=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[05:46] <johnorjias> Hello all :-) I am just wondering if anyone has instructions for enabling the ttyO1-O5 serial ports on the BBB in snappy
[05:47] <dbrouwer> Hi John, I was about to sk the same question!
[05:47] <johnorjias> haha hello doug :-)
[05:48] <johnorjias> I think everyone is sitting idle at the moment I will keep an eye out for if anyone gets on and response to this
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[07:19] <zyga> goooood morning :)
=== chihchun_afk is now known as chihchun
=== vrruiz_ is now known as rvr
[09:11] <ysionneau> morning!
[09:12] <ysionneau> what should I do to propose a patch for snapcraft? open a ticket on launchpad and append a patch? or open a pull request with my patch on GitHub ?
[09:12] <ysionneau> or both
[09:18] <dholbach> ysionneau, https://github.com/ubuntu-core/snapcraft/blob/master/CONTRIBUTING.md :)
[09:19] <ysionneau> thx!
[09:22] <ysionneau> I need to submit the "contributor license agreement"
[09:22] <ysionneau> "Please add the Canonical Project Manager or contact" < who is it?
[09:22] <ysionneau> -it+he
[09:22] <ysionneau> or she
[09:29] <ogra_> mvo, mind if i add "XB-Task: ubuntu-core" to the initramfs-tools-ubuntu-core package in the PPA ? seesm we end up without initrd in the rootfs if thats not there (breaking everyones custom kernel builds)
[09:33] <mvo> ogra_: please do
[09:33] <mvo> ogra_: all the packages from the weekend will hopefully get uploaded to xenial proper today
[09:33] <ogra_> i have a check for that in livecd-rootfs trunk already
[09:33] <mvo> ogra_: but please add it
[09:34] <ogra_> mvo, and sorry for the clashes on the weekend ... i only got aware you were tinkering too very late :)
[09:35] <davidcalle> zyga: hi, do you know when multiple plugs support is going to land? Right now, when I'm trying to use multiple ones (eg. home + network + something), I get "youtube-dl_2016.03.27_amd64.snap failed to install: only a single plug is supported, 3 found"
[09:38] <davidcalle> jdstrand: ^
[09:42] <mvo> ogra_: no worries
[09:43] <dpm> ysionneau, I think the best person to add would be Jamie Bennet
[09:43] <mvo> ogra_: I have some changes  pending locally that I need to commit proper but commiting must be done in sync with the new snappy upload so its all a bit circular
[09:44] <ogra_> well, after all edge is allowed to break :)
[09:44] <ogra_> mvo, i was wondering what we'll do with all the universe packages
[09:44] <ogra_> there is still a good bunch
[09:47] <ysionneau> ok dpm thanks
[09:50] <mvo> ogra_: uh, thats bad, I thought it all got promoted, I was not looking closely :/
[09:50] <ogra_> watchdog, libnss-extrausers, ubuntu-fan, ubuntu-core-libs, tpm-tools, opencryptoki, libopencryptoki0, libtpm-unseal1, ubuntu-core-config
[09:50] <ogra_> that is what i see coming from universe in the image build logs
[09:56] <mvo> ogra_: oh, ok. those are all for the image itself. ok
[10:00] <zyga> davidcalle: it's already supported now but stay tuned :)
[10:01] <zyga> davidcalle: I'm getting connect/disconnect to do something for real
[10:01] <davidcalle> zyga: supported as in "landed"? See my error above
[10:01] <zyga> davidcalle: and I also need to get auto-connect to work (for things as landed)
[10:01] <zyga> davidcalle: it's landed and released last night but wasn't useful yet
[10:02] <zyga> davidcalle: we need one more release
[10:02] <ogra_> mvo, well, libnss-extrausers, ubuntu-core-libs and ubuntu-core-config are pretty essential i think ... not sure about the others though
[10:02] <zyga> davidcalle: if your image is older than a few hours it needs to be rebuilt
[10:02] <ogra_> mvo, writing a mail
[10:02] <mvo> ta
[10:02] <zyga> davidcalle: but note that before the next release it's all broken anyway
[10:02] <zyga> davidcalle: and your snap won't get any permissions
[10:05] <davidcalle> zyga, ok, do you ~know when is this next landing planned?
[10:06] <zyga> davidcalle: when we get new things to work
[10:06] <zyga> very soon
[12:14] <ogra_> mvo, u-d-f fails with that latest snappy changes ...
[12:15] <ogra_> bind mount failed for /tmp/diskimage643961727/writable/system-data/var/lib/snappy to /tmp/diskimage643961727/system/var/lib/snappy with: exit status 32 mount: mount point /tmp/diskimage643961727/system/var/lib/snappy does not exist
[12:16] <mvo> ogra_: are you using the edge channel? i.e. what is your u-d-f commandline?
[12:17] <mvo> ogra_: are you using u-d-f from my people.c.c page?
[12:17] <sergiusens> kyrofa, hey, care to start reviewing https://github.com/ubuntu-core/snapcraft/pull/434
[12:18] <sergiusens> examples tests fail as new infra was deployed, fgimenez is on it fwiw :-)
[12:21] <ogra_> mvo, well, the same one i use since starting to use all-snaps ... from your people.u.c page, yes
[12:21] <ogra_> mvo, oh
[12:22] <ogra_> i didnt notice the update ... ignore me :)
[12:25] <ogra_> mvo, works fine, sorry for the noise :)
[12:26] <mvo> ogra_: thanks and no worries
[12:27] <mvo> ogra_: its hard to keep track of non-pkgs :/ but soon we fix all this
[12:27] <ogra_> yeah, we still have 10 days
[12:27] <ogra_> :P
[12:28] <ogra_> -
[12:28] <ogra_> oops
[12:28] <mvo> ogra_: *cough*
[12:28] <mvo> ogra_: wasn't this the 16.06 release ? to honor 6.06?
[12:29] <ogra_> lol
[12:34] <fgimenez> sergiusens, it should be fixed now http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/545/console
[12:34] <sergiusens> ty
[12:45] <ogra_> hmm, unsquashfs doesnt work on pipes :(
[12:46]  * ogra_ would like to pull the initrd.img out of the os snap without having to completely download it 
[12:47] <ogra_> but piping a wget stream seems to not work :(
[13:04] <johnorjias> Hello all :-) I am just wondering if anyone has instructions for enabling the ttyO1-O5 serial ports on the BBB in snappy?
[13:15] <oparoz> Hello, how do we know which OS binaries we can use in a snap? I've had startup scripts fail because I wanted to use hostnamectl or sed -i and got denied by apparmor
[13:16] <oparoz> I mean, I can call these just fine from the snap, but somehow I can't use them in a startupscript, so it takes a bit of trial and error to figure out what is allowed
[13:16] <ysionneau> If anyone want to try doing snaps cross compilation, you can give this a try : https://github.com/fallen/snapcraft/tree/dev-alchemy-branch
[13:17] <ysionneau> using this build system : https://github.com/parrot-developers/alchemy
[13:21] <oparoz> ysionneau: Is there a bit more instructions on how to set it up?
[13:22] <davidcalle> ogra_: how do you disable snappy auto-reboot on Xenial? Althgouh, it's very useful, when my desktop reboots unexpectedly, I know it's any-hour-past-ten :P
[13:22] <ysionneau> oparoz: I should post an example :)
[13:22] <ogra_> davidcalle, using snappy config ubuntu-core (i forgot the exact syntax, Chipaca` always knew it from teh top of his head though)
[13:23] <oparoz> ysionneau: Yes, please. Per example I'm using an amd64 VM and I'd like to target arm, so I guess I must be able to define the targets somewhere, etc.
[13:27] <davidcalle> ogra, can you get/set options from the cli or do I need to provide a new conf file?
[13:27] <ogra_> you can pipe it somehow, thats the bit i was referring to for Chipaca`
[13:27] <davidcalle> Ok, thanks :)
[13:28] <davidcalle> ogra_: Chipaca` found it  "echo 'config: {ubuntu-core: {autoupdate: off}}' | sudo snappy config ubuntu-core -"
[13:29] <ogra_> cool
[13:48] <ysionneau> oparoz: https://github.com/fallen/hello_snappy_alchemy
[13:52] <ysionneau> that's very early and beta stuff (the alchemy plugin, not the alchemy build system) but it does work for my uses for now
[13:53] <ysionneau> + it's a bit hacky
[14:00] <oparoz> Thanks for that ysionneau. Regarding snapcraft, do we need more than the alchemy plugin?
[14:21] <ogra_> reading canonical-snapdragon-linux_0.snap/vmlinuz
[14:21] <ogra_> 24026624 bytes read in 6534 ms (3.5 MiB/s)
[14:21] <ogra_> reading canonical-snapdragon-linux_0.snap/dtbs/apq8016-sbc.dtb
[14:21] <ogra_> mvo, ^^^ thats doesnt look correct ... where is the version gone ?
[14:23] <ogra_> + snapcraft snap snap
[14:23] <ogra_> Snapping canonical-snapdragon-linux_4.4.0-1009+20160411.11-57_arm64.snap
[14:23] <ogra_> Parallel mksquashfs: Using 4 processors
[14:23] <sergiusens> ysionneau, where is the alchemy plugin? :-)
[14:23] <ogra_> the snap seems to have been built ok though
[14:24] <sergiusens> ysionneau, fwiw, cross compiling is super easy, the problem we have from a snapcraft point of view are `stage-packages` and `build-packages`
[14:25] <ogra_> wow, "snap list" on the dragonboard takes nearly 30sec to tell me about the 3 packages
[14:25] <ogra_> ah, subsequent runs are slightly faster
[14:26] <ogra_> (still a lot slower than snappy list was)
[14:27] <zyga> ogra_: looks like socket activation
[14:27] <ogra_> did that get tested on all arches ?
[14:27] <ogra_> (i would suspect armhf to actually be a lot slower than arm64 here )
[14:28] <zyga> ogra_: it was always socket activated
[14:28] <ogra_> snappy list did use sockets ?
[14:28] <zyga> snappy list is gone, snap list uses sockets
[14:28] <ogra_> i thought the reply came directly from the snappy binary
[14:28] <ogra_> zyga, well, snap list is there since today
[14:29] <ogra_> and is definitely lots slower than snappy list was ... in the first incarnation at least
[14:29] <zyga> ogra_: no, it was there for a while, but now snappy list is not there
[14:29] <ogra_> zyga, it wasnt there until michael landed it on the weekend
[14:30] <zyga> ogra_: well, in any way, snap list was in the source for months
[14:30] <ogra_> i dont care about the source :P
[14:30] <zyga> ogra_: snappy list was taking global lock; snap list should be faster down the line
[14:30] <zyga> well, sorry :)
[14:30] <ogra_> it is definitely an odd user experience if you knew snappy list before though
[14:31] <zyga> (snap list won't read the FS soon)
[14:31] <ogra_> (it should at least print something that tells you the initial run can take ages
[14:31] <ogra_> )
[14:31] <zyga> currently it still does
[14:31] <zyga> ages?
[14:31] <zyga> each snap command should print that?
[14:31] <ogra_> 30sec to 1min ... i didnt actually stopwatch it
[14:31] <zyga> I think that's not reasonable, we'll just get it faster
[14:31] <zyga> what did you test this on?
[14:32] <ogra_> dragonboard
[14:32] <zyga> I run on pi2 all the time and it's a few seconds at most
[14:32] <ogra_> i.e. the fastest arm arch we have
[14:32] <zyga> wow, measure your card, maybe it's the cause
[14:32] <ogra_> i use the same cards everywhere ... 48MB/s throughput
[14:32] <ogra_> this is with todays image ... i.e. the first one that has all bits in place
[14:33] <zyga> odd, I will give it a try with the next image tomorrow
[14:33] <zyga> not everything is in place yet
[14:40] <daker> hi guys snapcraft questions :
[14:40] <daker> 1- how can i tell snapcraft to not pull git submodules ?
[14:41] <daker> 2- snapcraft snap don't produce a .snap, any ideas why ?
[14:41] <daker> doesn't*
[14:42] <zyga> daker: try just "snapcraft" for 2
[14:42] <daker> zyga: (y) thanks!
[14:43] <daker> for 1) i saw that it is harcoded
[14:43] <zyga> daker: patch snapcraft; no other way
[14:48] <ysionneau> sergiusens: https://github.com/fallen/snapcraft/tree/dev-alchemy-branch in the plugins directory :)
[14:49] <ysionneau> 16:00 < oparoz> Thanks for that ysionneau. Regarding snapcraft, do we need more than the alchemy plugin? < what do you mean?
[14:49] <netphreak> Hi, guys!
[14:49] <ysionneau> 16:24 < sergiusens> ysionneau, fwiw, cross compiling is super easy, the problem we have from a snapcraft point of view are `stage-packages` and `build-packages` < last time I asked the only way to cross compile was to use qemu-user with a debootstrap of arm userspace?
[14:49] <ysionneau> did the situation evolve ?
[14:50] <netphreak> Is it possible to to setup the snappy jdk plugin to pull in a jdk for a specific architecture not the same as the build machine?
[14:51] <sergiusens> ysionneau, that's not cross compile (qemu-user), that is native compile in an emulated environment :-P
[14:51] <ysionneau> yeah :p
[14:51] <ysionneau> sure
[14:51] <ysionneau> when you say "cross compiling is super easy" does it mean it is now possible to do it?
[14:53] <sergiusens> ysionneau, only for the kernel; I haven't solved `stage` and `build` packages as I mentioned
[14:53] <netphreak> ?
[14:54] <sergiusens> netphreak, not as it is right now
[14:55] <daker> sergiusens: any idea what would be the appropriate keyword for the git recurse-submodules ?
[14:55] <netphreak> :/
[14:55] <netphreak> makes idk and java a bit more complex to handle.. /
[14:55] <netphreak> jdk
[14:56] <netphreak> is it something that is on the todo list?
[14:58] <netphreak> or is there somewhere i can pull down a precompiled jdk for Xenial from for armhf i can use?
[14:58] <netphreak> ffrom snap
=== Chipaca` is now known as Chipaca
[15:04] <dbrouwer> Are there instructions for enabling the ttyO1-O5 serial ports on the BBB in snappy?
[15:32] <daker> Hi guys again store questions: what does Snap name stand for ? and which Series should i target ?
[15:33] <zyga> daker: snap name == just a name
[15:37] <daker> i didn't it's says invalide name :D maybe it should be lowercase ?
[15:37] <daker> i did*
[15:38] <daker> beuno: can you help please ?
[15:38] <beuno> daker, sorry, what's the context here?
[15:38] <beuno> what are you tryi ng to do?
[15:39] <beuno> snap name is indeed the name of the snappy package
[15:39] <beuno> it'll be what people type in the command line, so yes, lowercase and no special characters
[15:39] <daker> so "MicroPython" is an invalid name ?
[15:39] <daker> ah ok
[15:40] <zyga> daker: yep, micro-python or micropython will work
[15:40] <daker> beuno: because the indicator on the right is green with "MicroPython"
[15:40] <daker> and the helptext doesn't mention lowercase at all
[15:41] <beuno> daker, I'll get that fixed, thank you
[15:41] <beuno> beowulf, ^
[15:42] <daker> beuno: thanks!
[15:44] <qengho> You Ubuntu guys should sell some crash-reporting service for snaps.
[15:44] <daker> zyga: one last question: i see people uploading different arch, what arch should i build againt
[15:45] <zyga> daker: what do you want to target?
[15:45] <beowulf> daker: beuno: thanks, will fix
[15:45] <beuno> daker, as many as you can?  :)
[15:46] <qengho> daker: Why not all of them?
[15:46] <beuno> I think amd64 and armhf will get you the vast majority though
[15:47] <daker> beowulf: thanks! just avoid the confusion :D maybe also add a text under the input explaining what snap name means
[15:47] <qengho> (and PowerPC users try to weep some more from their dessicated tear ducts.)
[15:47] <beowulf> daker: good idea, thanks
[15:49] <daker> beuno: and how it will served via the store ? like someone on an rpi trying snapp install mysnapname and i only have an amd64 snapp on the the store
[15:50] <beuno> daker, they won't see snaps for architectures that aren't their own
[15:51] <beuno> thanks beowulf
[15:52] <daker> beuno: i mean how does the store knows the arch, is it via the snap name ex : "forbar_version_i386.snap"
[15:53] <beuno> daker, no, it ignores the name. It parses it out of the snap.yaml
[15:54] <daker> beuno: ah i see
[16:27] <jkridner> hi sergiusens
[16:27] <sergiusens> hi
[16:27] <sergiusens> jkridner, and you have kyrofa
[16:27] <kyrofa> jkridner, hey there
[16:27] <jkridner> thanks sergiusens and kyrofa
[16:29] <ysionneau> sergiusens: with which python package did you test your commit? the debian package (python-magic)? or the pip one?
[16:30] <ysionneau> it's just a matter of being consistent, I don't care which one you chose
[16:30] <sergiusens> ysionneau, the debian one
[16:30] <ysionneau> allright, then let's just commit with this one
[16:31] <ysionneau> it's ok for you if I change the pip line ?
[16:31] <ysionneau> (the one in .travis.yml)
=== chihchun is now known as chihchun_afk
[16:56] <netphreak> hi, guys!
[17:02] <zyga> hi
[17:08] <netphreak> Is there anyway i can pull down a architecture specific java jdk (not using the jdk/maven plugin)?
[17:10] <zyga> I don't know, sorry
[17:11] <netphreak> problem is jdk/maven plugins download an jdk matching the build machine's architecture :/
[17:14] <zyga> netphreak: I don't know if cross compiling is supported yet
[17:15] <netphreak> well, i suppose the jdk is exist in allready compiled state -ready to be pulled in?
[17:16] <zyga> netphreak: I think there are some requests for cross architecture snapcraft but you'd have to check that yourself
[17:16] <zyga> (even if bits are already built snapcraft would need to understand that you are targetting a different arch)
[17:47] <dbrouwer> Can someone give me some guidance? How do I enable  the ttyO1-O5 serial ports on the BBB in snappy?
[17:48] <zyga> dbrouwer: I don't think you can do that yet, you'd have to create a snap that listens on those ports and you'd have to pass the hardware to that snap
[17:48] <zyga> dbrouwer: come back in two weeks
[17:49] <zyga> dbrouwer: then it should be doable
[17:49] <dbrouwer> All right. Thanks! That at least gives me some hope!
[19:48] <oparoz> Is there a snap package builder status page to know when to avoid requesting builds?
[19:49] <oparoz> Maybe that's a question for #launchpad...
[19:58] <qengho> oparoz: what would make you avoid it?
[20:01] <daker> anybody know what's does : Unexpected output from click-review.
[20:01] <daker> stand for ...
[20:01] <oparoz> qengho: https://bugs.launchpad.net/launchpad/+bug/1569023
[20:01] <ubottu> Launchpad bug 1569023 in Launchpad itself "Snap builder fails to pull files (violation of protocol)" [Undecided,New]
[20:02] <oparoz> qengho: If the dashboard shows lots of builds failing, there is no point in overloading the system. It doesn't seem to be the case here though
[20:05] <qengho> daker: hrm. I'd check  https://myapps.developer.ubuntu.com/  . It could be the package verifier had a complaint, but the client you are running didn't understand it. (That would be a bug, but not your problem.)
[20:05] <daker> qengho: that's the automated review
[20:05] <qengho> daker: I assumed you just uploaded a package, that is?
[20:06] <daker> yes .snap
[20:06] <qengho> Sweet! daker, check the automatic review.
[20:07] <daker> the automated review says : Unexpected output from click-review. :D
[20:07] <daker> and the package is refused
[20:08] <qengho> Whoa.
[20:08] <daker> hi beuno sorry the noise, can you pleas help ?
[20:08] <daker> for*
[20:10] <beuno> daker, hi
[20:10] <daker> beuno: https://i.imgur.com/0WWnKzx.png
[20:11] <beuno> daker, it seems to think it's a click and not a snap
[20:11] <beuno> daker, did you upload it to Ubuntu Core?
[20:11] <beuno> https://myapps.developer.ubuntu.com/dev/click-apps/?format=snap
[20:11] <daker> beuno: yes
[20:12] <daker> https://i.imgur.com/906B4bw.png
[20:12]  * beuno looks
[20:13] <daker> id: 4841
[20:13] <daker> beuno: https://i.imgur.com/Iixkk7h.png
[20:16] <beuno> the review tools aren't happy:
[20:16] <beuno> beuno@beuno-desktop:~/canonical/click-reviewers-tools$ python3 bin/click-review ~/Downloads/micropython.daker_1.7_i386.snap
[20:16] <beuno> ERROR: could not find required 'hooks' in manifest:
[20:16] <beuno> {'architecture': ['i386'],
[20:16] <beuno>  'description': 'MicroPython is a lean and efficient Python implementation for '
[20:16] <beuno>                 'microcontrollers and constrained systems.',
[20:17] <beuno>  'framework': 'ubuntu-core-15.04-dev1',
[20:17] <beuno>  'icon': 'meta/icon.png',
[20:17] <beuno>  'installed-size': '481',
[20:17] <beuno>  'maintainer': 'Adnane Belmadiaf <daker@ubuntu.com>',
[20:17] <beuno>  'name': 'micropython',
[20:17] <beuno>  'title': 'A lean and efficient Python implementation for microcontrollers.',
[20:17] <beuno>  'version': '1.7'}
[20:17] <beuno> daker, how did you build it?
[20:17] <daker> yes that's i saw :D
[20:17] <daker> snapcraft snap
[20:17] <daker> then snapcraft
[20:18] <daker> $ snapcraft -v
[20:18] <daker> snapcraft (1.1.0).
[20:19] <oparoz> 1.1.0 ? :-O
[20:19] <daker> from the ppa :D
[20:19] <oparoz> Ah :D
[20:20] <daker> on 14.04
[20:24] <beuno> so, at this point, I'm not sure
[20:24] <beuno> I'm missing the people who know snapcraft and the reviewers tools today!
[20:25] <beuno> daker, I'll chase this up for you tomorrow with jdstrand
[20:25] <daker> beuno: thanks, i'll give it another try
[20:36] <daker> beuno: do you want to me fil a bug ? just in case you forgot
[20:36] <beuno> daker, sure, that'd be useful to track
[20:52] <stgraber> jdstrand: lxd 2.0 final sent to the snappy store
[20:59] <stgraber> beuno: thanks!
[20:59] <beuno> :)
[20:59] <daker> beuno: https://bugs.launchpad.net/snapcraft/+bug/1569041
[20:59] <ubottu> Launchpad bug 1569041 in Snapcraft "ERROR: could not find required 'hooks' in manifest" [Undecided,New]
[21:19] <kyrofa> daker, I don't think snapcraft ever included hooks in the manifest. Note also that you're using 2.x yaml on a 1.x snapcraft
[21:20] <daker> kyrofa: oh! really
[21:20] <kyrofa> daker, you need to be using this: https://github.com/ubuntu-core/snapcraft/blob/1.x/docs/snapcraft-syntax.md
[21:20] <kyrofa> daker, specifically referring to your use of `apps` instead of `binaries`
[21:21] <daker> i see
[21:22] <daker> kyrofa: what's the recommended version ? 2.x ?
[21:22] <kyrofa> daker, it depends on what your target-- are you wanting to ship snaps targeting 15.04 or 16.04 Snappy ubuntu core?
[21:22] <daker> 15.04
[21:23] <kyrofa> daker, then you're made the right choice. Note however that 15.04 will reach end-of-life soon
[21:23] <kyrofa> Man I can't type today. you've*
[21:23] <daker> :)
[21:24] <kyrofa> daker, basically, Snapcraft 1.x targets pre-xenial, Snapcraft 2.x post-xenial
[21:24] <daker> i see
[21:53] <daker> kyrofa: anyidea if this is correct https://paste.ubuntu.com/15768257/ ?
[21:53] <daker> this result in No such file or directory: '/home/daker/Work/micropython-snappy/snap/bin/micropython'
=== JanC_ is now known as JanC
[21:59] <daker> the binary is in /home/daker/Work/micropython-snappy/snap/usr/local/bin/
[22:06] <kyrofa> daker, yeah that looks correct. Do any parts place the `micropython` executable in bin/
[22:06] <kyrofa> ?
[22:06] <kyrofa> Ah
[22:06] <kyrofa> daker, well then, not correct-- use /usr/local/bin/
[22:06] <kyrofa> Rather, usr/local/bin/
[22:07] <kyrofa> (I can't remember if that's automatically added to the path)
[22:07] <kyrofa> You can try just specifying micropython on its own, see if it is
[22:07] <daker> yes testing
[22:09] <daker> click-review crashed :D
[22:10] <daker> kyrofa: can you please check if the syntax is correct https://paste.ubuntu.com/15768597/ ?
[22:29] <daker> Yay it works :D
[22:30] <daker> beuno: found the issue
[22:30] <daker> well actually kyrofa did
[23:11] <kyrofa> daker, very good :)
[23:12] <daker> kyrofa: and the snap is waiting for review :D
[23:12] <daker> thanks!
[23:12] <kyrofa> daker, no problem. Is that snapcraft bug invalid, then?
[23:17] <daker> kyrofa: yes fixed
[23:25] <Swami_> hi
[23:25] <kyrofa> Hey Swami_, welcome
[23:25] <Swami_> Hi Kyrofa,
[23:26] <Swami_> just wanted to check if this is the irc channel for #snappy?
[23:26] <Swami_> from ubuntu core team
[23:26] <kyrofa> Swami_, it is indeed!
[23:26] <Swami_> thanks, this is my first time here.
[23:26] <Swami_> never used irc before.
[23:27] <kyrofa> Swami_, we're here for questions, though I'll warn you that most people are typically here a bit earlier in the day
[23:28] <Swami_> has anyone tried porting from source (custom kernel) to create their own ubuntu snappy image for a generic amd64 device, just as a first step?
[23:29] <Swami_> I was going through the mail digest for the past year and going through. Is there a list or some kind of writeup if someone has as there are not much info. available in snappy developer website for bringing up a custom kernel.
[23:29] <Swami_> Thanks Kyrofa.
[23:29] <kyrofa> Swami_, the kernel snaps are pretty new
[23:30] <kyrofa> Swami_, but yeah, you should be able to use the kbuild/kernel plugins in Snapcraft to build your kernel snap, then use ubuntu-device-flash to generate an image configured with it
[23:31] <kyrofa> Swami_, thing is, this only applies to xenial, which isn't released yet so it's still changing
[23:31] <kyrofa> Swami_, feel free to play with it, but keep that in mind
[23:32] <Swami_> I was reading through that I need some Apparmor changes, if I wanted to use my custom kernel. say for eg., I downloaded the kernel source from kernel.org and is it possible to use this kernel source to build for snappy's kernel image?
[23:33] <Swami_> sure, got it. I am not there yet. still new to snappy. haven't explored latest releases yet.
[23:34] <kyrofa> Swami_, I'd say it depends on the version
[23:34] <kyrofa> Swami_, I'm afraid I'm also not familiar with how much apparmor has been upstreamed
[23:35] <Swami_> I see. Is there a link which I can refer to build a custom kernel for my own engineering snappy image. Rather than picking the device tar ball from ubuntu server and then just using ubuntu-device-flash for just creating the image using the device tar file.
[23:37] <kyrofa> Swami_, perhaps this will be helpful: http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/