[01:02] <elopio> 
[01:04] <tsimonq2> hello :)
[01:07] <elopio> sergiusens: that one fails because on the all-snaps image something left an apt running, so the others couldn't install things.
[01:07] <elopio> weird. But I just need a  little time to make that error better. Hopefully tomorrow.
[01:09] <tsimonq2> elopio: hey, would you happen to have time to look at https://github.com/ubuntu-core/snapcraft/pull/567 ? I'm working on it right now and I would like some feedback on something.
[01:09] <tsimonq2> s/something/two things/
[01:10] <elopio> tsimonq2: hey there. I can take a look in ~30 mins.
[01:10] <tsimonq2> elopio: alright, I'll be around, thank you
[01:10] <elopio> thanks to you
[01:13] <sergiusens> elopio is it good to go then?
[01:13] <elopio> sergiusens: no, it needs a retry. Many tests failed. http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1056/testReport/
[01:20] <sergiusens> Boo
[01:20] <sergiusens> Let me update branch
[01:22] <tsimonq2> elopio: because I already knew it would get pointed out that Subversion was not with the other version control systems, I just rearranged it and committed :D
[05:22] <jdstrand> beuno, roadmr: what sergiusens said-- we don't allow calling snap.app because that invokes the launcher and to be able to invoke the launcher you need to grant permissions to setup the sandbox and if you have the permissions to set the sandbox you can shange your own sandbox
[05:22] <jdstrand> change*
[06:07] <zyga> slangasek: ohhh
[06:07] <zyga> slangasek: I see, this is the problem when we fork projects and move them around :/
[06:08] <zyga> slangasek: I'll bump the version to 1.0.30 with an appropriate message
[06:08] <zyga> slangasek: but we should really move away from lp:ubuntu-core-launcher towards snapcore/snap-confine
[06:15] <zyga> mvo: ^^ FYI
[06:18] <mvo> thanks zyga
[06:19] <slangasek> zyga: agreed, re: moving; I've already uploaded 1.0.29+2 to Debian unstable including the Vcs-* move to github
[06:21] <zyga> slangasek: the +2 version is the onfe from snapcore?
[06:21] <zyga> slangasek: I'm sorry if I seem confused, I just woke up
[06:28] <slangasek> zyga: yes; I took what was in the snapcore github, threw a 1.0.29+2 version on it, adjusted the packaging to avoid NEW, and uploaded
[06:31] <zyga> slangasek: so snaps work on debian now?
[06:36] <slangasek> zyga: yes
[06:37] <slangasek> zyga: FTR I haven't successfully tested X-using snaps yet, something was wrong with my X forwarding from my VM; will double-check that today
[06:37] <zyga> slangasek: was your VM headless?
[06:38] <zyga> slangasek: thanks, let's make sure it works
[06:38] <slangasek> zyga: I installed it as a base Debian system, no GUI in the VM
[06:38] <slangasek> and I'm at a sprint where the bandwidth is not as advertised, so installing a desktop stack in the VM would be a fool's errand at the moment
[06:38] <zyga> slangasek: ok, I see
[06:40] <zyga> slangasek: I asked if elopio can test this and he's already on it
[06:59] <dholbach> good morning! :-)
[07:03] <ogra_> chiluk, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
[07:56] <dholbach> Can you snap* people join gitter too? https://gitter.im/ubuntu/snappy-playpen
[07:56] <sgclark> Hi all, I hope to upload some KDE stuff to the beta storee today, I here there is some magic snapcraft command to achieve this?
[07:56] <dholbach> zyga, can you review http://askubuntu.com/review/suggested-edits/578918? :-)
[07:56] <sgclark> dholbach: I have a a meeting shortly, but if I do not have to show my ugly mug, perhaps after.
[07:57] <dholbach> sgclark, https://developer.ubuntu.com/en/snappy/build-apps/upload-your-snap/
[07:57] <sgclark> thanks
[08:02] <zyga> dholbach: looking
[08:06] <zyga> dholbach: this looks good, I don't know how I can review / approve it
[08:08] <dholbach> zyga, oh ok... I thought you could do it... nevermind then. It looks approved now. Maybe somebody else was quicker. :-)
[08:09] <willcooke> morning all
[08:10] <zyga> ok
[08:14] <willcooke> jamiebennett, Sweet5hark - hello!
[08:14] <willcooke> Sweet5hark, can you explain your issue with installing from the beta store again?
[08:16] <Sweet5hark> well, I uploaded a libreoffice snap to the store to beta/edge channels (as it is devmode) and published it (on the canonical account). Unfortunately, it doesnt show up in "snap find" and does not seem to be installable even with "snap install --channel=beta libreoffice".
[08:17] <jamiebennett> Sweet5hark: what is the exact name of the libreoffice snap, is it "libreoffice"?
[08:18] <Sweet5hark> yes
[08:18] <jamiebennett> let me have a look
[08:18] <ogra_> wohooo !!!
[08:18]  * ogra_ dances
[08:18] <Sweet5hark> jamiebennett: "libreoffice" or "libreoffice.canonical"
[08:19] <mvo> Sweet5hark: might be a store issue, we had similar issues before, once sec
[08:22] <jdstrand> zyga: hi! when were you thinking snap-confine would got to 6.04?
[08:22] <jdstrand> err 16.04
[08:25] <mvo> Sweet5hark: I'm asking the store people now, we had a similar issue some days ago where some reindex was needed
[08:32] <ogra_> mvo, do you usually just copy-package livecd-rootfs to the PPA or do you do an actual upload ?
[08:34] <davidcalle> Howdy, I'm trying to upload VLC to the store and it fails with "package contains external symlinks: lib64/ld-linux-x86-64.so.2 lint-snap-v2_external_symlinks", shouldn't snapcraft warn me in these cases?
[08:35] <mvo> ogra_: I usually do an upload
[08:35] <ogra_> ok
[08:35] <mvo> ogra_: why do you ask? is there an advantage/disadvantage?
[08:36] <ogra_> mvo, nah, just want to know, so we use the same process
[08:36] <ogra_> (tonights build failed, need to upload the last livecd-rootfs)
[08:40] <davidcalle> kyrofa: sergiusens, is that to be expected, that a snapcrafted snap builds/installs correctly but is rejected by the store? ^ (same rejection also happens with another one)
[08:40] <ogra_> (pushed)
[08:56] <mvo> Sweet5hark: store people are working on the issue
[09:02] <jdstrand> sergiusens: fyi, I like how snapcraft is quieter in the 'snapcraft snap' step, but I think it may be too quiet. I'm snapping a large snap (1GB) and all I have is the spinner and not a progress meter, and so I don't really know what's going on
[09:14] <mvo> ogra_: iirc you mentioned there is a qemu for pi2? is that packaged yet somewhere?
[09:14] <mvo> ogra_: would love to use it for image build tests :)
[09:25] <davidcalle> jdstrand: any advice on my external symlinks issue? ^
[09:28] <davidcalle> What I'm wondering is: why is it blocking a package marked as requiring devmode, why is it the first time I stumble upon this, I would expect getting a warning from snapcraft
[09:39] <zyga> jdstrand: I think that's up to mvo, I'd like to do that in 2.0.9 or .10 maybe
[10:05] <jennym> Hi, anyone have any experience using ant plugin (for building java projects) and copy plugin?
[10:17] <zyga> jennym: no, sorry
[10:22] <jennym> zyga: Do you know where else I could get some assistance.
[10:23] <zyga> jennym: yes, stick around a
[10:23] <zyga> jennym: ask on snapcraft@lists.ubuntu.com
[10:24] <zyga> jennym: ask sergiusens when he's around
[10:50] <ogra_> mvo, i dont think that was me ... there is a qemu hack for BBB that i know of
[11:59] <jdstrand> davidcalle: it indicates that your snap has symlinks pointing outside of the snap that liky don't exist and are dangling symlinks. it isn't a devmode thing. I'm not sure why snapcraft idn't alert you
[12:07] <ogra_> mvo, did you turn on proposed for snappy builds ? i see it is suddenly enabled everywhere (and makes builds fail on amd64)
[12:15] <sergiusens> jdstrand we will need to patch mksquashfs to get only progress and not the big dump
[12:16] <ogra_> heh
[12:16] <ogra_> it has a --noprogress option iirc ... so it just needs a --only-progress option now
[12:19] <sergiusens> davidcalle you can manually run the reviewer tools, we are not doing that yet as we weren't on par up until a moment ago.
[12:20] <mvo> ogra_: I did a one-off PROPOSED=1 build on ~saturday or sunday, nothing else
[12:20] <ogra_> mvo, weird, that seems to have stuck somehow ... i cant manage to build without proposed at all anymore
[12:20] <ogra_> and kernel meta packages being out of sync now make the images fail ...
[12:21] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/65242 ... (Pocket: proposed) ...
[12:21] <ogra_> all i'm currently running is:  ARCHES=amd64 DIST=xenial SUBPROJECT=system-image EXTRA_PPAS=snappy-dev/image for-project ubuntu-core cron.daily-preinstalled --live
[12:21] <ogra_> and that shouldnt enable proposed at all
[12:21] <ogra_> ... i'll try to hunt down infinity to take a look
[12:24] <mvo> ogra_: when I greped for PROPOSED=1 in the script I am pretty sure it does not store that somewhere, strange indeed
[12:24] <ogra_> yeah, very ... you didnt put it indo cdimages ~/.bashrc or ~/.profile either i guess *grin*
[12:24] <ogra_> *into
[12:25] <mvo> ogra_: I don't think so ;)
[12:25] <zyga> sergiusens: please send your contributions upstream
[12:25] <ogra_> env also doesnt show the var set
[12:25] <ogra_> very strange ... adam is in a meeting though ... once he comes out i'll corner him :)
[12:39] <ogra_> mvo, myth solved ... seemingly proposed is enabled globally for xenial now ... we actually need to build with PROPOSED=0 now
[12:39]  * ogra_ adds that to the cron job for the default builds
[12:42] <mvo> woah
[12:42] <mvo> thats interessting (and scary ;)
[12:42] <ogra_> yep
[12:59] <dpm> seb128, hey
[12:59] <dpm> seb128, does this GTK wrapper look similar to the latest work that you guys have been doing with GTK apps' wrappers, or do we need to include any recent changes you've done? https://github.com/dplanella/gtkconf/blob/master/gtk-launch
[13:01] <seb128> dpm, howdy
[13:01] <seb128> dpm, let me have a look
[13:01] <dpm> great, thanks
[13:01] <pmp> hi ogra, I'm getting back to you concerning dtoverlay usage with rpi and a custom kernel snap flashed with current u-d-f.
[13:01] <seb128> dpm, how come some of us are doing the same work though :-/
[13:01] <seb128> feels like waste/duplication
[13:02] <sergiusens> zyga sorry, but what are you talking about? :-)
[13:02] <pmp> ogra_: my kernel boots - which is nice
[13:02] <sergiusens> zyga oh, mksquashfs I guess
[13:02] <ogra_> pmp, right ... until the final version of the 16 images is there you will have to mangle the overlays manually
[13:02] <dpm> seb128, well, the idea of that is to _remove_ duplication. That's a wiki part that most GTK apps should be able to use
[13:02] <pmp> ogra_: your last hint was to copy the dtbo files manually to the boot-partition
[13:02] <ogra_> specifically on the rpi where you need to create an overlays dir in the vfat
[13:03] <pmp> like it is on raspian?
[13:03] <seb128> dpm, right, asked differently why didn't we get concerned people Cced on a same email or talking before things got set up/started
[13:03] <ogra_> i know niemeyer works on defininng some high level thing soo you caan do that from the gadget snap in the future
[13:03] <ogra_> pmp, right, just like on raspbian
[13:03] <seb128> dpm, oh well, in any case that seems mostly to be what we used, outdated revision missing some improvement and bugfixes though
[13:04] <zyga> sergiusens: squashfs changes
[13:04] <dpm> seb128, I'm not sure what you mean. We knew about the work you guys were doing with gtk apps and reused that, that's all
[13:05] <seb128> dpm, is that going to be including in snapcraft itself?
[13:06] <dpm> seb128, it's a part for now that snaps can point to in their snapcraft.yaml file, I'm not sure it would make sense to have a gtk plugin, but sergiusens might have better ideas
[13:06] <seb128> dpm, forget about the comment, seems we each have diverging branches with different improvements/fixes but that's not the end of the world
[13:06] <seb128> it's just that seeing work duped bothers me
[13:06] <seb128> seems like we have several team working on the same things in not really coordinated ways
[13:08] <dpm> seb128, I'd say on the contrary: you guys did the heavy lifting with the wrapper, and we're proposing a reusable part before everyone starts copying over that gtk wrapper in their snaps
[13:08] <seb128> dpm, yeah, I guess I'm just grumpy because we didn't get involved in how/where that reusable parts have been set up
[13:08] <seb128> like you clearly based on a version of our wrapper outdated with bugs
[13:09] <seb128> I would have preferred that somebody included us upfront
[13:09] <seb128> you also apparently did change to deal with gtk2 vs gtk3 that you didn't send us back/asked us for comment
[13:09] <dpm> seb128, there wasn't much to coordinate, to be honest: I just did it this morning, and I thought I'd touch base with you now
[13:10] <seb128> k
[13:11] <dpm> and the gtk2 vs gtk3 bit is not yet working (but on the way to, I hope)
[13:11] <seb128> dpm, anyway, you miss some fixes but it seems to be mostly good
[13:11] <dpm> cool
[13:11] <seb128> I also think it doesn't make sense to have a gtk plugin
[13:11] <seb128> but most of those hacks should go away over time
[13:12] <seb128> like snapcraft/snapd should export the proper env variable
[13:12] <dpm> seb128, ack . Where are those latest fixes, so that I add them to the plugin?
[13:12] <seb128> rather than requesting every snaps to set e.g the xdg dirs
[13:12] <dpm> that's indeed a pain, yes
[13:12] <sergiusens> kyrofa mind looking at https://github.com/ubuntu-core/snapcraft/pull/563 ?
[13:12] <seb128> dpm, same, https://code.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap
[13:13] <seb128> dpm, diff them, I improved some things in commit 7 when I merged back the work from trevinho
[13:13] <seb128> dpm, like your wrapper is probably displaying warnings on first start about invalid symlinks or so
[13:13] <seb128> his code was not checking for empty dirs and suchs
[13:15] <dpm> seb128, cool, thanks. Also, what's the best way to give you guys back changes/bug fixes?
[13:15] <seb128> dpm, we don't have a proper project for that, diff via email or pastebined and shared on #ubuntu-desktop I guess
[13:16] <seb128> dpm, none of you guys looked at getting translations to work by any chance?
[13:16] <dpm> ack
[13:17] <dpm> seb128, not yet. I looked at it for qt/sdk apps, but I failed
[13:17] <seb128> k
[13:17] <seb128> no worry
[13:18] <kyrofa> sergiusens, sure thing!
[13:26] <pmp> ogra_: the dtparam-parameter works, but dtoverlay-commands seem to be ignored, not sure how I should debug this
[13:28] <ogra_> hmm, that should just work from config.txt ... we just use the upstream blobs from broadcom ... shouldnt be any different from raspbian
[13:34] <pmp> ogra_: probably out of scope here, who is merging the device-tree with the overlays, the blobs from broadcom? When is it done? I assume it's done before u-boot boots .. how does the kernel then find the right merged device-tree?
[13:35] <ogra_> right, it happens inside the broadcom blob ... there is hope the u-boot feature that just landed to merge dtbs is stable enough to actually use it instead for the final images
[13:35] <ogra_> i will look into that next week (i'm at a sprint this week)
[13:36] <roadmr> Heya folks! How can I get one of the binaries in my snap to be able to use the "setpriority" syscall? I think it's failing to call another binary in the same snap because of that.
[13:36] <roadmr> (it works in devmode, btw)
[13:36] <ogra_> likely thought an interface that doesnt exist yet ... zyga or jdstrand should be able to tell you
[13:37] <pmp> ogra_ et roadmr , there should be a bug on launchpad for that
[13:38] <pmp> we had the same problem
[13:38] <roadmr> thanks ogra_ :)
[13:38] <roadmr> meanwhile I'll try to hack the setpriority away from the binary to see if that's the only snag...
[13:39] <pmp> roadmr: if you're running in devmode you should see apparmor warnings in syslog for all restriction you would see in real-life
[13:40] <roadmr> pmp: indeed! that was the only suspicious one I saw
[14:00] <pmp> ogra_: so, if I understand you correctly, uboot does not, currently, support dt-overlays merging on raspberry-pi. I found this discussion https://github.com/raspberrypi/linux/issues/942 saying exactly this
[14:01] <pmp> ogra_: could I bypass u-boot and still boot to ubuntu? and will it be happy?
[14:01] <ogra_> pmp, nope, all the boot logic in snappy lives in the uboot scripts
[14:02] <ogra_> jospoortvliet, congrats on the nextcould release !
[14:02] <ogra_> jospoortvliet, where is the snap ? :)
[14:03] <tsimonq2> !info xfonts-100dpi yakkety
[14:04] <tsimonq2> !info aspell-en yakkety
[14:10] <jospoortvliet> ogra_: hahaa snap will be here soon I bet
[14:10] <jospoortvliet> kyrofa: must be all over it :P
[14:11] <jospoortvliet> kyrofa: now you know what we've been up to...
[14:11] <jospoortvliet> whohoo :D
[14:11] <ogra_> hopefully soon :)
[14:11] <ogra_> great stuff :)
[14:11] <jospoortvliet> for ppl not sure what the heck we're talking about: https://nextcloud.com/nextcloud-9-available-enterprise-functionality-to-be-open-source/
[14:11] <jospoortvliet> yes, we go 100% open source (yay) and the first release already has some 'enterprise' features. Yay for liberating them :P
[14:12] <ogra_> nice !
[14:12] <jospoortvliet> awesome, right?
[14:13] <kyrofa> jospoortvliet, awesome :) . Not diverged too much from ownCloud just yet though?
[14:16] <ogra_> GRRR ... hotel wifi
[14:16] <ogra_> (just kicked me out completely in the middle of commiting something)
[14:35] <dpm> sergiusens, is there a cache of some sorts for wiki parts? I've done `snapcraft clean && snapcraft` for an app that pulls a wiki part that I just changed (gtkconf in https://wiki.ubuntu.com/Snappy/Parts), looking at the generated snap, it does not have those latest changes
[14:35] <dpm> Either that, or `source-branch: devel` in the wiki page is being ignored
[14:39] <sergiusens> dpm yes there is, but not in anything from snapcraft. The wiki's webfront just returns old results I believe
[14:42] <dpm> sergiusens, oh, so how long in your experience until a change is made in the wiki and the server returns the updated data?
[14:42] <sergiusens> dpm 10 minutes or so
[14:43] <dpm> sergiusens, ok, good to know, thanks
[14:45] <sergiusens> dpm also, might want to start playing with the future https://wiki.ubuntu.com/snapcraft/parts?action=raw
[14:46] <dpm> sergiusens, I saw that, but you only wanted to give us a sneak peek, so I'm not sure what to do with it ;)
[15:03] <tsimonq2> elopio: when you have a chance, can you look at my PR again? I think I'm done :)
[15:32] <sergiusens> dpm this all might land next week ;-)
[15:32] <sergiusens> elopio I fixed the integration test
[15:32] <dpm> \o/
[15:37] <pmp> ogra_: fyi, I succeeded with my device-tree-overlay on raspi
[15:37] <pmp> ogra_: by integrating the device-tree stuff into the main device-tree
[15:38] <pmp> ogra_: and then overwriting the /boot/bcm2709-rpi-2-b.dtb
[15:39] <pmp> ogra_: overwriting the one in /boot/rpi2-kernel_0.snap/dtbs didn't work
[15:45] <sergiusens> kyrofa just saw you reviewed as well, nice catches!
[15:45] <kyrofa> sergiusens, no problem :)
[15:52] <sergiusens> elopio btw, where do you get that `-` is not valid for ranges?
[15:53] <sergiusens> kyrofa do you know about that? ^
[15:56] <kyrofa> sergiusens, a comment he made in review?
[15:57] <sergiusens> kyrofa yeah, but I want to know where the fact that it is not valid comes from
[15:57] <sergiusens> kyrofa I would think that 2015-2017 implies: 2015, 2016, 2017
[15:57] <kyrofa> sergiusens, ohhh
[15:58] <kyrofa> sergiusens, same here. I use commas when it's two years and hyphens after that
[16:03] <kyrofa> jospoortvliet, https://github.com/kyrofa/nextcloud-snap . Tested and working, publishing asap
[16:03] <elopio> sergiusens: FSF guide. Take a look at http://git.savannah.gnu.org/cgit/emacs.git/tree/README#n99
[16:03] <elopio> That statement is what makes the - valid. I don't know, layers are weird.
[16:04] <jospoortvliet> kyrofa: whoah, amazingly quick...
[16:04] <kyrofa> jospoortvliet, I told you, as soon as you had code!
[16:06] <jospoortvliet> you're a man of your word
[16:06] <jospoortvliet> respect
[16:06] <jospoortvliet> real awesome
[16:08] <sergiusens> elopio that actually implies that what I did is fine
[16:09] <kyrofa> sergiusens, elopio agreed, it seems that hyphens are fine
[16:09]  * sergiusens leaves to pick up his kid from daycare
[16:17] <dpm> hi jospoortvliet, now that I see you here... this might be interesting for you too -> https://design.canonical.com/2016/06/the-app-design-clinics-are-back/
[16:18] <jospoortvliet> ah nice
[16:18] <jospoortvliet> guessing that might just need a nextcloud logo ;-)
[16:19] <dpm> yeah, I guess the app was created pre-nextcloud :)
[16:52] <kyrofa> Sweet5hark, https://askubuntu.com/questions/786974/libreoffice-5-2-snap-will-it-use-my-existing-profile
[17:00] <mhall119> hi guys, I'm trying to setup another machine to build snaps for me, but I'm getting this on cleanbuild:
[17:00] <mhall119> error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: permission denied
[17:00] <mhall119> any ideas?
[17:03] <mhall119> srw-rw---- 1 root lxd 0 Jun 14 12:52 /var/lib/lxd/unix.socket
[17:12] <Sweet5hark> kyrofa: heh, that's an excellent and tricky question to answer ..
[17:15] <sabdfl> jospoortvliet, welcome!
[17:17] <kyrofa> mhall119, probably a sergiusens question
[17:19] <mhall119> jospoortvliet: got that nextcloud snap in the store yet? :)
[17:19] <kyrofa> mhall119, it's building now
[17:20] <kyrofa> mhall119, i386 is the only one completed so far
[17:20] <Sweet5hark> kyrofa: http://askubuntu.com/questions/786974/libreoffice-5-2-snap-will-it-use-my-existing-profile/786991#786991 <- answered, I hope that is ok.
[17:20] <mhall119> kyrofa: excellent! Is jospoortvliet (or someone from nextCloud) all setup with an account in MyApps to publish them?
[17:21] <kyrofa> mhall119, not yet, it's in the canonical account. But we can give them the name whenever they would it
[17:21] <kyrofa> would like it*
[17:22] <mhall119> jospoortvliet: ^^ you want that, so you guys can push updates directly (including use the beta-testing channel)
[17:23] <niemeyer> jdstrand: ping for review on spread snap
[17:25] <matteo> ciao
[17:26]  * svij installed his first snap on archlinux. :)
[17:26] <zyga> svij: woot! :)
[17:26] <jamiebennett> \o/
[17:36] <svij> can we have snapcraft as a snap?
[17:39] <sergiusens> svij soon-ish
[17:39] <svij> yay
[17:44] <beuno> olli_, sabdfl, I'll fix freenode perms soon for a wider list of access
[17:45] <olli> beuno, mind repeating for olli
[17:46] <beuno> so many olli's
[17:46] <olli> thx
[17:46] <tsimonq2> (maybe just do his cloak?)
[17:47] <olli> I was competing with myself  for the nick
[17:50] <tsimonq2> http://snapcraft.io/create/ <-- this doesn't have instructions for any other flavor yet, it only lists `sudo apt install snapcraft`, and I heard something about Arch?
[17:50] <svij> on Arch it's in the AUR, tsimonq2
[17:50] <tsimonq2> so yeah, it should probably be added to that page, whoever has access
[17:51] <olli> jamiebennett, ^
[17:54] <jamiebennett> Hi tsimonq2. At the moment we are offering the snap runtime, snapd, on other distributions to enable snaps to be run. Supporting snapcraft so that you can create snaps on other distros is being worked on at the moment.
[17:55] <tsimonq2> oh okay, thank you jamiebennett
[17:55] <tsimonq2> jamiebennett: anything I can do to help, or is it not code related?
[17:56] <jamiebennett> tsimonq2: sergiusens and kyrofa are working on that and can comment better on what is needed
[17:57] <tsimonq2> jamiebennett: thank you for your time :)
[17:57] <jamiebennett> tsimonq2: hey, no problem at all
[17:57]  * svij made a one-line patch to snapcraft before it was cool.
[17:58] <tsimonq2> sergiusens, kyrofa: is there anything I can do to help with what he mentioned?
[17:58] <sergiusens> tsimonq2 sorry, I cannot follow the chain of thought in the thread, help with what exactly?
[17:59] <jamiebennett> sergiusens: we were talking about snapcraft support on other distros
[17:59] <jamiebennett> sergiusens: and what it would take to make it happen
[18:00] <sergiusens> jamiebennett tsimonq2 we have a plan, but it is not going to be easy, end goal might be to make it a snap as svij hinted a while ago
[18:01] <tsimonq2> sergiusens: I think that might be a good option, because on a snap-only system, as far as I know, you can't use snapcraft
[18:02] <jamiebennett> tsimonq2: basically snap support in LXD can help us here and that is actively being worked on at the moment
[18:02] <jamiebennett> tsimonq2: once that is available we will be able to progress further on the snapcraft cross-distro story
[18:02] <zyga> tsimonq2: https://github.com/zyga/devtools/blob/master/classic.sh
[18:04] <tsimonq2> jamiebennett: okay, thanks
[18:04] <tsimonq2> zyga: do you accept pull requests? :)
[18:06] <tsimonq2> ahh yes, says so in the readme
[18:06] <zyga> tsimonq2: absolutely!
[18:29] <tsimonq2> zyga: you have a pull request :)
[18:31] <tsimonq2> jamiebennett: http://snapcraft.io/ needs a favicon.ico
[18:31] <tsimonq2> s/needs/should have/
[18:33] <jamiebennett> tsimonq2: Good catch, thank you
[18:33] <jamiebennett> I've reported it to our webteam
[18:42] <kyrofa> jospoortvliet, alright, nextcloud has been published
[18:46] <niemeyer> jdstrand: ping
[18:46] <niemeyer> tyhicks: ping
[18:54] <mariogrip> this is awesome! http://news.softpedia.com/news/snap-packages-become-the-universal-binary-format-for-all-gnu-linux-distributions-505241.shtml
[19:03] <tsimonq2> mariogrip: yeah! :D
[19:21] <netphreak> Nice!!
[20:31] <Shibe> What are snappy "realms"?
[20:42] <aisrael> What's the procedure for installing extra kernel modules on snappy? In particular, trying to get a wireless dongle to work (a ralink 801.11n usb)
[20:55] <marcoceppi> Okay, I'm ready to snap, but I have no idea for what to do
[20:56] <caraka> It is totally worth stepping through the tutorials one by one and bulding each of the examples, marcoceppi
[20:56] <marcoceppi> caraka: I've tried, the project I want to build has a deb and stuff
[20:56] <marcoceppi> it's a golang project
[20:57] <marcoceppi> none of the examples really enumerate that, was wondering if there was ane xample like that
[20:57] <caraka> there are examples of both incorporating debs and working with go in the tutorials
[20:58] <caraka> If I recall, they are separate tutorials, you'd have to combine the concepts
[20:58] <caraka> I'm just working through them all myself
[20:59] <caraka> snappy is a work in progress. I know that when I have come here with specific questions, I usually get an answer or a link to one.
[21:02] <tsimonq2> caraka: what do you need?
[21:51] <ali1234> so..... can i package software from raspberry pi 1 now?
[21:55] <tsimonq2> zyga: the note you left on line 30, are you talking about replacing it with $classic, if not, I don't know what you mean, could you clarify?
[22:03] <zyga> tsimonq2: hey
[22:03] <zyga> tsimonq2: I like your change, I just want to make it a little bit more generic
[22:04] <zyga> tsimonq2: everywhere where the script had hard-coded 'xenial' just use a variable ($classic)
[22:20] <tsimonq2> zyga: yep, I'm working on the script now
[22:20] <tsimonq2> zyga: I'm making it so you can do a lot more with it
[22:25] <zyga> tsimonq2: fantastic, thanks :)