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