[01:33] <mup> PR snapcraft#944 closed: Release changelog for 2.23 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/944>
[07:11] <mup> PR snapd#2403 opened: store: fix unhandled error from io.Copy() in download() <Created by mvo5> <https://github.com/snapcore/snapd/pull/2403>
[09:53] <madprops__> very excited about snap
[09:53] <madprops__> still dont understand it fully
[09:54] <madprops__> thinking about what would happen with big applications like DEs
[09:54] <madprops__> im guessing some of it will be global ... but temporarily?
[09:55] <madprops__> will it be snap and the normal global system in conjunction
[09:55] <madprops__> or will everything be snap
[09:55] <madprops__> i wonder
[09:56] <madprops__> but giving applications its jar and water to live is an idea ive always thought why it was not being implemented
[09:56] <madprops__> idk
[19:15] <madprops> I saw a question that made me wonder, maybe someone can explain it to me "How do I verify that all 300 copies of libgnutls.so are patched and protected against the latest vulnerabilities?"
[19:28] <ali1234> madprops: there is no good answer to that question, in the general sense. it has always been a problem for any type of app bundling
[19:29] <ali1234> for highly important libraries involving encryption etc there will be platform snaps which will provide library sharing
[19:30] <ali1234> and of course the core platform
[19:30] <ali1234> but you can still get bitten by something obscure
[19:32] <madprops> that's what i feared
[19:36] <madprops> makes me think, this among other things, that maybe "snapifying" a system maybe not the way to go .. except for certain cases
[19:36] <madprops> like video games make sense
[19:36] <madprops> but at the same time you can have something like steam
[19:45] <madprops> but on the other hand it does have some benefits, like less prone to dependency hell and quicker updates
[19:57] <qengho> madprops: I expect there will be a kind of scanner for out of date dependencies in packages, and shame as the major motivator for people to fix their bugs.
[19:59] <qengho> madprops: The great thing about snaps is that a broken package can only harm the things it is allowed touch, which is not very much -- pretty much only what it makes.
[20:01] <qengho> madprops: As always, you have to trust the person who makes the code. With snaps, there is no third person (a packager) who has to care enough also.
[20:06] <madprops> qengho, how do snap hosting works? do developers make a snap and publish it in some centralized server or they host it themselves?
[20:09] <qengho> madprops: There are central hosts, stores.
[20:09] <qengho> madprops: Your "snap" system has one in mind when you install.
[20:10] <qengho> madprops: And your machine ensures everything is up to date by checking its store every so often.
[20:10] <madprops> who mantains these stores monetarily?
[20:12] <qengho> madprops: You, if you develop a snap-using OS. Ubuntu has one. Probably others.
[20:12] <qengho> I use Ubuntu Core, so my machines ask Ubuntu's store.
[20:15] <qengho> I also upload a few packages to Ubuntu's store. I push to a Launchpad branch and it deposits compiled packages (for four architectures!) into my snap-package's Proposed channel in a few minutes. I make sure it looks right and then promote it to Stable channel in the store.
[20:15] <qengho> https://myapps.developer.ubuntu.com/
[20:19] <madprops> nice
[20:20] <ali1234> what architectures do you build for?
[20:20] <ali1234> can snapcraft do cross-builds yet?
[20:22] <qengho> ali1234: Some parts have cross-build support, but not all. Some will be tricky. I build for x86, amd64, armhf, & amr64
[20:23] <qengho> ali1234: Now that there's a virtual-machine build process, I suspect the built-in cross-build will die and we'll just emulate the other arch and run "native" there.
[20:23] <qengho> But I don't know a lot of that.
[20:24] <ali1234> i find the launchpad workflow too slow for development
[20:25] <ali1234> it would probably be okay once i actually get things working
[20:26] <qengho> Yeah, Launchpad isn't your development environment.
[20:26] <ali1234> yeah... unfortunately my target is raspberry pi
[20:26] <ali1234> so native builds are even slowed
[20:28] <qengho> ali1234: "snapcraft cleanbuild" runs lxc. Making that be a different architecture should be possible.
[20:28] <ali1234> i couldn't get cleanbuild to even work for host architecture
[20:28] <qengho> Just some other wrapper to an emulator.
[20:28] <ali1234> it just gives me apt errors
[20:29] <ali1234> http://askubuntu.com/questions/787258/internal-server-error-when-retrieving-files-from-the-archive-in-lxd
[20:30] <qengho> http 500 from an archive? Sounds funny. Are you using a proxy or something?
[20:32] <ali1234> no
[20:53] <qengho> ali1234: Well, that would be a problem common to every Ubuntu user everywhere, not specific to snapcraft.
[20:53] <ali1234> it only happens with snapcraft
[20:53] <ali1234> specifically, only with lxc it seems
[20:53] <ali1234> also i didn't post that question
[20:54] <ali1234> so it isnt just me
[23:01] <torusJKL> Hi. I have a qustion regarding building with autotools.
[23:01] <torusJKL> I want to instruct snapcraft to build witin the directory build_unix.
[23:02] <torusJKL> But the configure.ac file is in the directory dist.
[23:02] <torusJKL> I tried to use source-dir and specified dist.
[23:03] <torusJKL> It found the configure file but then it would say that I should not build in this directory.
[23:15] <torusJKL> The error is: Berkeley DB should not be built in the top-level or "dist" directories. Change directory to the build_unix directory and run ../dist/configure from there.