[04:33] i am new to snappy ubuntu and wondering if i can setup my own snappy repo to host updates and also snappy images for raspberry pi 2? [04:35] i am currently using snappy ubuntu core 16.04 on my rpi2 right now. just to let you know. [04:36] i have been a ubuntu user since Ubuntu 9.04 came out. [04:38] any help is appreciated [04:40] i would like to start contributing back to the ubuntu community as both as a dev and a fellow ubuntu user. [04:52] anyone able to help me with my problem? i also have a webdm on snappy ubuntu problem as when i go to my localip of my raspberry pi 2 it doesn't show on 16.04LTS snappy core [04:55] i thought using this irc channel would provide faster answers after searching the internet for approx 24 hours i find the forums are a tad bit slow at answering than on irc === chihchun_afk is now known as chihchun [08:05] good morning [08:11] good morning dholbach! [08:11] salut didrocks === john-mca` is now known as john-mcaleely [09:59] Good morning all! Happy Thursday, and happy Battery Day! 😃 [10:28] When I upload a snap to the store, I have to add a release. rolling-personal, rolling-core and 15.04-core. i made the snap on 16.04. which is that? [10:30] Good morning snappy, what is the best way to get snapcraft and start building a snap for 16.04? [10:30] is there a ppa or should i clone from Git? [10:34] there's a ppa longsleep [10:35] popey: that one looks good: https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily [10:56] longsleep: get xenial or the snapcraft ppa [10:56] longsleep: install snapcraft and look at snapcraft examples [10:56] i think you need xenial in any case, dont you ? [10:56] longsleep: the examples are in snapcraft source tree, you can just clone that from github as a start [10:56] ogra_: oh, good point [10:57] longsleep: so you do want to use xenial for 16.04, 16.04 requires 16.04 to develop [10:57] so use a chroot (or the traditional ubuntu-core tarball) [10:58] ogra_: well i got the vagrant image but ran into bug #1546108 [10:58] bug 1546108 in livecd-rootfs (Ubuntu) "Latest Vagrant box for Ubuntu Xenial is failing to boot" [Undecided,Confirmed] https://launchpad.net/bugs/1546108 [10:58] i can chroot as well but that requires root which i would like to avoid [10:59] ogra_ HI i will use your application to start with lighttpd but do you have an conf file? [11:01] noizer, i use a script to generate both configs (config.sh) out of the default.yaml file [11:02] and indeed the startup wrapper script [11:08] zyga: All right, i have 16.04 now gbarbieru/xenial Vagrant box seems to work [11:09] ogra_: can i still rely that python3 and openssl binaries are available in 16.04 base snappy system? [11:10] ok ready to go root@vagrant:~# snapcraft -v [11:10] 2.2.2 [11:11] ogra_ is it possible to use an conf file? [11:12] noizer, sure, just ship it and point the binary to it [11:12] longsleep, you could never rely on that .... though the new snapcraft makes it trivial to ship your interpreter [11:12] ok I will first make my conf file and then try it. [11:12] ogra_: ok thanks - i will check it out [11:13] thx ogra_ [11:14] longsleep, thats for snapcraft 2.1 (so, outdated atm) http://paste.ubuntu.com/15106152/ but that should give you an idea [11:14] the last three lines simply pull in the py2 interpreter [11:14] (it allows indeed more complex things too) [11:14] yeah i guess it does [11:15] thanks - i need to find a suitable version of Go first - is it in the repositories nowadays? [11:15] not a go user, so i dont know :) [11:16] https://launchpad.net/ubuntu/+source/golang/2:1.6~rc2-0ubuntu1 [11:16] looks like that is in the archive [11:16] * longsleep looks [11:17] well apt-cache search golang-go-linux-amd64 gave nothing, lets try golang-go and see what that installs [11:18] https://launchpad.net/ubuntu/+source/golang/2:1.6~rc2-0ubuntu1/+build/8984117 [11:18] looks like it is just "golang" [11:19] probably packaging has changed, does not look too bad [11:23] ogra_: looks really good vagrant@vagrant:/vagrant/Dev/spreed-webrtc$ file bin/spreed-webrtc-server [11:23] bin/spreed-webrtc-server: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped [11:23] hooray! [11:24] yay [11:24] ricmm, ^^^ ! [11:33] longsleep: excellent :) [11:42] 19:41 -!- magizian [pan@162-202-67-158.lightspeed.livnmi.sbcglobal.net] has quit [Client Quit] [11:42] 19:41 -!- magizian [pan@162-202-67-158.lightspeed.livnmi.sbcglobal.net] has quit [Client Quit] [11:43] hmm [11:43] sorry :) [11:43] zyga, yes ? [11:44] hah [11:44] * ogra_ was wondering what you wanted to tell us :) [11:45] "where has my focus gone to" [12:06] * zyga digs into cgroups [12:06] whee [12:08] mhm snapcraft does not work when used on the /vagrant mount - not really a problem but it would be nice if it would work :) [12:08] [Errno 1] Operation not permitted: '/vagrant/Dev/spreed-webrtc-snap/parts/glue/install/ssleay.cnf' -> '/vagrant/Dev/spreed-webrtc-snap/stage/ssleay.cnf' [12:13] ogra_: do you know if the make plugin for snapcraft can run a script after clone? like ./autogen.sh [12:14] jdstrand: I'd like to make some modification to ubuntu-core-launcher, I'll ping you later about that [12:14] ogra_: ah seems i have to ue the autotools plugin [12:14] jdstrand: I'd like to sync with you as soon as you are around, it's important and related to the sprint [12:23] ricmm: Are you there? I got the problem that snapcraft passes a bunch of LDFLAGS in a format which seems to be wrong for the go toolchain [12:25] did you use the go plugin actually ? [12:27] ogra_: no, the autotools plugin, but i can fix it in the Makefile.am [12:27] ogra_: i guess it is our fault and not snapcraft to blame :) [12:28] or sergiuens ;) [12:28] Staging spreed worked now [12:32] jdstrand: so (in case you read the backlog), hw-assign doesn't work with /dev/i2c-1 for the same reason it didn't work with skills, still no permission to /dev/i2c-1 -- it's in the control group, but it's just not writable and the app doesn't run as root [12:33] jdstrand: unless there's a logic hole somewhere I think we have to accept to chmod devices [12:33] jdstrand: what confuses me is that other people make similar stuff and for them it works but they were always background commands, running as root, so getting the permission [12:35] ogra_: btw, snappy-tools where do i get it from for xenial? [12:36] (i have ppa:snappy-dev/tools) [12:36] longsleep, hmm, they should be in the archive ... if not, they are definitely in https://launchpad.net/~snappy-dev/+archive/ubuntu/image [12:37] oh, wait ... -tools isnt in there [12:37] i guess the above is correct [12:38] what exactly? /tools has not much builds for xenial yet [12:38] and /image does not seem to have it either [12:38] * ogra_ has honsetly not used -tools since he switched to xenial and snapcraft 2.x ) [12:38] how do you sideload? [12:39] manually? [12:39] i wanted to use snappy-remote or something [12:39] Good morning [12:41] ogra_: seems i accidently created an app instead of a service :/ [12:41] * longsleep searches for a service example [12:42] longsleep, see my mycroft examplle from above [12:42] ah just add the daemon key? === chihchun is now known as chihchun_afk [12:42] yeah, services are dead .... they are all apps now === chihchun_afk is now known as chihchun [12:43] binary vs daemon is the difference [12:43] ok got it [12:46] ogra_: what about the caps? Seems like snapcraft 2.2 does not like it like it is in your example [12:46] probably the uses key from the examples [12:46] i think i get it from the example [12:46] * longsleep tries it [12:47] longsleep, thats the new skills system i'm completely unfamiliar with [12:47] zyga might be able to point you to something perhaps [12:47] https://github.com/ubuntu-core/snapcraft/blob/master/examples/mosquitto/snapcraft.yaml [12:47] using that example [12:47] (caps are gone with 2.2+ ) [12:47] yeah, that looks about right [12:48] longsleep: no caps [12:48] longsleep: use the migration-skill please [12:48] longsleep: and tell me about the permissions your snap needs please [12:48] * zyga -> lunch [12:50] zyga: i now use [network-listener, network-service], as the snap only listens in a bunch of ports and reads/writes to its own directories [12:51] ogra_: ok i have a service now, only the config hook needs fixing and then i think i might have it [12:52] wow, that was fast [12:52] you rock :) [12:52] well, KeyError app in the config hook still to resolve :) [13:03] ah it is not even a problem in the config hook, i am just missing the config.in file in the snap === chihchun is now known as chihchun_afk [13:08] longsleep: nice! [13:33] hmm [13:34] does anyone have an idea why we ship Qt libs in our rootfs ? http://people.canonical.com/~ogra/core-image-stats/20160218.changes [13:35] hehe [13:35] ogra_: yes i know [13:35] i lokoed it it just yesterday [13:35] i think it can be fixed by seed [13:35] we have the ubuntu-download-manager still in [13:35] or somethign along that line used qt [13:36] eek [13:36] yeah, that shoul drally go [13:36] just unseed it and see if world explodes :) [13:36] hmm, how do I start a background service in a snappy way? [13:36] *should really [13:36] sure it should [13:36] dont think we want to remove it though before next week :) [13:36] does snappy do the download on its own for snaps ? [13:36] yes i think thats all old [13:37] ogra_: yes [13:37] cool then [13:37] just leftover from old world [13:37] feel free to double check if you find any other rdepend [13:37] so we are safe [13:37] yeah, there is more system-image stuff still seeded i think [13:37] (and hacks in the build system to set that up) [13:37] sudo reboot [13:38] damn ... EFOCUS :P [13:38] * ogra_ blames zyga ... he started that :P [13:40] Feb 18 13:40:23 localhost.localdomain ubuntu-core-launcher[3888]: failed to create user data directory. errmsg: Permission denied [13:40] hehe [13:40] so it seems we still have the permission denied issue, this time for services [13:40] so yay, more stuff to debug [13:41] (this is with the applied workaround) [13:44] kyrofa: ^^ any chance you know how to work around this? [13:44] * kyrofa reads scrollback [13:44] ogra_: after i have fixed a bug in the config hook totally unrelated to snappy it actually works on 16.04 [13:45] zyga, did jdstrand get that new profile out? [13:45] longsleep, whee, awesome ! [13:45] zyga, as for working around it, the same workaround he suggested before should work [13:45] Oh wait.. you said you're using that workaround [13:46] zyga, it was /** r or something, wasn't it? [13:47] zyga, check for apparmor denials? [13:47] (make sure this is the same issue) [13:48] zyga, also, you haven't rebooted since loading in that temporary profile, right? Or you've loaded it again? [13:49] zyga, alright, I will now take you up on making an edge image for me, if you have a minute. Let me take it for a spin, see what's going on [13:50] kyrofa: yes (I don't know if new image was built) but note I did apply the same workaround myself [13:51] kyrofa: how do I check apparmor denials? [13:51] zyga, either with snappy-debug or just the syslog [13:51] kyrofa: previously I manually straced everything, I don't know how to do that when systemd does activation [13:51] ok, I'll check [13:51] zyga, yeah you don't need to-- it's not that complicated [13:52] ogra_ how does I make some rewrite in lighttpd. it does not work from me [13:54] noizer: rewrite/ [13:55] zyga do you know something about nginx on snappy? [13:57] noizer: no, I was just wondering what you were asking about [13:58] Feb 18 13:57:55 localhost.localdomain ubuntu-core-launcher[4831]: failed to create user data directory. errmsg: Permission denied [13:58] Feb 18 13:57:55 localhost.localdomain kernel: audit: type=1400 audit(1455803875.084:81): apparmor="DENIED" operation="mkdir" profile="/usr/bin/ubuntu-core-launcher" name="/root/snaps/" pid=4831 comm="ubuntu-core-lau" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 [13:58] kyrofa: ^^ [13:58] seems like the same old problem [13:58] just root instead of $HOME [13:58] I'll apply the same workaround [13:58] kyrofa: it'd be good to check if jdstrand fixed both root and $HOME [13:59] lighttpd is a webserver but ogra_ worked with it before and i thought he could help me out with some problems [13:59] noizer, you likely need to enable the module first [13:59] zyga, I thought the workaround was /** r though, no? [13:59] somewhere in the config [13:59] zyga, oh, the write though [13:59] zyga, yeah you can take a peek inside the profile real quick if you want [14:00] kyrofa: I only have the workaround [14:00] * zyga looks at vanilla profiles [14:00] mod_rewrite is enabled ogra_ [14:00] http://redmine.lighttpd.net/projects/1/wiki/Docs_ModRewrite#Description [14:02] zyga, /etc/apparmor.d/usr.bin.ubuntu-core-launcher [14:03] * ogra_ grumbles about systemd log output [14:03] ..."Failed with result 'exit-code'." [14:03] zyga, though have you built another image since that was released? (or is it included in the OS snap...) [14:03] why cant it actually write the exit code in there [14:03] * ogra_ shakes head [14:08] zyga, yeah the apparmor profile uses HOME, which should be set correctly to /root. So I suspect you simply don't have the update [14:08] kyrofa: I have the workaround for sure so something else might be broken [14:08] * zyga returns to checking what [14:09] zyga, if you can upload an image somewhere I'd be happy to check it out [14:09] kyrofa: it's the stock image I built before, I don't want to re-flash it because I use classic dimension heavly for skill development [14:10] kyrofa: looking at u-c-l profile, where does it have access to $HOME/snaps? [14:10] zyga, makes sense [14:10] 14:58 < zyga> Feb 18 13:57:55 localhost.localdomain kernel: audit: type=1400 audit(1455803875.084:81): apparmor="DENIED" operation="mkdir" profile="/usr/bin/ubuntu-core-launcher" name="/root/snaps/" pid=4831 comm="ubuntu-core-lau" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 [14:11] zyga, check the last few lines of the profile (83 and on) [14:12] kyrofa: I don't see anything that affects $HOME in the profile [14:12] kyrofa: http://paste.ubuntu.com/15109503/ [14:12] kyrofa: that's my hacked copy [14:12] zyga, yeah you don't have the update then. Here, use this: [14:12] kyrofa: ah, perfect, thanks [14:12] * zyga wonders if he can just update snappy then [14:13] update is not released? [14:13] ubuntu-core 2016-02-12 16.04.0-8.armhf canonical [14:13] zyga, http://paste.ubuntu.com/15109578/ [14:13] trying [14:13] zyga, I think that's the OS snap... right? Which needs it needs to be rebuilt before the update is actually distributed? [14:14] i'll try to get to that today and bump all os snaps ... [14:14] which means it needs* [14:14] (prob iis that mvo didnt pick the same version for all of them so its all manual hackery ) [14:14] * kyrofa is still a little fuzzy on the kernel/os/magic snaps [14:15] kyrofa: all good, thanks [14:15] zyga, yeah? Working now? [14:15] kyrofa: I found unrelated bugs in snappy (it seems that "snappy service" blindly tries to run crazy stuff that's not a service [14:16] kyrofa: ) but starting the systemd unit manually makes things go [14:16] kyrofa: so I have a skill-based service in operation :-) [14:16] zyga, ooo, that's fun. What type of crazy stuff? [14:16] kyrofa: background piglow [14:16] (make sure you log those!) [14:16] kyrofa: Feb 18 14:14:07 localhost.localdomain ./snappy[5012]: main.go:50: DEBUG: [./snappy service start] failed: unable to start pi2-piglow's service foreground: [start pi2-piglow_foreground_INANbBEQgddX.service] failed with exit status 6: Failed to start pi2-piglow_foreground_INANbBEQgddX.service: Unit pi2-piglow_foreground_INANbBEQgddX.service failed to load: No such file or directory. [14:16] kyrofa: note: foreground is _not_ a background command/service [14:17] kyrofa: the source for this snap is at github.com/zyga/snappy-pi2-piglow [14:17] * zyga pushes new stuff [14:17] done [14:18] (now done) [14:18] zyga, haha, I was gonna say... [14:18] Feb 18 14:14:07 localhost.localdomain ./snappy[5012]: main.go:50: DEBUG: [./snappy service start] failed: unable to start pi2-piglow's service foreground: [start pi2-piglow_foreground_INANbBEQgddX.service] failed with exit status 6: Failed to start pi2-piglow_foreground_INANbBEQgddX.service: Unit pi2-piglow_foreground_INANbBEQgddX.service failed to load: No such file or directory. [14:18] zyga, yeah, how does foreground turn into a service? [14:18] er, damn paste [14:18] kyrofa: it doesn't-- there is no .service file for it [14:19] I don't know the service generation code by heart, maybe something is wrong there [14:19] zyga, huh... but the snap.yaml looks okay? [14:20] kyrofa: let's see [14:20] kyrofa: yes [14:21] kyrofa: I wouldn't worry yet, this might be some old/new snappy combination [14:21] I may have used old (non trunk) version of snappy to instal the snap perhaps [14:21] zyga, probably-- I was through all that code recently and it seemed okay [14:21] kyrofa: if it happens after clean reproduction I'll start chasing it [14:21] zyga, sounds good! [14:25] who can I poke to review / approve squashfs app in the store? [14:25] pi2-piglow.zygoon revision 2 [14:26] ricmm, ogra_ https://github.com/strukturag/spreed-webrtc-snap - works fine for me and should build fine on arm64 as well if you run snapcraft there [14:27] ricmm, ogra_ it currently get the code from develop branch as i had to fix a variable conflict in the Makefile [14:27] * zyga must say that the piglow executable, stripped, is comparable in size to the side of .yaml/changelog ;) [14:48] * jdstrand reads backscroll and sees it is resolved [14:48] yes, ubuntu-core-launcher is part of the os snap. if an os snap hasn't been generated in a while, the fix won't be there [14:49] kyrofa: and the workaround rule was '/**/ rw,' - the trailing '/' is important :) ( though /** rw certainly would've worked too, but basically invalidated confinement :) [14:50] as workarounds go, it would've been effective though :) [14:50] jdstrand, heh. Yeah, all resolved :) [14:51] jdstrand, good morning by the way! [14:51] zyga: as for chmod-- this needs architects input. sure, a chmod will make it 'just work' for the ubuntu user, but there are a lot of implications in that [14:51] kyrofa: hi! [14:52] zyga: my gut feeling is that a chmod for the device for the user and a skills assignment to the snap are conflating two different things [14:54] we don't have a strong story of users and groups on snappy yet and that probably needs to be discussed [14:54] jdstrand: yep, I think this needs proper design [14:54] cool [14:54] jdstrand: hmm, perhaps in this case we could cheat by putting that device in the cgroup (as we do) and chmodding it *there* [14:54] so the user doesn't get it [14:54] but the app does [14:54] I'm happy to be part of that conversation, but I think tyhicks should also be a part of it [14:55] jdstrand: ok, let's do it [14:56] zyga: I think we want pitti to have input too [14:56] jdstrand: shall I open a bug on this to track it? [14:57] I think that makes sense. something about requiring sudo for certain devices after skills assignment [15:09] longsleep, thanks, i'll try it out before EOD [15:15] ogra_: For comparison, this is the full output for snapcraft snap for me: http://paste.ubuntu.com/15111240/ [15:15] thx [15:15] ogra_: i am not sure about the dependencies, i added some but might have missed autoconf or something else [15:16] k [15:34] kyrofa: can you do a sanity check please [15:34] kyrofa: install v2 of the p2-piglow.zygoon snap from the github url I mentined earlier [15:34] kyrofa: and see what services you have [15:34] ubuntu@localhost:~$ sudo ./snappy service status [15:34] Snap Service State [15:34] pi2-piglow background enabled; loaded; failed (failed) [15:34] pi2-piglow foreground ; not-found; inactive (dead) [15:34] !? [15:35] zyga, I don't actually have an image where that stuff will work :P [15:37] kyrofa: looking at the service code [15:37] kyrofa: the condition to see if something is a service is bogus IMHO [15:37] if serviceName != "" && serviceName != name { [15:37] continue [15:37] } [15:37] everything else is a service [15:37] what? [15:38] zyga, wait... shouldn't that be using the daemon keyword? [15:38] in other words _everything_ is a service [15:38] kyrofa: exactly [15:38] kyrofa: I'll fix that [15:45] https://github.com/ubuntu-core/snappy/pull/495/files [15:51] revoke works [15:51] ogra_: What would i select to upload a snap to the store for 16.04? rolling-core? [15:51] now I only want to know which signal does systemd send to stop an app [15:51] (a service) [15:52] so that piglow can react to it by shutting down the lights before it goes [15:52] longsleep, yeah [15:55] ah, that's SIGTERM [15:55] nice [15:58] ogra_: mhm automated review failed, (NEEDS REVIEW) squashfs pkg lint_is_squashfs [15:58] and one warning: unknown entries in package.yaml: 'apps,description,summary,uses' lint_snappy_unknown [15:59] longsleep, sounds like a false positive ... beuno ^^^ ? [16:00] Snapping spreed-webrtc_0.24.11-1_arm64.snap [16:00] FATAL ERROR:Mksquashfs requires more physical memory than is available! [16:00] * ogra_ cries [16:00] lol [16:01] how much memory did you give that box? [16:01] * ogra_ hopes a swapfile will be respected [16:01] ogra_, it will [16:01] cool ! [16:01] longsleep, its real HW with 1GB [16:01] ah [16:01] ogra_, it's the only way my snaps build on the arms I have here-- a 16GB swapfile :P [16:02] wow, thats bad [16:02] my vagrant box has 758352 memory and the same as swap and it worked to build [16:03] ogra_, and that's a slight lie. I could make with no -j parameter and it would need less, but then it would take days [16:04] ogra_: what hardware do you actually use? [16:04] longsleep, dragonboard [16:04] ah ok cool [16:04] ogra_, longsleep, it is false positives, will ve fixed soon [16:05] kyrofa, ogra_, you can build snaps on Launchpad! [16:05] beuno, indeed, and I plan on figuring that all out very soon [16:05] beuno, but we're doing arm64 [16:05] beuno, launchpad only has 32-bit arms, no? [16:05] kyrofa, hmm, do you use chroots when building ? [16:06] ogra_, no, why? [16:06] kyrofa, no, LP builds our rootfses :) [16:06] so there are also arm64 machines [16:06] ogra_, ah, excellent! [16:06] kyrofa, because i just noticed 1GB is fine ... i just forgot to mount /proc and /sys [16:06] Ah! [16:06] kyrofa, it as arm64 for snaps :) [16:13] longsleep, works great ! [16:13] ogra_: fantastic! [16:13] ogra_: thans for testing [16:13] +k [16:13] thansk for building ! [16:17] so sad the ubuntu phone browser doesnt work with it :( [16:18] what html/javascript engine does that browser use? [16:18] not sure ... popey ^^^ do you know ? [16:19] not v8 afaik [16:19] it's chromium, so blink. [16:19] blink is the renderer [16:20] and that all we use from chromium afaik ... the js engine was something different [16:20] if its chromium including v8 and the media enginges in the back then it could work with if recent enough [16:20] i'm pretty sure it is neither [16:21] currently we support Chromium 38 or newer [16:21] it might somewhat down to Chromium 30 [16:22] work somewhat [16:22] * ogra_ asked in #ubuntu-touch [16:22] we onyl use blink (and even re-work it for Qt) [16:23] "Mozilla/5.0 (Linux; Ubuntu 14.04 like Android 4.4) AppleWebKit/537.36 Chromium/35.0.1870.2 Mobile Safari/537.36" [16:23] thats OTA-9 [16:23] so chromium 35 [16:23] right, doesnt talk about js [16:23] well, Chromium 35 would be too old in any case to connect to any recent browser [16:24] nor is it chromium beyond the renderer ... thats like using gecko with all your own stiff and showing firefox in the UA :P [16:24] ok, seems i was wrong, it is actually v8 [16:25] question is if all the media extensions are compiled in including the capture code [16:25] webrtc for that matter [16:25] no [16:25] dtls [16:25] srtp :) [16:25] neither of them because they would have to be hooked into the toolkit [16:25] whicfh isnt dont yet [16:25] (my webrtc bug is open since 2.5y ... eventually it will come though :) ) [16:26] *isnt done [16:27] we have basic camera and mic access working i think ... just no webrtc integration yet [16:28] i wonder how much would work if we cheated inthe UA though === charles_ is now known as charles [16:35] ogra_: what do you mean cheating in the UA? [16:35] ogra_: we are doing feature detection for pretty much everything, so the UA would not help [16:35] longsleep, telling the server it is chromium 38 [16:35] ah, k [17:16] I just tried Snappy for the first time on a NUC. I like where the project is headed, the integration of a stable upgrade image A->B (and back) is a great step forward. It takes the best part of CoreOS and grafts it into a Ubuntu world. Thanks! The "snappy" package manager is headed in the right direction as well, but I have to wonder (and I'm sure I'm [17:16] not the first to ask this) why not simply adopt the Nix package manager format? Why invent yet another thing when Nix seems to have all the bases covered that snappy would like to address (and more)? [17:17] does nic integrate with apparmor and seccomp ? [17:17] *nix [17:17] does it use squashfs files as readonly filesystems of its packages ? [17:18] (i never heard of Nix, just curious) [17:18] http://nixos.org/nix/ [17:19] seems to onyl be a package manager though ... you should take a look at snapcraft too if you look at snappy :) [17:19] http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html is a good evaluation by a Nix maintainer of Snappy [17:20] snappy (the package manager) is very deeply integrated with the OS too ... it was essentially built around all the things we learned from the phone OS [17:21] So, I'm not saying "ditch all of Snappy" I'm saying "steal liberally the ideas from Nix and integrate them into Snappy" especially the way that Nix versions and inter-relates package dependencies (sim-link tree with a hash rather than version number used to separate packages). [17:23] I used to work at Amazon/AWS and there we had a similar (to Nix) way of managing package dependencies in deployment (called Brazil) with versioned trees of inter-dependent packages. [17:23] I like that deep integration ogra_ that makes sense. [17:23] If my mom or some other non-technical person is ever going to experience Ubuntu Desktop then we'll need that level of integration. [17:24] I'm sure that the phone project pushed the developers hard in the direction of super simple/reliable package distribution. [17:25] well, snappy does effectivbely not have any dependencies [17:25] you bundle everything [17:27] (you can have library snaps, but only within your own namespace) [17:27] ogra_ isn't that going to hammer memory as each different process brings its own copy of glibc along with it? [17:27] well, glibc is on the system. as long as you dont differ too much you dont really need to ship it (but you can indeed) [17:28] but yeah, there is surely some duplication that will eat some diskspce at least [17:28] my point is more generally related to shared libraries that will, in a snappy world, be duplicated and not shared [17:28] and RAM and cache lines [17:29] and that's power and performance lost [17:29] no? [17:29] right, yxou should just build static binaries if you can :) [17:29] er, I disagree [17:29] you prefer shared libs that arent shared ? [17:29] how is that not going to introduce the same problem? [17:29] no :) [17:30] either way, the confinement wont allow apps to share resources on that level === rickspencer3_ is now known as rickspencer3 [17:31] (unless the libs come from your own namespace ... i.e. libreoffice.ogra wouldnt have to ship boost but could consume libboost.ogra) [17:31] In the Nix (and Brazil) world a shared lib can indeed be shared by many other packages iff those packages all required the same version/config/build/dependencies that went into building glibc [17:31] So, where there is overlap the shared libraries are indeed shared [17:31] right, then we are back at dpkg :) [17:31] not really. [17:31]