[01:33] PR snapcraft#944 closed: Release changelog for 2.23 === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:11] PR snapd#2403 opened: store: fix unhandled error from io.Copy() in download() [09:53] very excited about snap [09:53] still dont understand it fully [09:54] thinking about what would happen with big applications like DEs [09:54] im guessing some of it will be global ... but temporarily? [09:55] will it be snap and the normal global system in conjunction [09:55] or will everything be snap [09:55] i wonder [09:56] but giving applications its jar and water to live is an idea ive always thought why it was not being implemented [09:56] idk [19:15] 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] 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] for highly important libraries involving encryption etc there will be platform snaps which will provide library sharing [19:30] and of course the core platform [19:30] but you can still get bitten by something obscure [19:32] that's what i feared [19:36] makes me think, this among other things, that maybe "snapifying" a system maybe not the way to go .. except for certain cases [19:36] like video games make sense [19:36] but at the same time you can have something like steam [19:45] but on the other hand it does have some benefits, like less prone to dependency hell and quicker updates === JanC_ is now known as JanC [19:57] 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] 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] 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] 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] madprops: There are central hosts, stores. [20:09] madprops: Your "snap" system has one in mind when you install. [20:10] madprops: And your machine ensures everything is up to date by checking its store every so often. [20:10] who mantains these stores monetarily? [20:12] madprops: You, if you develop a snap-using OS. Ubuntu has one. Probably others. [20:12] I use Ubuntu Core, so my machines ask Ubuntu's store. [20:15] 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] https://myapps.developer.ubuntu.com/ [20:19] nice [20:20] what architectures do you build for? [20:20] can snapcraft do cross-builds yet? [20:22] ali1234: Some parts have cross-build support, but not all. Some will be tricky. I build for x86, amd64, armhf, & amr64 [20:23] 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] But I don't know a lot of that. [20:24] i find the launchpad workflow too slow for development [20:25] it would probably be okay once i actually get things working [20:26] Yeah, Launchpad isn't your development environment. [20:26] yeah... unfortunately my target is raspberry pi [20:26] so native builds are even slowed [20:28] ali1234: "snapcraft cleanbuild" runs lxc. Making that be a different architecture should be possible. [20:28] i couldn't get cleanbuild to even work for host architecture [20:28] Just some other wrapper to an emulator. [20:28] it just gives me apt errors [20:29] http://askubuntu.com/questions/787258/internal-server-error-when-retrieving-files-from-the-archive-in-lxd [20:30] http 500 from an archive? Sounds funny. Are you using a proxy or something? [20:32] no [20:53] ali1234: Well, that would be a problem common to every Ubuntu user everywhere, not specific to snapcraft. [20:53] it only happens with snapcraft [20:53] specifically, only with lxc it seems [20:53] also i didn't post that question [20:54] so it isnt just me [23:01] Hi. I have a qustion regarding building with autotools. [23:01] I want to instruct snapcraft to build witin the directory build_unix. [23:02] But the configure.ac file is in the directory dist. [23:02] I tried to use source-dir and specified dist. [23:03] It found the configure file but then it would say that I should not build in this directory. [23:15] 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.