[03:55] <TheMuso> I'm working on a snap that is command-line tools, but it has multiple command-line tools. When installing the snap, I notice the files in /snap/bin are renamed snapname.command... Any way to work around this in snapcraft.yaml, or is this by design?
[04:37] <jdstrand> niemeyer1: done
[05:21] <lpotter_> TheMuso: that's the design
[05:44] <jdstrand> Chipaca: hey, when you have a moment can you help me debug a testsuite issue?
[05:45] <TheMuso> lpotter_: Urm ok.
[06:50] <Gunther_> Good morning! Is there a way in vivid, to influence ubuntu-device-flash so that I am able to set a custom static ip (instead of dhcp)? How can I change the "ubuntu" user or its password. I want to do this changes to the image at time of creation.
[06:57] <trijntje> Hi all, I'm trying to get started using snaps by following the webcam tutorial on the site. I've got the snap to build, but when I install it with sudo snap install webcam_0.1_amd64.snap I dont know where it went
[07:11] <tsimonq2> !info kde4-config yakkety
[07:11] <tsimonq2> !info kde-config yakkety
[07:11] <tsimonq2> hmm
[07:12] <tsimonq2> !info kdelibs-bin
[07:12] <tsimonq2> \o/
[07:16] <nhaines> I'm sort of curious as to how far out the pulseaudio socket is from landing in snapd.  :)
[07:16] <tsimonq2> ^ yeah that would be nice
[07:18] <nhaines> I have a cute little script whose only function is to throw sound at the speakers.  I'd love to snappify it.
[07:19] <tsimonq2> nhaines: link? :D
[07:21] <trijntje> Should snap packages work in a normal 16.04 system? I've tried to install the 'hello' package with 'sudo snap  install hello', but when I run it I get  failed to create user data directory. errmsg: Permission denied
[07:22] <tsimonq2> trijntje: I am getting that exact same error on my machine, I think it's been reported already, but I could be wrong
[07:22] <nhaines> tsimonq2: oh, I should probably put it on LP or at least a bzr directory...
[07:22] <nhaines> http://www.apress.com/9781484206096 under "Source Code/Downloads".  It requires sox.
[07:23] <trijntje> tsimonq2: ok thanks, I'm trying 'notes' now
[07:23] <trijntje> hmm, same error
[07:28] <dholbach> tsimonq2, trijntje: does 'snap changes' give anything?
[07:28] <dholbach> is this with snapd 2.0.8?
[07:30] <nhaines> dholbach: how do I find what's changed between various revisions of the moon-buggy snap?
[07:31] <dholbach> nhaines, I think I would need to put it into changelog box when uploading the snap :)
[07:31] <dholbach> the last upload was quite a while ago, so I'm not sure what I changed back then
[07:31] <nhaines> dholbach: sure, but I don't think that shows up with 'snap' at all either, right?  :)
[07:32] <mvo> tsimonq2, trijntje: anything in "ls -lR ~/snap" that is owned by a different user (or root) by any chance?
[07:34] <tsimonq2> snap changes gives nothing
[07:34] <tsimonq2> mvo: everything in ls -lR ~/snap shows that I'm the owner
[07:35] <tsimonq2> dholbach: and yes, snapd 2.0.8
[07:36] <trijntje> mvo: no, its all owned by me. I also found a bug report about appArmor getting upset at encrypted homes, so I'm going to test that next.
[07:36] <dholbach> nhaines, I don't know
[07:36] <dholbach> nhaines, if not, maybe there should be a bug for it?
[07:36] <trijntje> but its lying anyway since it did create ~/snap/notes/1, so it has permission to write in my home dir
[07:36] <tsimonq2> trijntje: I have an encrypted home directory :)
[07:36] <tsimonq2> yeah
[07:36] <nhaines> dholbach: hmm, maybe.  I suppose I'll have to look into it.
[07:36] <dholbach> cool, thanks!
[07:37] <nhaines> 'snap login' is really vague and confusing to me!  All I know is that if I use it, I don't have to run 'snap install' with sudo.  Why?  :D
[07:37] <mvo> tsimonq2, trijntje thank you
[07:37]  * mvo scratches head
[07:37] <tsimonq2> mvo: and like stated eralier, I have an encrypted home directory with ecryptfs
[07:37] <tsimonq2> *earlier
[07:38] <mvo> tsimonq2: oh, that might indeed be why I don't see it here!
[07:43] <zyga> tsimonq2: there's a bug about encrypted home directory
[07:43] <zyga> tsimonq2: though last time I checked on xenial, it wasn't breaking anything, just printing messages when snap-confine / ubuntu-core-launcher were started
[07:44] <zyga> ah
[07:44] <zyga> mvo: one thing *has* changed
[07:44] <tsimonq2> zyga: I'm on Yakkety :)
[07:44] <zyga> mvo: the home directory is no longer created by snap-confine, now it's made by what? snap-run?
[07:44] <tsimonq2> (FWIW)
[07:44] <zyga> mvo: but that's not live yet, is it?
[07:46] <mvo> zyga: thats not in xenial yet AFAIK
[07:55] <ovalseven8_> Hello, what's the exact difference between the distribution of a statically linked software (one executable) and the Snap packages?
[07:56] <zyga> ovalseven8_: snaps can use shared libraries (e.g. you can ship two executables and a common shared library inside a snap)
[07:56] <zyga> ovalseven8_: statically linked software is just that, a static executable
[07:56] <trijntje> zyga, mvo: both hello and notes work in a fresh 16.04 in virtualbox without encrypted home
[07:57] <zyga> ovalseven8_: snaps provide data, shared libraries, executables and services in one bundle
[07:57] <trijntje> should I report a new bug or comment on the existing one?
[07:57] <zyga> trijntje: please comment on the existing one unless you think this is something very different than before, please include the version of snapd and ubuntu-core-launcher you have installed (apt-cache policy snapd)
[07:58] <trijntje> zyga: can you link the bug report?
[07:58] <ovalseven8_> zyga: Ok, but for the user of the software it doesn't really make a difference? Because if there's a bug in a dependency, he will have to update the snap/executable
[07:59] <zyga> tsimonq2: I see https://bugs.launchpad.net/snappy/+bug/1574556 but reading it quickly I think a new bug is better now
[08:00] <zyga> ovalseven8_: if there's a bug in the dependency the maker of the snap will see that as the snap won't run on their machine
[08:00] <zyga> ovalseven8_: snaps don't depend on anything from the system
[08:01] <trijntje> zyga: ill file a new bug report, but it looks like the last two comment (from bruno nova) are about the same problem I have
[08:01] <ovalseven8_> zyga: Yeah, but the delivered dependencies inside the snap have to be updated, no?
[08:02] <zyga> ovalseven8_: updated for what?
[08:02] <ovalseven8_> zyga: If there's a bug
[08:04] <nhaines> ovalseven8_: typically, the maker of a snap uses 'snapcraft', which automates getting everything from the Ubuntu repositories or from source repositories and then builds everything.  So the snap maker would have to run 'snapcraft' again, wait 5 minutes, and then upload the new version to the store.
[08:04] <zyga> ovalseven8_: yes
[08:04] <zyga> ovalseven8_: that's correct
[08:08] <trijntje> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592696
[08:44] <tsimonq2> !info json-glib yakkety
[08:44] <tsimonq2> !info libjson-glib-1.0-0 yakkety
[08:45] <tsimonq2> !info libjson-glib-dev yakkety
[08:59] <tsimonq2> !info gnome-keyring
[08:59] <morphis> zyga: ping
[09:13] <tsimonq2> !info gnome-keyring-dev
[09:18] <petermaffay> hey there, i'm new to packaging snap and got a question: i develop a webapp which needs apache and php7, is there an option to import these two with the "plugin" tag in snapcraft
[09:20] <tsimonq2> petermaffay: hello, you would put the appropriate packages in build-packages, the plugin is for compiling the snap
[09:22] <dholbach> use "stage-packages" if you want to include the contents of packages in the snap.
[09:22] <dholbach> "build-packages" are just packages you need to build the snap.
[09:22] <petermaffay> thanks very much!!
[09:23] <dholbach> anytime :)
[09:24] <tsimonq2> petermaffay: if you want to check out some examples, take a look at snappy-playpen: https://github.com/ubuntu/snappy-playpen - if you have questions for how that would be implemented and such
[09:28] <tsimonq2> !info cpp
[09:28] <tsimonq2> !info c++
[09:29] <tsimonq2> !info g++
[09:29] <tsimonq2> aha
[09:50] <dpm> davidcalle, in addition to the snapcraft.io coverage, I was enjoying seeing the image you created for d.u.c on the media :) http://www.zdnet.com/article/ubuntu-snap-takes-charge-of-linux-desktop-and-iot-software-distribution/
[09:52] <seb128> is there a way for snapcraft to run manual commands after the "make install" step from the autotools plugins?
[09:52] <seb128> like to move files around or clean some
[09:52] <seb128> before the squashfs is generated
[09:52] <seb128> sergiusens, ^
[09:56] <davidcalle> dpm: hehe same here, also on https://www.linux.com/news/ubuntu-snappy-based-package-format-aims-bridge-linux-divide . "Make it. Snap it. Push it. Update it" has been out there as well, this is pretty fun.
[10:05] <tsimonq2> !info kde4-devel
[10:05] <tsimonq2> !info kdebase-dev-kde4
[10:06] <tsimonq2> !info kdelibs4-dev
[10:06] <tsimonq2> !info kdelibs5-dev
[10:08] <bollo> I installed vtop and then tried to remove it but it just stuck on remove. I then ran abort and now it's just stuck on that.
[10:09] <bollo> Restarted snapd to see if that would solve anything but no.
[10:10] <bollo> So now I can't try to remove it again since it's stuck on abort.
[10:17] <bollo> I can't remove it since it can't be unmounted it seems
[10:25] <jdstrand> zyga: hey, so snap-confine HEAD has a failing test. I feel like maybe I am not compiling it right with the lastest updates. basically, I'm snagging the Build-Depends, then doing 'debian/rules build'
[10:27] <jdstrand> zyga: meh, nm
[10:27] <jdstrand> common.sh was missing a syscall
[10:34] <zyga> jdstrand: :-)
[10:34] <zyga> jdstrand: I'll be enrolling snap-confine in spread this week
[10:35] <zyga> jdstrand: to ensure it compiles and builds on ubuntu, fedora and arch (initially)
[10:35] <zyga> jdstrand: and that tests pass
[10:35] <zyga> jdstrand: we need to start thinking about making testing possible when snap-exec story is done
[10:35] <zyga> jdstrand: and snap-confine unconditionally execs snap-exec
[10:47] <petermaffay> hey, still trying to build apache snap, got this now: name: anchor  version: 0.1  summary: anchor file browser  description: no production use  confinement: devmode  parts:  webserver: stage-packages:      - apache2
[10:48] <petermaffay> what should i use for plugin and source as they are required fields?
[10:48] <petermaffay> at the moment just trying to package apache :P
[10:50] <georgeowell> Hey all. I have an encrypted home directory and I'm running into this bug: https://bugs.launchpad.net/snappy/+bug/1574556
[10:51] <georgeowell> Is there a work around? I don't really understand the stuff referenced in the launchpad comments.
[10:52] <georgeowell> I get "failed to create user data directory. errmsg: Permission denied" when I try and run a snap
[11:09] <trijntje> georgeowell: I think this is the bug you have: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592696
[11:10] <georgeowell> Do I just select "this affects me"?
[11:12] <trijntje> yes, that way the developers see that a lof of people run into this bug
[11:13] <trijntje> I expect this will be fixed pretty fast, since its a recent problem and a lot of people have encrypted homes (though I'm not a developer for snap)
[11:55] <Gunther_> Hi there!
[11:57] <Gunther_> Is there a working way to configure a static network interface in vivid using u-d-f? (Tried modifying meta-data with little success)
[12:02] <ogra_> Gunther_, 15.04 is pretty dead, but you couold create your own gadget snap and apply config through that
[12:04] <olli> t
[12:04] <ogra_> u
[12:04] <Gunther_> ogra_: I am currently editing the created image. Still /etc/network/interfaces.d/eth0 gets automatically created using a dhcp config. If I try to insert a static configuration file at the same place, its changed to dhcp at the first boot.
[12:05] <Gunther_> I think the behaviour on 16.04 is the same
[12:06] <ogra_> well, 16.04 isnt done yet ... the config interface and firstboot stuff is still in the works (all focus was at the desktop and cross distro stuff for the last weeks, images are looked at now )
[12:08] <Gunther_> Just one answer please :): Who is generating /etc/network/interfaces.d/eth0 ?  systemd or cloud-init?
[12:09] <ogra_> snapd
[12:09] <ogra_> well
[12:09] <ogra_> not sure if it did that in 15.04
[12:09] <ogra_> nobody touched that in monts
[12:09] <ogra_> (includign me)
[12:10] <ogra_> (not even sure there was snapd ... could have been called snappy-firstboot or some such)
[12:10] <Gunther_> ok looking for firstboot now. thanks
[12:11] <Gunther_> ubuntu-snappy.firstboot.service :)
[12:13] <ogra_> yeah
[12:13] <ogra_> kyrofa, trying snapcraft for a wine package i get "multiple repeat at position 40" as answer when it fails ... any indicator what that might mean ?
[12:15] <kyrofa> ogra_, huh... can you pastebin the result of snapcraft --debug ?
[12:15] <ogra_> or sergiusens ^^
[12:16] <ogra_> kyrofa, http://paste.ubuntu.com/17358094/
[12:16] <ogra_> hmm
[12:16] <ogra_> could it be because i dont use a subdir for the binaries i want to copy ?
[12:17] <ogra_> (i have everything in the toplevel dir)
[12:17] <kyrofa> ogra_, seems like a regex error
[12:17] <ogra_> http://paste.ubuntu.com/17358140/ is the snapcraft.yaml
[12:18] <kyrofa> ogra_, when it's trying to replace $SNAP in the output
[12:18] <kyrofa> ogra_, please log a bug, I think there's a larger problem here
[12:18] <ogra_> hmm .. i have a dash in the package name
[12:18] <ogra_> ok
[12:19] <ogra_> (though there are other packages with dash ... )
[12:19]  * ogra_ files a bug 
[12:25] <ogra_> kyrofa, sergiusens, bug 1592795
[12:26] <kyrofa> ogra_, no I don't think this is a YAML problem, it has something to do with the combination of the regex we're using and the file contents of the snap that needs some investigating
[12:27] <ogra_> k
[12:52] <ogra_> Son_Goku, zyga is zyga if he is on IRC :)
[12:52] <Son_Goku> :/
[12:53] <ogra_> (he isnt around atm obviously)
[12:53] <Son_Goku> what time zone does he live in?
[12:53] <Son_Goku> I'm in UTC-4
[12:53] <ogra_> EU ... but i think he has to care for personal stuff this afternoon
[12:54] <ogra_> perhaps we can help you ?
[12:55] <ogra_>   yeah, he is UTC-2 or so
[12:56] <Son_Goku> well, I wanted to talk to him about Fedora / Mageia packaging for snaps
[12:57] <Son_Goku> but perhaps you can answer a more general question of mine
[12:57] <Son_Goku> when will the server components to snaps be open sourced and allow for alternative repositories of snaps to exist?
[12:59] <jamiebennett> Hi Son_Goku, the server-side components are not planned to be open sourced at this time
[12:59] <Son_Goku> ...
[12:59] <Son_Goku> wuh?!
[12:59] <Son_Goku> why?!
[13:00] <Son_Goku> is this going to be Launchpad all over again?
[13:00] <jamiebennett> Son_Goku: we have been concentrating on the client side of snaps so it has not been on the roadmap so far
[13:00] <jamiebennett> Son_Goku: we will of course continue to assess this going forward
[13:00] <m15k> "error: cannot remove "jenkins": snap "jenkins" has changes in progress" any suggestions howto solve this?
[13:00] <Narcotix> being completely new to the "snap" topic, i wonder: can anyone set up a "snap store"? i mean is the snap package system bound to the ubuntu store or ir cannonical just the only provider of snaps atm?
[13:01] <Son_Goku> no one can currently set up snap stores
[13:01] <Son_Goku> Canonical is the gatekeeper for all things snappy :(
[13:01] <Narcotix> holy moly :O this is rly evil
[13:01] <jamiebennett> Son_Goku: snaps can be side loaded easily
[13:01] <Son_Goku> that's not an suitable answer
[13:02] <Narcotix> i mean this is like with the windows universal apps
[13:02] <jamiebennett> Son_Goku: sorry I can't give you a date at this time
[13:02] <Son_Goku> sideloading means that there's no mechanism for updates
[13:02] <ogra_> you can sideload the updates too :)
[13:02] <Narcotix> so the snap packaging tool isn't open source ?
[13:02] <jamiebennett> Narcotix: it
[13:02] <jamiebennett> is
[13:02] <jamiebennett> Narcotix: the server side stuff is not at this time
[13:02] <Son_Goku> ogra_ yes, but that's not quite the same thing
[13:03] <jamiebennett> Narcotix: for stores
[13:03] <Son_Goku> essentially, if you want another store to exist, someone has to reverse engineer the protocol and then alter the client to user it
[13:03] <Son_Goku> *use
[13:03] <Narcotix> yeah but... it's like anyone can set up a store with win32 api programms, but only microsoft can set up a store for universal apps
[13:04] <Son_Goku> to some extent, I'm not really surprised
[13:04] <ogra_> no, but it is upgradeable that way
[13:04] <Son_Goku> the system was designed for the mobile context, where everything is locked down because things
[13:05] <Son_Goku> (the reasoning for locked down systems in mobile is too complicated for me to want to get into...)
[13:05] <Son_Goku> but this new trend of bringing that locked down nature to traditionally open platforms is frightening
[13:06] <Narcotix> wow, so if snap packages would become THE standard among all distros, this would mean that Linux would become more of a walled garden (if deb, yum and others get dropped somewhen in the future)
[13:06] <ogra_> why woud deb and yum be dropped ?
[13:06] <ogra_> there is no reason to drop them
[13:07] <Narcotix> well, i guess you are right
[13:07] <jamiebennett> Narcotix: and of course anyone can develop and push a snap to the store
[13:07] <Narcotix> but developers could drop them
[13:07] <ogra_> and none of the newer packaging systems focus on that ... they all focus on delivering apps
[13:07] <jamiebennett> it is just a delivery mechanism
[13:07] <Son_Goku> ogra_ that's not what Canonical is putting out
[13:07] <Narcotix> so they still exist, but programs won't get published as debs
[13:08] <Son_Goku> they've been talking about moving over to snap system in place of debs and rpms
[13:08] <ogra_> Son_Goku, what are you referring to now ?
[13:08] <Son_Goku> ubuntu snappy core and ubuntu snappy desktop
[13:08] <ogra_> Son_Goku, do you have a refercene for that ?
[13:08] <Son_Goku> lemme see if I can find it...
[13:08] <ogra_> (an official statement)
[13:08]  * ogra_ is sure there is none 
[13:09] <ogra_> probably a third party speculation ...
[13:09] <ogra_> oor a developers wishful thinking :)
[13:09]  * Son_Goku sighs
[13:09] <Son_Goku> it was somewhere on either launchpad or one of the ubuntu dev blogs
[13:09] <ogra_> debs wont go away in ubuntu
[13:09] <ogra_> neither will the classic installs
[13:10] <ogra_> even *if* there will perhaps be full snappy based desktop installs ... the ubuntu deb archive would have to be used to create these snaps
[13:10] <ogra_> so how could we ever drop it ? :)
[13:14] <ogra_> Son_Goku, https://plus.google.com/+OliverGrawert/posts/YQ7idGAXzFd see the comments here
[13:16] <m15k> Is there a documentation how the snapped packages are run? Currently I'm a little bit confused if the applications are isolated or how...
[13:19] <justtesting> With regard to isolation, here's a page on security: https://developer.ubuntu.com/en/snappy/guides/security/ Not sure how they are really run though. Maybe another page details that.
[13:20] <jdstrand> justtesting: see this https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/
[13:20] <jdstrand> m15k: ^
[13:20] <ogra_> m15k, they are run inside the core snap  ... and via interfaces they can talk to the host
[13:21] <m15k> Thanks, I'll have a look at the pages.
[13:21] <ogra_> (and yeah, that page is probably the better answer :) )
[13:33] <sabdfl> m15k, the apps run under a profile that is setup by the snap machinery, and covers seccomp, apparmor and a range of other confinement techniques
[13:33] <sabdfl> m15k, the idea is that a snap can have a binary running as root which still doesn't see anything it is not allowed to
[13:35] <morphis> ogra_, jdstrand: btw. how is the core snap involved on desktop? is LD_LIBRARY_PATH or so linked to it or is there no usage at all?
[13:36] <ogra_> the launcer sets the library path
[13:36] <morphis> ok as I thought
[13:36] <morphis> matteo: ^^
[13:37] <morphis> ogra_: so host binaries should used at all?
[13:37] <ogra_> no, they shouldnt
[13:37] <morphis> ok
[13:38] <matteo> yes, I've tried but got a SIGSEGV
[13:46] <seb128> does anyone know where is the snap/.desktop integration documented?
[13:47] <seb128> there is no [.]desktop mentioned on http://snapcraft.io/create/
[13:48] <seb128> nor on https://developer.ubuntu.com/en/desktop/get-started/
[13:49] <seb128> why isn't it just using/exporting one based on the snap/u/s/a one with the exec mangled?
[14:06] <seb128> mvo, ^ do you know?
[14:07] <kyrofa> seb128, I suspect it's still not documented
[14:08] <kyrofa> seb128, but you just drop them in snapcraft's setup/gui/ directory
[14:09] <mvo> seb128: is https://github.com/snapcore/snapd/blob/master/docs/meta.md#gui-directory helpful?
[14:10] <seb128> mvo, yes, thanks ... do you know why we just don't use the upstream one? would be less packaging work/easier
[14:10] <seb128> and get translations&co
[14:16] <mvo> seb128: its very close to the upstream one, translations and all will be unchanged, the upstream one will do something like /usr/bin/foo but it won't be /usr/bin/foo in the snap so that requires a tiny bit of tweaking. essentially Exec= and Icon= is what needs tweaking. I guess snapcraft could try to be smart about it
[14:18] <seb128> mvo, right, my point is "why not using the upstream one and just mangling exec/icon automatically for the user"
[14:18] <seb128> mvo, with the current scheme you need to dup info and keep up with upstream tweaking e.g their description or categories or keywords
[14:19] <mvo> seb128: that would be cool, its a bit tricky to know how to map the meta/snap.yaml app to the exec line, we could try to do pattern matching I guess, we could of course be radical and allow only exec lines that match the snap name itself by default
[14:19] <mvo> seb128: same for icons
[14:20] <mvo> seb128: that would solve the common case at least, i.e. if you package "gnome-foo" your app in snap.yaml must be named "gnome-foo" and that is the exec line you get in your deskop file (and then we need to think about an override for this openoffice thing with 243324 desktop files inside ;)
[14:20] <seb128> mvo, or you could have the manifest have a section that let you override the exec/icon by specifying those
[14:21] <seb128> and having snapcraft doing the work for copying/sedding with those values
[14:21] <mvo> seb128: manifest == snapcraft.yaml?
[14:21] <seb128> yes
[14:21] <seb128> sorry
[14:21] <mvo> seb128: yeah, that is a sergiusens thing then :) works for me
[14:21] <mvo> seb128: no worries, just wanted to be sure we talk about the same thing
[14:22] <seb128> the current way is undocumented on our main websites
[14:22] <seb128> so it's likely most desktop app snappers are going to overlook that
[14:22] <mvo> davidcalle: -^ is that something you could help with?
[14:22] <seb128> and we have less good integration in the desktop as a result
[14:22] <mvo> davidcalle: basicly making https://github.com/snapcore/snapd/blob/master/docs/meta.md#gui-directory available somehow
[14:22] <mvo> seb128: +1
[14:23] <seb128> mvo, thanks for relaying the nag to the right people ;-)
[14:23] <seb128> mvo, also since it's similar/related, do you know if there is an consideration using the upstream appstream info if available rather than requesting the snapcraft.yaml to duplicate e.g the description?
[14:23] <davidcalle> mvo: sure, give me 3 min
[14:24] <seb128> mvo, or we could have description: $appstream-desc
[14:24] <seb128> ?
[14:29] <davidcalle> mvo: oh I thought it was a new edit on the doc, but the last commit is actually mine... You mean giving it more visibility than in https://developer.ubuntu.com/en/snappy/guides/meta/?
[14:32] <blackout24> What happend to the idea of frameworks? I can't find any info on framework snap anymore on the official websites.
[14:35] <seb128> hum
[14:36] <seb128> does anyone know how to I tell snapcraft that no the build step is not outdated?
[14:36] <seb128> and that it should access to prime as I asked
[14:38] <seb128> sergiusens, ^?
[14:42] <seb128> shrug
[14:42] <davidcalle> seb128: mvo: what about a new example (desktop integration-oriented) using the krita snap in https://developer.ubuntu.com/en/desktop/examples/
[14:43] <seb128> davidcalle, shouldn't those things be covered on snapcraft.io?
[14:43] <seb128> davidcalle, also I think the .desktop should be autogenerated from the upstream one rather than requesting you to have a new one
[14:44] <sergiusens> seb128 you will need to marshall some yaml, how did you end up in this situation? kyrofa can help with state management
[14:45] <seb128> sergiusens, I built a snap, then decided I need to do some changes before it's packed so I "snapcraft clean -s prime" and copied things around in stage/snap
[14:45] <davidcalle> seb128: I fuly agree on both points, but if we want to have something sooner than later, let's use what we have (krita snap with custom desktop file), I think that desktop file generation is snapcraft's territory
[14:45] <seb128> sergiusens, no that I modified the stage I wanted to rebuild the snap by using "snapcraft prime"
[14:46] <seb128> now*
[14:47] <seb128> sergiusens, should that work of did I do something fundamentally wrong?
[14:48] <kyrofa> seb128, are you sure you didn't change the YAML at all?
[14:49] <seb128> kyrofa, oh, I might for another later iteration
[14:49] <kyrofa> seb128, because the build step saves the YAML on which it ran and compares to the current YAML to determine whether or not it's out of date
[14:50] <seb128> where does it save it?
[14:50] <seb128> there is no other *yaml in my dir
[14:50] <kyrofa> seb128, in parts/<part>/state/<step>
[14:51] <seb128> ok, indeed
[14:51] <seb128> thanks kyrofa
[14:51] <seb128> that didn't have the argument I added
[14:51] <kyrofa> seb128, yep, that'll do it
[14:51] <seb128> hum
[14:52] <seb128> can I move things around in the stage?
[14:52] <seb128> prime is complaining about a missing file
[14:52] <seb128> which I moved around
[14:52] <sergiusens> seb128 the files really get migrated from parts/<part-name>/install
[14:53] <seb128> sergiusens, snapcraft.io states
[14:53] <seb128> "stage/ is where all the content from parts/<part_name>/install is copied and consolidated in a single directory."
[14:53] <seb128> so I though it was the step after
[14:53] <seb128> like things get copied from parts
[14:53] <seb128> and then the stage is moved to prime
[14:53] <seb128> is that wrong?
[14:54] <seb128> if I want to move things around should I do it in the install?
[14:59] <sergiusens> seb128 mvo about desktop files and snapcraft. Doing things by convention was a mistake. I'll be allowing it to be declarative which would allow adapting such desktop file to whatever the "by convention" is in snapd
[15:07] <seb128> sergiusens, would that avoid having to create one? could you say
[15:07] <seb128> desktop:
[15:07] <seb128>     file: ...
[15:07] <seb128>    exec:
[15:07] <seb128>      icon:
[15:08] <seb128> and have it use the upstream "file" points at just sedding the exec/icon values?
[15:08] <ogra_> sergiusens, i got the telegram update today, now i have a broken icon in the panel ... known issue ?
[15:15] <sergiusens> ogra_ yeah, telegram does not respect the --no-auto-update switch it has :-/
[15:16] <ogra_> well, i dont mind the update ... and i definitely didnt have a panel applet before
[15:16] <ogra_> it is just the icon that is missing it seems
[15:16] <kyrofa> seb128, regarding stage versus install: the files are pulled from stage, but the filesets are determined using install
[15:17] <kyrofa> seb128, that's why you may notice that if you use the `stage` keyword to filter stuff, you almost always must include the same filter with the `snap` keyword
[15:17] <didrocks> kyrofa: I guess seb128 is talking about the other stage
[15:18] <didrocks> like:   stage        Stage the part's built artifacts into the common staging area.
[15:18]  * ogra_ wishes he would be able to build any snaps at all :(
[15:18] <ogra_> Fetched 0 B in 0s (0 B/s)
[15:18] <ogra_> E:Unable to correct problems, you have held broken packages.
[15:18] <seb128> kyrofa, sorry I don't understand, if I want to tweak the target layout between the "make install" and the prime what do I change?
[15:18] <ogra_> thats all i see since hours :(((
[15:18] <didrocks> (not the stage as stage-packages)
[15:18] <kyrofa> didrocks, indeed, as am I
[15:19] <dholbach> ogra_, did you try using --enable-geoip?
[15:19] <didrocks> ah sorry, unsure to understand you either then :p
[15:19] <dholbach> ogra_, or clearing your /var/lib/apt/lists cache?
[15:19] <kyrofa> seb128, in my experience you kinda need to do that in prime
[15:19] <kyrofa> seb128, because moving files around in stage will lead to issues when priming, as you noticed
[15:19] <kyrofa> seb128, you can change contents in stage, but not layout
[15:19] <ogra_> dholbach, well, ithe hosts apt works just fine ... it is only under snapcraft
[15:19] <seb128> kyrofa, ok...
[15:20] <kyrofa> seb128, not one of my favorite features, but I seem to remember there being a reason for it
[15:20] <ogra_> it also worked once this morning ... but not anymore since
[15:21] <kyrofa> ogra_, huh... does your system apt work okay?
[15:21] <ogra_> yes
[15:21] <ogra_> i have one private PPA enabled though ... i wonder if that causes havoc (though it didnt in the morning)
[15:24] <dholbach> popey, http://paste.ubuntu.com/17365382/? :-)
[15:34] <RaycatRakittra> Hello?
[15:35] <RaycatRakittra> Anyone active?
[15:38] <ogra_> yes
[15:38] <ogra_> :P
[15:39] <seb128> shrug
[15:39] <seb128> I screwed snapcraft by moving a dir in the stage
[15:39] <seb128> "snapcraft clean" fails now
[15:40] <seb128> sergiusens, is there a "clean-without-check"?
[15:40]  * seb128 just rm
[15:40] <kyrofa> seb128, yeah, rm. Also rm the parts/<part>/state/stage
[15:40] <seb128> kyrofa, thanks
[15:40] <seb128> that was needed
[15:41] <seb128> pocking around things you shouldn't is fun :p
[15:41] <kyrofa> seb128, the state tracking is pretty whiny, but it means you can actually unstage a part without messing with other parts
[15:41] <kyrofa> seb128, but yeah, it results in that if you poke at it
[15:42] <seb128> I'm still unclear what I should do exactly if I want to move things after the make install
[15:42] <seb128> move or remove
[15:42] <seb128> like some of the make installed thing are useless and waste space
[15:42] <kyrofa> seb128, at that point all best are off if you want snapcraft to continue working. You should be doing such things with the organize keyword, etc
[15:42] <seb128> what's the official way to deal with that?
[15:42] <matteo> I've disabled confinement in ubuntu-core-launcher with this patch: http://pastebin.ubuntu.com/17366167/ looks reasonable for you?
[15:42] <kyrofa> seb128, or filter them out with the stage and snap keywords
[15:43] <seb128> kyrofa, are those snapcraft.yaml keywords?
[15:43] <kyrofa> seb128, indeed
[15:43] <kyrofa> seb128, https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-syntax.md
[15:43] <seb128> snapcraft.io doesn't cover those
[15:43] <seb128> thanks
[15:44] <seb128> kyrofa, so default is everything but if you use stage: you need to manually list all the things you want?
[15:44] <seb128> is there a reverse "clean"?
[15:44] <seb128> or "exclude"?
[15:44] <kyrofa> seb128, or prefix with a minus
[15:45] <kyrofa> seb128, to blacklist
[15:45] <kyrofa> seb128, an example of all the mysql stuff I didn't want to ship in the nextcloud snap: https://github.com/kyrofa/nextcloud-snap/blob/master/snapcraft.yaml#L144
[15:47] <seb128> kyrofa, thanks
[15:48] <seb128> kyrofa, I don't really understand why there is a "snap"
[15:48] <seb128> kyrofa, if you exclude things from the stage they are not going to be in the snap either at the end right?
[15:48] <kyrofa> seb128, filter applying to stage versus filter applying to prime
[15:48] <seb128> what difference does it make?
[15:48] <kyrofa> seb128, no, that's what I was trying to say earlier
[15:49] <kyrofa> seb128, for example, take the boost part: https://github.com/kyrofa/nextcloud-snap/blob/master/snapcraft.yaml#L115
[15:49] <kyrofa> seb128, I need it in stage so I can build against it, but I don't want to ship it in the final snap
[15:50] <seb128> oh, I see
[15:50] <seb128> that makes sense now
[15:50] <seb128> thanks
[15:53] <kyrofa> Sure thing!
[15:55] <didrocks> kyrofa: but if you exclude it from the stage, it will be excluded in the prime directory as a result, right?
[15:55] <kyrofa> didrocks, no, that's what I was saying
[15:55] <kyrofa> didrocks, it'll error instead :)
[15:55] <kyrofa> didrocks, try it!
[15:55] <didrocks> I was thinking stage -> impacts primes that way
[15:55] <didrocks> hum, ok, will do
[15:57] <kyrofa> didrocks, seb128 https://bugs.launchpad.net/snapcraft/+bug/1537850
[15:57] <kyrofa> sergiusens may know more about the history/reasons for doing it that way
[15:59] <didrocks> kyrofa: ok, so reading this… shouldn't stage/ be skipped or kept empty if you don't have some after: keyword?
[16:00] <kyrofa> didrocks, that's also where reorganization happens, I think
[16:00] <didrocks> (and stage/ be populated only by parts which are declared after any after: keywords)
[16:00] <didrocks> kyrofa: if the reorg happens in stage/ it's counter-intuitive then
[16:00] <didrocks> as this will impact prime
[16:01] <kyrofa> didrocks, indeed, I think you need to use the reorganized named in the filters: "filesets will refer to the exposed named applied after organization is applied."
[16:01] <kyrofa> s/named/names/
[16:02] <didrocks> kyrofa: something is still unclear in my head. I need to play with this and reorganizing at the same time. I bet if seb, you & I were puzzled at some point about this, something isn't right in the way snapcraft is handling it
[16:02] <didrocks> but we may be all wrong (the 3 of us :p)
[16:02] <kyrofa> didrocks, I completely agree
[16:03] <didrocks> ok, I'll play with this tomorrow with reorg to see the behavior
[16:03] <matteo> ping mvo
[16:04] <kyrofa> didrocks, let me know
[16:04] <didrocks> will do :)
[16:37] <mhall119> sgclark: d_ed: hey, niemeyer1 would like to talk with you guys about how best to support the sharing of KDE Frameworks between KDE snaps
[16:38] <d_ed> sure
[16:38] <d_ed> I can tell you what we're currently doing for FlatPak at least.
[16:39] <mhall119> niemeyer1: do you want to have a hangout for this?
[16:42] <mhall119> sgclark: also, I have a pull request for your kate snap, I've got building in a clean lxc now
[16:46] <sgclark> alrighty
[17:00] <kyrofa> kgunn, here's the qmake plugin if you're able to take a look: https://github.com/ubuntu-core/snapcraft/pull/566/files#diff-dd46e36f2d591eb4108efc48a69fa41eR1
[17:01] <mvo> matteo: pong
[17:01] <matteo> hi mvo
[17:01] <mvo> hi
[17:01] <matteo> I've compiled ubuntu-core-launched with a patch to disable confinement
[17:02] <matteo> but it's working bad, can you have a quick look?
[17:02] <matteo> http://pastebin.ubuntu.com/17366167/
[17:02] <mvo> matteo: oh, interessting! can you please check out https://github.com/snapcore/snap-confine ?
[17:02] <mvo> matteo: it has a --isable-confinment configure switch
[17:03] <matteo> yes I know
[17:03] <mvo> matteo: and is otherwise compatible with ubuntu-core-launcher, so its a drop-in
[17:03] <matteo> I took the relevant part from there
[17:03] <matteo> mvo: I see that there is a wrapper around it
[17:03] <matteo> which removes an argument
[17:03] <matteo> right?
[17:04] <mvo> matteo: yeah, it provides a wrapper, but that should be ok, did it not work for you?
[17:04] <mvo> matteo: i.e. if it does not work, that would be a bug, its meant to be a drop-in replacement
[17:04] <mvo> fully comaptible and all that
[17:04] <matteo> I never tried that because I tought that snapd was not ready
[17:04] <matteo> ok, I'll discard the core launcher then
[17:04] <mvo> matteo: aha, sorry, please give it a try a shout if there are any problems :)
[17:04] <matteo> thanks
[17:05] <mvo> matteo: thank you! and keep us/me updated please
[17:05] <matteo> will do :)
[17:14] <mhall119> is it possible to build a snap for a different arch using snapcraft cleanbuild?
[17:25] <mhall119> sgclark: I'm getting this when trying to build kdevelop: [Errno 2] No such file or directory:
[17:25] <mhall119> '/root/parts/kdevelop/install/usr/bin/pp-trace'
[17:26] <mhall119> any suggestion on what package that might be in?
[17:33] <kyrofa> mhall119, regarding the cross-building, that's only supported for kernels right now
[17:34] <kyrofa> mhall119, though if you ran snapcraft in a 32-bit lxc, that should work fine (cleanbuild won't do that for you)
[17:35] <elopio> ping ogra_: I have a bash question. Are you here?
[17:42] <willcooke> kyrofa, hey, re: qmake plugin.  I had an issue with qmake yesterday where I had to pass in the name of a specific .pro file.  I don't /think/ your plugin caters for that.  Do you want a patch?
[17:42] <sgclark> mhall119: my repo has all the deps needed, builds in cleanbuild. however that is a qt4 build which I do not want.
[17:44] <mhall119> sgclark: is there a cmake flag or something to tell it to build only for qt5?
[17:44] <kyrofa> willcooke, ah, I was wondering about that
[17:44] <kyrofa> willcooke, what does that command look like?
[17:45] <sgclark> mhall119: nevermind, that particualre one is fine it will build qt5
[17:45] <sgclark> we are doing some a bit differently
[17:45] <willcooke> kyrofa, it's dead simple:  https://github.com/8none1/fritzing-snap/blob/master/parts/plugins/x-qmake.py#L54
[17:46] <willcooke> kyrofa, it's probably a hack, but I'm not familiar with qmake, but it worked for me
[17:46] <kyrofa> willcooke, looking at the manpage, it seems you can profile multiple .pro files, is that correct?
[17:46] <kyrofa> s/profile/provide/
[17:47] <kyrofa> willcooke, yeah, my familiarity with it is rather limited as well, obviously. I only ever use it from qtcreator :P
[17:48] <willcooke> kyrofa, ah, yes it does look like it, haven't accommodated that but it should be easy enough
[17:48] <kyrofa> willcooke, alright I'll add an optional config parameter that is an array of .pro files. Will that serve your purpose okay?
[17:49] <willcooke> kyrofa, yeah, should do!  I can easily test with my use-case at least
[17:49] <kyrofa> willcooke, also, can I safely assume that these are _paths_ to .pro files? i.e. they don't need to be in cwd?
[17:50] <willcooke> kyrofa, hummm, don't know I'm afraid.  I just passed a .pro that *was* in cwd
[17:51] <willcooke> i.e. "project-file:  wills-special-pro-file.pro"
[17:51] <willcooke> in the yaml
[17:51] <kyrofa> willcooke, alright
[17:52] <willcooke> anyone in the channel a qmake expert? mhall119, know anyone?
[17:53] <mhall119> willcooke: bzoltan maybe?
[17:53] <willcooke> oh yeah! bzoltan do you know if the "files" passed in to qmake need to be in the cwd or can they be absolute paths as well?  I'd assuming the later.
[18:08] <elopio> ogra_: hey, you would be proud. Look how I solved it: subunit2pyunit results.subunit 2>&1 >/dev/null | sed "s/\\\n/\n/g"
[18:09] <bzoltan> willcooke:  hard to say, could you pastebin the pro file?
[18:09] <elopio> the scary thing is that I'm understanding bash, and it's all your fault.
[18:10] <kyrofa> elopio, aww, I could have helped you there, I'm sorry
[18:11] <willcooke> bzoltan, the one I was using is here:
[18:11] <willcooke> err, here: https://github.com/fritzing/fritzing-app/blob/master/phoenix.pro
[18:12] <willcooke> but this is more a qmake thing,  can it accept absolute paths *and* relative ones passed to qmake?
[18:12] <willcooke> Usage: /usr/lib/x86_64-linux-gnu/qt5/bin/qmake [mode] [options] [files]
[18:12] <thibran> hi
[18:13] <bzoltan> willcooke:  the file path there should be relative to the project file
[18:13] <bzoltan> willcooke:  absolut path I am not sure about
[18:14] <willcooke> bzoltan, oki, thanks!
[18:14] <willcooke> kyrofa, so I guess we go with relative for now then ^
[18:14] <thibran> would you be interested in a patch to change the output of 'snap find *' to 'snap find'?
[18:14] <bzoltan> willcooke: good luck, ping me back if you ned help... i am not at the sharpest state right now... 9pm and started 5am :)
[18:15] <willcooke> bzoltan, cheers!
[18:15] <kyrofa> bzoltan, just to clarify, this is about the `files` parameter to the qmake cli
[18:15] <kyrofa> bzoltan, it sounds like you're talking about the contents of the .pro file, no?
[18:16] <kyrofa> bzoltan, but I think it must accept paths, since it seems out-of-source builds work fine
[18:17] <bzoltan> kyrofa: yes, i am talking about the pro file
[18:17] <bzoltan> zbenjamin: ^^^
[18:22] <baggednismo> does anyone know the specifics og ubuntu core boot? hoping it loads an image in ram but cant find any docs on it anywhere
[18:33] <zbenjamin> willcooke: kyrofa: since qmake supports shadow builds they can be somewhere else than cwd... there might be some restrictions. so for example the build directory can not be a subdirectory of the source dir
[18:34] <zbenjamin> if i remember correctly
[18:35] <kyrofa> zbenjamin, so if I'm in my build directory, `qmake /my/path/to/src` and `qmake /my/path/to/src/my_project.pro` both look like fine invocations?
[18:36] <zbenjamin> kyrofa: yeah that should work
[18:40] <ali1234> baggednismo: i don't think it does that. i think it has a read only root with tmpfs for logs etc
[18:40] <kyrofa> zbenjamin, thank you!
[18:48] <ralsina> Hi there, I seem to have managed to create a snap that breaks snapd :-)
[18:48] <ralsina> https://pastebin.canonical.com/158808/
[18:49] <ralsina> And the snapcraft.yaml is not very weird http://pastebin.ubuntu.com/17374772/
[18:52] <baggednismo> @ali1234 im having trouble with my ubuntu IOT devices and they are getting powered off improperly. they are dropping like flies so I need a solution that loads the OS in ram so any read/write doesnt damage the OS if improperly shutdown
[18:52] <nothal> baggednismo: No such command!
[18:52] <ali1234> baggednismo: i have the same problem. i don't know the solution yet...
[18:52] <ali1234> raspberry pi?
[18:52] <baggednismo> :-)
[18:52] <baggednismo> and liva
[18:53] <baggednismo> they are powered by TV USB so when TV is turned off the pi is turned off
[18:53] <baggednismo> liva is lasting longer because it never shuts off
[18:53] <ali1234> yeah... it's a problem for sure
[18:53] <ali1234> i had hope that snappy core would solve this problem but i haven't really been able to even get it to work yet
[18:53] <baggednismo> i was hoping if the root is read only then it cannot possibly corrupt the OS
[18:54] <ali1234> in theory it is supposed to be read only
[18:54] <baggednismo> i was just reviewing snaps, mine would be time consuming but doable. need a LAMP stack on it
[18:55] <ali1234> LAMP should be trivial
[18:55] <ali1234> i need the videocore libraries for my app... i don't know how to include them in a snap
[18:56] <baggednismo> right now im using wget to pull a page down to apache so if there is no connection to inet it will load the default. do you think thats doable? the apache directory will change regularly
[18:56] <ali1234> also since i'm doing a battery powered device i used the A+... and ubuntu can't run on it
[18:56] <ali1234> so i'm waiting for the 3A to be released
[18:56] <baggednismo> :-(
[18:57] <baggednismo> luckily i had a pi2 sitting around because even the last ubuntu core cant be ran on pi3
[18:57] <ali1234> it should be working on 3 now i think... if you build the image youself
[18:58] <ali1234> but i have all the different models... it's just that only the A+ fits inside my device
[18:58] <ali1234> so i've tried running snaps on the 2B... but i didn't get very far
[18:58] <ali1234> and that's even with loads of fantastic help from the people here
[18:59] <ali1234> i'm sure LAMP would work fine though... it's very common
[18:59] <baggednismo> im concerned about persistent storage though
[19:00] <ali1234> not sure what happens if that gets corrupted
[19:00] <elopio> kyrofa: what's the tag in askubuntu? ubuntu-core?
[19:00] <saalen> how to resolve this snapcraft error on Arch (after reading the snapcraft.yaml): Could not find a required package in 'build-packages': "The cache has no package named 'make'" ?
[19:00] <kyrofa> elopio, there are so many now... you might be able to just use my filter, hold on
[19:01] <elopio> saalen: hey, snapcraft's build-packages are only for ubuntu. If you have lxc installed, you could do a cleanbuild.
[19:03] <kgunn> kyrofa: so are snapcraft.ProjectOptions basically the usr/lib/$ARCH dirs?
[19:03] <saalen> elopio: mmh, it is present in AUR and I read about it being ported to other distributions... so I gave it a try ;)
[19:03] <kgunn> kyrofa: sorry...context is the qt plugin
[19:04] <elopio> saalen: snapd is currently working in all the distributions. snapcraft not yet.
[19:05] <saalen> elopio: thx
[19:08] <kyrofa> kgunn, the ProjectOptions hold stuff like the target arch, number of parallel build jobs supported, etc
[19:08] <baggednismo> ok so the question of the day before i start building my snap. where is the persistent storage on core if any?
[19:08] <kgunn> kyrofa: ack..i was just trying to trace through that QT_SELECT would end up with env of /usr/lib/$ARCH/qt5/bin
[19:08] <kgunn> which if your stuff works, then it must
[19:09] <kyrofa> kgunn, basically they reflect command-line parameters that affect all plugins
[19:09] <ali1234> baggednismo: it is on a separate partition which is created at first boot... at least on the raspi
[19:09] <kyrofa> baggednismo, there are two environment variables: SNAP_DATA and SNAP_USER_DATA
[19:09] <kyrofa> SNAP_DATA is in /var/snap/<snapname>/<snapversion>, SNAP_USER_DATA is in HOME/snap/<snapname>/<snapversion>/
[19:10] <baggednismo> and what happend when the device gets rebooted repeatedly improperly? the data gets damaged and i will have to handle that in my snap?
[19:11] <baggednismo> i just gotta make sure that OS will always boot. I can handle the data that gets damaged as long as its not the OS
[19:13] <kyrofa> baggednismo, the OS and snap app themselves are read-only
[19:13] <kyrofa> baggednismo, so unless there's real damage,  you should be okay
[19:15] <kyrofa> kgunn, the QT_SELECT stuff is using qt as a build-package though
[19:15] <kgunn> kyrofa: oh, not runtime env
[19:15] <kyrofa> kgunn, indeed
[19:15] <kgunn> which is fine
[19:15] <baggednismo> define real damage? i have found a lot of my devices out there have random problems like all permissions got changed, services wont start, os just fails to boot all simply from powering the device off improperly. what would constitute "real damage"?
[19:17] <baggednismo> or are you jumt implying physical damage?
[19:27] <Shibe> why are ubutnu snaps so big?
[19:27] <Shibe> according to phoronix the libreoffice snap is 1.1GB
[19:27] <Shibe> will this size issue get better?
[19:35] <kyrofa> baggednismo, I was more talking about physical damage
[19:35] <kyrofa> Shibe, because snaps bundle their dependencies
[19:35] <baggednismo> ok, let me get into snap's then ;-) thanks for your help kyrofa
[19:37] <baggednismo> ali1234, i think we have an answer. I will be testing this over the next few weeks and hopefully report success
[19:38] <Shibe> kyrofa: yes but will anything be done to reduce the size in the future?
[19:38] <Shibe> like sharing dependencies between programs that require the same version?
[19:42] <ali1234> Shibe: we already have debs if you want a system that works that way
[19:43] <caraka> ^^
[19:43] <Shibe> ali1234: yes but there's the dependency hell thing
[19:43] <ali1234> yeah well you have to pick one or the other
[19:43] <Shibe> i mean like share libraries when both require the same version
[19:43] <caraka> no dependency hell if they are bundled.
[19:43] <caraka> The price is disk space
[19:43] <ali1234> snaps already share the basic platform
[19:43] <Shibe> caraka: but the snappy package is bigger than the combined size of the windows installer, a deb and an rpm of libreoffice
[19:44] <ali1234> it is possible that the platform may be expanded in the future
[19:44] <Shibe> caraka: and it's be problematic on mobile too since phones have much less storage than desktops usually
[19:44] <ali1234> storage is the least of your worries on phones
[19:45] <ali1234> if your phone is fast enough to run LO i bet it has 32GB as standard already
[19:45] <caraka> all true Shibe, but storage and power are increasing rapidly on phones, and the truly monstrous apps aren't quite the kind for phone
[19:47] <ali1234> like the nexus 6P... comes with 32GB, 64GB, or 128GB
[19:49] <Shibe> caraka: and there's also the issues of low-end computers or people dualbooting Ubuntu
[19:49] <ali1234> LO is an outlier anyway. most snaps are nowhere near that big
[19:49] <Shibe> usually they won't give the Ubuntu partition as much storage as the windows one does
[19:50] <caraka> All true Shibe, but then they can use the traditonal deb format and stay slim and light
[19:50] <Shibe> caraka: but deb's are annoying and you usually stay behind versions depending on your distro
[19:50] <Shibe> or your risk instabillity with arch and stuff
[19:50] <caraka> there are tradeoffs for each of the systems - size is one of them
[19:51] <ali1234> can you name a change made in the last release of LO?
[19:51] <Shibe> ali1234: what is LO?
[19:51] <caraka> no guarantee that outdated dependencies won;t get bundeled into snaps either
[19:51] <ali1234> libreoffice
[19:51] <Shibe> oh libreoffice
[19:51] <caraka> LibreOffice
[19:52] <Shibe> ali1234: uh libreoffice 5 took quite a while to appear on some distros
[19:52] <Shibe> for example, mint got it in 17.3, many months after 5 came out
[19:52] <ali1234> mint is a very silly place
[19:52] <caraka> snaps won't solve all issues - only create different tradeoffs
[19:53] <Shibe> ali1234: yeah but mainly because it's on Ubuntu 14.04 and dependencies are always tricky
[19:53] <Shibe> who knows whether upgrading this library could break something
[19:53] <caraka> same will happen with snaps
[19:54] <Shibe> caraka: but don't snaps get to decide which version of a library they want?
[19:54] <ali1234> Shibe: it's just a filesystem containing some files, ultimately
[19:54] <kyrofa> Shibe, there's a content-sharing interface that is in the planning stages. The plan is to use that for e.g. the kde runtime, or gtk, etc
[19:54] <Shibe> ali1234: yeah, but the developer knows that all users will be getting the same versions of libraries and hence it will work similarly across all distros
[19:54] <caraka> yes they do. And the same developers will make the same kind of decisions when they package for snap as they do for other things - sometimes for the better and sometimes for the worse
[19:55] <kyrofa> Rather, the plan is to be ABLE to use that. Devs don't have to
[19:55] <Shibe> what about gtk apps btw?
[19:55] <kyrofa> What about them?
[19:55] <ali1234> what people don't seem to realise is that this is actually quite a hard problem
[19:55] <Shibe> I used nix once, and each gtk app was a few hundred MB in size because they all downloaded the adwaita icon theme
[19:55] <ali1234> there's a lot of talk in the peanut gallery along the lines of "old school unix developers, so naive... i could do better than that"
[19:56] <ali1234> but when you actually try it, it's not as easy as it looks
[19:56] <caraka> young developers are sometimes too abstracted from the bare metal and think it's all plug and play
[19:57] <caraka> (says the old man)
[19:58] <kyrofa> Shibe, I think the point is, as caraka mentions, there's no silver bullet. There are always going to be tradeoffs
[19:58] <caraka> ^^
[19:59] <caraka> snaps will have their ecosystem and their appropriate use. But they won;lt be the be-all end-all
[19:59] <ali1234> platforms will be nice
[19:59] <ali1234> i mean... optional ones as mentioned above
[19:59] <Shibe> also how come the flatpak package is smaller than the snap?
[20:00] <Shibe> flatpak is somehow only 156mb
[20:00] <kyrofa> Shibe, because they have a runtime
[20:00] <Shibe> ok
[20:01] <ali1234> so... can i use PPAs when building a snap?
[20:01] <kyrofa> josepht, elopio I'm not able to duplicate the ROS failures in the example tests... is something weird about that environment?
[20:01] <kyrofa> ali1234, yes you can. snapcraft will use your sources
[20:01] <caraka> ali1234: my PPAs offer to build snaps now. I haven't tried
[20:02] <kyrofa> ali1234, oh, you mean build snaps in launchpad? Yes, you can do that as well
[20:02] <ali1234> i found this ppa with videocore libs: https://launchpad.net/~ubuntu-raspi2/+archive/ubuntu/ppa
[20:02] <ali1234> i want to put those libs into my snap
[20:02] <kyrofa> Ah, yeah, add the PPA to your system and snapcraft should use it
[20:02] <ali1234> kyrofa: i think you were right the first time
[20:02] <kyrofa> caraka, the LP snap builders are pretty handy. https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way
[20:02] <caraka> I'm still trying to bundle by hand beffore I ask launchpad to do it
[20:03] <kyrofa> Good idea
[20:03] <caraka> yeah. get it right at home before sending it out into the world
[20:05] <ali1234> i've got so many raspberry pis now that i'm having difficulty knowing which one is which
[20:05] <ali1234> i need to reflash one again then i'll see if i can get videocore stuff working in a snap
[20:06] <ali1234> that's where i got stuck last time
[20:10] <willcooke> kyrofa, did you push that new qmake plugin in to your feature/1574774 branch?  The version I'm looking at there says it's 4 days old?
[21:20] <allesz_> hi guys link http://www.snapcraft.io does not resolve for me
[21:22] <ArmOrAttAk> no dns entry for that
[21:22] <ArmOrAttAk> remove the www.
[21:23] <allesz_> ArmOrAttAk: thanks that did the trick
[21:46] <tsimonq2> jamiebennett: Hey, would you be able to contact someone about that? ^
[21:56] <jamiebennett> tsimonq2: wow, not sure what is going on there