| edsiper | is Ubuntu core already released for the Dragonboard _ | 01:30 |
|---|---|---|
| edsiper | ? | 01:30 |
| === chihchun_afk is now known as chihchun | ||
| zyga | good morning | 06:55 |
| shuduo | good morning. | 06:58 |
| shuduo | is there any plan to have classic dimension back? ;) | 06:59 |
| shuduo | should I expect snapcraft working in a chroot environment? | 06:59 |
| zyga | shuduo: I'm sure classic will work though I'm not quite sure when | 07:01 |
| zyga | shuduo: snapcraft and chroot, hmm, I heard that people had issues with kpartx | 07:01 |
| zyga | shuduo: you might be able to snapcraft in a chroot but only construct the squashfs manually or on the outside | 07:01 |
| shuduo | zyga: since no classic environment to build snap app for armhf target, i'm trying to run snapcraft in an armhf chroot. but got msg "Issues while validating snapcraft.yaml: snapcraft validation file is missing from installation path | 07:03 |
| shuduo | " when i build examples | 07:03 |
| zyga | shuduo: maybe try snapcraft from source, I don't know | 07:04 |
| shuduo | zyga: yes, i just pulled it from github and build/install it in chroot. | 07:05 |
| zyga | shuduo: you can also use launchpad to build snaps AFAIR but I haven't used this much | 07:05 |
| shuduo | zyga: sorry never heard of that. how? | 07:06 |
| zyga | I don't really know but from what I remember it's like a PPA | 07:07 |
| zyga | just builds snaps | 07:07 |
| shuduo | zyga: i looked at lp. seems only target amd64 and i386. | 07:11 |
| zyga | ah, too bad | 07:11 |
| dragly | Hi. I'm trying to package an app that is built using one of the newest versions of Qt (5.6 or 5.7). Because these are installed manually, I have written a plugin that copies all *.so libs and QML modules to the install folder. I was getting close to making this work when I encountered an annoying bug. After building and installing the snap 2-3 times, I | 07:48 |
| dragly | always get the following error when running the app: | 07:48 |
| dragly | /bin/sh: 0: Can't open /snap/neuronify/100006/command-neuronify.wrapper | 07:49 |
| dragly | It goes away if I rename the snap and build/install again. Have anyone here seen this before? | 07:49 |
| zyga | dragly: yes, this is already (almost) fixed | 07:49 |
| zyga | dragly: though I don't know if my fix will land or if it will need larger changes | 07:50 |
| zyga | dragly: as a workaround, uninstall and install your snap each time | 07:50 |
| dragly | Oh, okay. I can live with that workaround while developing. Thanks! | 07:50 |
| dragly | That works. Now I just need to figure out how to get access to xkb working. | 08:00 |
| dragly | Do you know if I might be missing some "plugs" when I get this error? | 08:01 |
| dragly | xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb | 08:01 |
| dragly | I already have "plugs: [unity7,opengl,x11,system-observe]" | 08:01 |
| zyga | dragly: you can consult generated apparmor profile but I suspect that nothing grants x11/xkb access | 08:19 |
| zyga | dragly: please open a bug with the details of your snap, I will be working on interfaces a lot this week, | 08:19 |
| dragly | zyga: ok, du you prefer bugs on launchpad or github? | 08:47 |
| zyga | dragly: I think we want launchpad | 08:48 |
| qengho | What's wrong with this? | 08:49 |
| qengho | echo -e 'name: xeyes\nversion: 1\ndescription: eyes\nsummary: toy\napps:\n snapxeyes:\n command: usr/bin/xeyes\n plugs: [ x11 ]\nparts:\n pkg:\n plugin: nil\n stage-packages: [ x11-apps ]' |tee snapcraft.yaml |cat -n | 08:49 |
| qengho | Okay, ignoring a wrapper problem. | 08:57 |
| qengho | $ /snap/bin/xeyes | 08:57 |
| qengho | Bad system call | 08:57 |
| zyga | qengho: try with --devmode | 09:00 |
| zyga | qengho: (remove the snap and install it with --devmode) | 09:00 |
| zyga | qengho: then observe syslog | 09:01 |
| zyga | qengho: also check if the x11 plug is connected | 09:01 |
| zyga | qengho: I had a few people report intersting bugs lately | 09:01 |
| qengho | zyga: https://pastebin.canonical.com/155116/ | 09:05 |
| zyga | qengho: interesting, so you use encrypted home | 09:06 |
| zyga | qengho: you have to add the home plug and connect this | 09:06 |
| zyga | qengho: I'm not sure that it will suffice though | 09:06 |
| zyga | qengho: but please report a bug that snappy won't work at all with encrypted home directory | 09:07 |
| qengho | zyga: https://bugs.launchpad.net/snappy/+bug/1574526 | 09:12 |
| ubottu | Launchpad bug 1574526 in Snappy "snappy doesn't work with encrypted home directory" [Undecided,New] | 09:12 |
| zyga | qengho: thank you | 09:12 |
| === JamesTait is now known as Guest99393 | ||
| zyga | qengho: can you snap install links | 09:17 |
| zyga | qengho: and run links successfully? | 09:18 |
| ara | qengho, I get the same dmesg, but the snap works fine | 09:20 |
| ara | qengho, I got the bad system call the first time (interfaces were disconnected), but uninstalling the snap and installing it agian, solved the issue | 09:20 |
| qengho | zyga: "links" snap works. | 09:21 |
| zyga | qengho, thanks | 09:22 |
| zyga | so it's not encrypted home per se | 09:22 |
| zyga | qengho: is your snap trying to access regular home directory? | 09:22 |
| ara | qengho, if you try uninstalling the snap and reinstalling it, do you get the bad system call again? | 09:23 |
| * zyga wonders if the encrypted-home option is available in the installer anywhere | 09:24 | |
| ara | zyga, you mean ubiquity? | 09:24 |
| ara | zyga, it is | 09:24 |
| zyga | ara: yes, I'm looking but all i see is encrypted / | 09:24 |
| ara | zyga, wait until it asks for your username | 09:24 |
| zyga | ara: ah, thanks | 09:24 |
| ara | zyga, it will have a radio button to encrypt your home | 09:24 |
| ara | qengho, was xeyes the first snap that you installed on your system? | 09:25 |
| qengho | ara: not the first. | 09:26 |
| qengho | $ sudo snap install ./xeyes_1_amd64.snap | 09:27 |
| qengho | [-] Make snap "xeyes" available to the system | 09:27 |
| qengho | $ /snap/bin/xeyes | 09:27 |
| qengho | Bad system call | 09:27 |
| qengho | cmiller@vetinari:/tmp$ sudo snap connect xeyes:x11 ubuntu-core:x11 | 09:27 |
| qengho | [|] Connect xeyes:x11 to ubuntu-core:x11 | 09:27 |
| qengho | cmiller@vetinari:/tmp$ /snap/bin/xeyes | 09:27 |
| qengho | Bad system call | 09:27 |
| zyga | qengho: and with devmode you get those messages about ~/.Private? | 09:29 |
| zyga | qengho: currently we don't get notices about seccomp denials in --devmode | 09:29 |
| ara | zyga, the .ecryptfs messages are always shown | 09:30 |
| ara | zyga, even without --devmode | 09:30 |
| === vrruiz_ is now known as rvr | ||
| ara | zyga, and even if the app works fine (like links) | 09:30 |
| ara | zyga, for me, if I launch links successfully, I still get those messages | 09:30 |
| zyga | odd | 09:31 |
| zyga | thanks! | 09:31 |
| qengho | Yes, "links" also causes four ecryptfs DENIED rw | 09:31 |
| qengho | But no crash | 09:31 |
| zyga | qengho: apparmor gives EPERM but seccomp gives you sigkill | 09:32 |
| ara | zyga, I thought that was going to change | 09:34 |
| zyga | ara: I don't think it did yet | 09:34 |
| qengho | Okay, so it's not dependent on ecryptfs. | 09:34 |
| zyga | ara: because seccomp needs kernel work | 09:34 |
| qengho | Is it? | 09:34 |
| === Guest99393 is now known as JamesTait | ||
| qengho | Okay, so this bug is not dependent on ecryptfs? | 09:35 |
| zyga | qengho: it seems it's not | 09:35 |
| qengho | zyga: Your xeyes runs, then? | 09:35 |
| zyga | qengho: I'm still setting up an env | 09:36 |
| zyga | qengho: I'll try on my host | 09:36 |
| zyga | qengho: xeyes doesn't run | 09:42 |
| zyga | kwi 25 11:44:15 zyga-thinkpad-w510 kernel: audit: type=1326 audit(1461577455.555:55): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=16555 comm="xeyes" exe="/snap/xeyes/100001/usr/bin/xeyes" sig=31 arch=c000003e syscall=51 compat=0 ip=0x7f3da9445df7 code=0x0 | 09:44 |
| zyga | that is getsockname | 09:45 |
| * zyga looks at snappy source | 09:45 | |
| zyga | qengho: it doesn't work because x11 doesn't include that profile | 09:46 |
| zyga | qengho: unity7 will work | 09:46 |
| zyga | qengho: I just confirmed that it works with unity7 plug | 09:48 |
| zyga | qengho: I've updated the bug | 09:48 |
| zyga | with everything is a file/everything is over a socket, I find snappy interfaces related to networking rather limited | 09:49 |
| qengho | zyga: With devmode, it runs with no crash. Same dmesg output. | 09:49 |
| zyga | apparmor will need more work | 09:50 |
| zyga | qengho: change to "plugs: [unity7]" | 09:50 |
| zyga | qengho: then it works for me | 09:50 |
| * qengho boggles. | 09:51 | |
| zyga | qengho: I've updated the bug | 09:51 |
| qengho | *Should* it have unity7 as plug? | 09:51 |
| zyga | qengho: no | 09:51 |
| zyga | qengho: it's just a bug | 09:51 |
| qengho | Okay, so I'm trying to figure out how to report it. "snappy's x11 plug doesn't work for 'getsockname' syscall"? | 09:54 |
| zyga | qengho: I renamed the existing bug | 09:54 |
| zyga | qengho: have a look | 09:54 |
| qengho | zyga: ah, perfect. Thank you. | 09:55 |
| qengho | zyga: I don't get that syscall=51 log message. Am I running stale software, or a different bug causes it to be missing? | 09:58 |
| zyga | qengho: it's a bug | 09:58 |
| zyga | qengho: that message says "getsockname is denied" | 09:58 |
| zyga | qengho: it's a bug in snappy | 09:58 |
| zyga | qengho: the message is obviously cryptic :/ | 09:59 |
| qengho | I was just worried about *silence*. | 10:08 |
| qengho | Cryptic is fine. I've used linux since 1995. Cryptic, I got. | 10:08 |
| zyga | I reported https://bugs.launchpad.net/snappy/+bug/1574556 | 10:10 |
| ubottu | Launchpad bug 1574556 in Snappy "apparmor denials reported for encryped HOME" [Undecided,New] | 10:10 |
| zyga | qengho: FYI: https://github.com/ubuntu-core/snappy/pull/1069 | 10:22 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/1069 | 10:22 |
| dpm | hey all could someone ask this user on Ask Ubuntu? It seems their snappy system is locked due to errors (see the pastebin in the last comment) http://askubuntu.com/a/760782/9781 | 10:29 |
| dpm | sorry, not *ask, I meant help | 10:29 |
| dpm | I'm just wondering what the way is to recover from those errors they see on the output of `snap changes` | 10:30 |
| zyga | dpm: snap changes errors are harmless | 10:34 |
| zyga | dpm: they are just a trace that something went wrong | 10:34 |
| zyga | dpm: it seems that people still install using "$snap.$origin" (instead of just $snap) | 10:35 |
| zyga | dpm: the error with revision 2 there seems interesting though | 10:36 |
| dpm | zyga, thanks. Not sure, in that case, they're saying the install command was `sudo snap install ubuntu-clock-app` | 10:36 |
| zyga | dpm: yes, that was the command that was tried next | 10:36 |
| dpm | ah, I see what you mean now | 10:37 |
| dpm | zyga, any ideas on what to recommend? | 10:38 |
| zyga | dpm: I'm responding on askubuntu now | 10:38 |
| dpm | awesome, thanks! | 10:38 |
| qengho | zyga: what's the answer? How does he recover? I tried 'strace'ing once to find out. | 10:47 |
| qengho | I think the strace didn't pass through launcher. I think. | 10:47 |
| zyga | qengho: I don't know what his problem is yet | 10:47 |
| zyga | qengho: I asked for additional information: http://askubuntu.com/a/762340/532607 | 10:48 |
| zyga | qengho: at the end of the day it should be possible to wipe snappy state entirely | 10:48 |
| plars | zyga: not sure what josepht and popey were seeing, but even with your devtools script, I get a kernel oops on mount with xenial on my laptop, and on a trusty system I get this: failed to install "canonical-pc" from "edge": canonical-pc failed to install: [--root /tmp/diskimage700808732/system enable snap-canonical\x2dpc-5.mount] failed with exit status 0: | 10:52 |
| zyga | plars: odd, I just tested this (including booting) on 0a58844b8b48b2c5d08154b44edd182287e6c589 | 10:55 |
| zyga | plars: seems like a bug in udf | 10:55 |
| plars | zyga: is that the sha1 of your udf? That's not what I have | 10:58 |
| popey | fails here too | 10:58 |
| * popey replied with pastebin to the list | 10:58 | |
| plars | popey: do you get the oops also? | 10:59 |
| popey | yes | 11:00 |
| popey | http://paste.ubuntu.com/16046785/ is my dmesg | 11:00 |
| popey | gah, that mount process is unkillable | 11:01 |
| ogra_ | sounds more like a kpartx bug | 11:04 |
| zyga | plars: no, that's the head of devtools I'm on | 11:07 |
| zyga | ouch [ 588.493709] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 | 11:07 |
| zyga | kernel bugz | 11:07 |
| cjwatson | shuduo: LP, amd64/i386> No, that's not true. amd64 and i386 are the default architectures, but you can use "Change details" on the snap to enable any architecture for which we have good virtualised sandboxing, so any of armhf/arm64/ppc64el. | 11:10 |
| * ogra_ notes we have working yakkety image builds | 11:10 | |
| zyga | ogra_: snappy images? :) | 11:14 |
| ogra_ | zyga, sure | 11:16 |
| zyga | ogra_: where are those published? | 11:17 |
| ogra_ | nowhere atm ... you'd have to grab the snaps yourself | 11:17 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ | 11:17 |
| ogra_ | (and i'm nt sure what we should do with these snaps ... we dont have a 16.10 channel in the store) | 11:20 |
| ara | zyga, autopilot.service execs "/usr/bin/snap refresh", but that command expects a snap name (or fails if it doesn't have it) | 11:28 |
| ara | zyga, known bug? or something missing? | 11:28 |
| zyga | ara: known bug | 11:34 |
| zyga | ara: (we knew about this before releae) | 11:34 |
| ara | zyga, but something that it is going to be addressed at some point? shall I file a bug as reminder? | 11:35 |
| zyga | ara: yes, certainly, we have a card for this, there's a bug as well somewhere AFAIR | 11:36 |
| ara | zyga, can you point me to the card, please? | 11:36 |
| zyga | ara: https://trello.com/c/l1EpwBoT/98-re-enable-auto-refreshing-autopilot | 11:37 |
| zyga | ara: here you go :) | 11:37 |
| ara | zyga, fantastic, thanks | 11:37 |
| * zyga refreshed the fix for bug https://github.com/ubuntu-core/snappy/pull/1049 | 11:53 | |
| === zyga_ is now known as zyga | ||
| kyrofa | Good morning | 12:09 |
| === zyga_ is now known as zyga | ||
| kyrofa | mcphail, not sure if you got your question answered, but the ownCloud snap isn't compatible with the desktop just yet | 12:12 |
| kyrofa | I hasn't been released for Snappy 16-- it's still using rolling | 12:13 |
| ssweeny | niemeyer, zyga, so what are next steps for https://github.com/ubuntu-core/snappy/pull/1037 ? | 12:19 |
| sergiusens | morning | 12:21 |
| dpm | JamesTait, beuno, in the store, what's the difference between 'Make private' and 'Unpublish' for a snap? | 12:24 |
| sergiusens | dragly in case our question hasn't been answered `export QT_XKB_CONFIG_ROOT=` to some path in your snap and maybe also stage-package xkb-data | 12:24 |
| sergiusens | zyga ^ | 12:24 |
| JamesTait | dpm, "Make private" puts the package behind an ACL, whereas "Unpublish" removes it from the store. | 12:25 |
| JamesTait | I suspect your next question might be "How do I set up an ACL?" and I think the answer is that you have to share the package, but it's a part of the UI I'm not familiar with. | 12:26 |
| zyga | ssweeny: AFK, I'll reply in ~1 hour | 12:30 |
| ssweeny | zyga, ack | 12:30 |
| dpm | JamesTait, thanks. Actually, my next question was going to be... what's an ACL? :) | 12:34 |
| JamesTait | dpm, Access Control List. 😉 | 12:34 |
| dpm | oh, ok | 12:34 |
| dpm | thanks | 12:35 |
| JamesTait | dpm, so you might use it, for example, to allow members of your QA team to download a binary from the edge channel to test it before promoting it to stable. | 12:35 |
| dpm | JamesTait, ok | 12:36 |
| mcphail | kyrofa: thanks! | 12:51 |
| dpm | nice one, thanks for the askubuntu answer on snap refresh ara! | 12:55 |
| beuno | dpm, private snaps are only available to ~canonical, I think | 12:56 |
| beuno | (atm) | 12:56 |
| dragly | sergiusens: Thanks! I'll try that out. | 12:58 |
| === devil is now known as Guest27374 | ||
| dholbach | sergiusens, kyrofa: when do we want to do the clinic? | 12:59 |
| kyrofa | dholbach, I thought it was tomorrow? | 12:59 |
| dholbach | did we say tomorrw at 15 UTC (the community Q&A slot)? | 12:59 |
| dholbach | just wanted to double-check, so I can announce it now :) | 13:00 |
| === Guest27374 is now known as devil_ | ||
| Unser | Hello, were do I get the builds for raspberry pi 3? | 13:12 |
| kyrofa | dholbach, yeah we didn't set a time, but I think 15 UTC works fine | 13:14 |
| dholbach | kyrofa, perfect | 13:14 |
| dholbach | sergiusens, ^ does that work for you too? | 13:14 |
| sergiusens | dholbach I guess; with our current state though I wish we could push it another week, not sure what kyrofa thinks about that :-P | 13:17 |
| sergiusens | anytime is good tomorrow fwiw | 13:17 |
| kyrofa | I don't mind pushing | 13:17 |
| kyrofa | That's a good point actually | 13:17 |
| dholbach | the week after is UOS | 13:18 |
| dholbach | that's a good time for demos and stuff anyway | 13:18 |
| kyrofa | dholbach, snappy 16 is not on ubuntu core yet-- weird situation | 13:18 |
| dholbach | kyrofa, I'm not sure I understand | 13:18 |
| zyga | ssweeny: I'll catch up with the conversation on that pull request now | 13:19 |
| kyrofa | dholbach, unless things have changed since I used edge, snappy on the desktop and snappy on ubuntu core are different | 13:19 |
| ssweeny | zyga, great, much appreciated :) | 13:19 |
| dholbach | sergiusens, ^ what do you think? | 13:20 |
| dholbach | do you think the week after things should be better? | 13:20 |
| sergiusens | kyrofa we only care about snaps on the desktop/server though (for now) | 13:20 |
| kyrofa | sergiusens, ah, okay good to know | 13:21 |
| sergiusens | dholbach I am +1, let's see what olli| thinks | 13:21 |
| kyrofa | sergiusens, what "state" were you referring to, then, regarding pushing? | 13:22 |
| * olli| scrolls | 13:22 | |
| sergiusens | kyrofa producing a full fledged desktop snap | 13:22 |
| sergiusens | not enough interfaces ready yet | 13:22 |
| sergiusens | or known issues made known :-) | 13:23 |
| kyrofa | sergiusens, ah, true. None of your attempts worked out either, huh? | 13:23 |
| sergiusens | kyrofa not really; I will know more this after the group meeting | 13:24 |
| ogra_ | well, it could be a developer desktop ;) installed with --devmode | 13:24 |
| kyrofa | ogra_, hahaha | 13:24 |
| sergiusens | kyrofa but the fact that most apps use network manager to get info about connectivity status brings down a lot of options | 13:24 |
| sergiusens | ogra_ hah | 13:25 |
| zyga | ssweeny: so looking at this I think we want to implement the per-connection thing better, I'll fork this and give you a patch | 13:48 |
| ssweeny | zyga, ok fair enough | 13:48 |
| zyga | ssweeny: quick question, how do you test this? | 14:00 |
| ssweeny | zyga, I do a smoke test in a vm with your devtools scripts then have someone with a snappy system w/ bluetooth hardware exercise it | 14:01 |
| ssweeny | zyga, I use this snap btw https://code.launchpad.net/~ssweeny/+snap/bluez | 14:03 |
| zyga | ssweeny: and the VM, I assume it doesn't have bluetooth, or does it? | 14:03 |
| ssweeny | zyga, it doesn't, so I only test that bluetoothctl can connect to the daemon | 14:04 |
| zyga | ok | 14:04 |
| zyga | ah, right | 14:04 |
| zyga | that's all I need, thanks! | 14:04 |
| ssweeny | yw | 14:04 |
| seb128 | dpm, hey, is the store supposed to list things calculator? is it amd64 only or supposed to work on i386 as well? | 14:08 |
| seb128 | is there a snap status command or equivalent? | 14:09 |
| popey | seb128: its an amd64 only build I believe | 14:11 |
| seb128 | k, that explains -:/ | 14:11 |
| seb128 | :-/ | 14:11 |
| seb128 | popey, thanks | 14:11 |
| popey | despite it being qml only, it's got lots of binaries lobbed in to make it work | 14:11 |
| dpm | seb128, the x86 build does not work for some reason | 14:12 |
| seb128 | I see you guys look down on us i386 users :p | 14:12 |
| dpm | seb128, you mean *user? :P | 14:12 |
| seb128 | :-) | 14:13 |
| dpm | :) | 14:13 |
| seb128 | k, next question | 14:13 |
| seb128 | $ sudo snap install hello-world | 14:13 |
| seb128 | error: can't install "hello-world": snap "ubuntu-core" has changes in progress | 14:13 |
| seb128 | how do I figure out what's going on? | 14:13 |
| dpm | seb128, I actually did an x86 build, but gets a "Bad system call" message when executed on an x86 machine | 14:13 |
| seb128 | there is no status command? | 14:13 |
| dpm | seb128, `snap changes` perhaps | 14:13 |
| dpm | and then `snap changes $CHANGEID` to zoom in | 14:13 |
| seb128 | thanks | 14:14 |
| josepht | I'm having checksum mismatches when I build a snap on my rpi2 and try to upload it to the store. I'm building in a chroot on the device itself. | 14:15 |
| popey | seb128: when I had the "changes in progress" issue, the only resolution I had was to nuke my snappy config (and apps) from orbit :( | 14:15 |
| === jgrimm-afk is now known as jgrimm | ||
| seb128 | popey, where do those live? | 14:16 |
| popey | so i had to stop the snapd service, umount /snap/*/* and rm all of /var/lib/snapd/* iirc | 14:16 |
| popey | then reinstall snapd and snap install ubuntu-core | 14:16 |
| josepht | seb128: reset-state from here should do it. https://github.com/zyga/devtools | 14:16 |
| popey | it "fixed" it for me | 14:16 |
| popey | ooh, we even scripted it! | 14:17 |
| seb128 | josepht, popey, thanks | 14:17 |
| josepht | seb128: my pleasure | 14:17 |
| olli| | sergiusens, let's chat in the team mtg | 14:26 |
| === willcooke is now known as wllck | ||
| zyga | ssweeny: hey, this is a totally crude attempt at this | 14:44 |
| zyga | ssweeny: I'll build the snap next but I wanted to show you https://github.com/zyga/snappy/commits/bluez-fix-rules | 14:44 |
| zyga | ssweeny: one thing I could do is to look at all the apps in the slot | 14:47 |
| zyga | ssweeny: and let the sender (with the plug) talk to each of those apps specifically | 14:47 |
| zyga | ssweeny: I'm not sure we want that though | 14:47 |
| zyga | jdstrand: hey, are you around? | 14:47 |
| dragly | Is there a way to set LD_LIBRARY_PATH, or do I need to run a script that does this before executing a C++ executable? | 14:54 |
| zyga | dragly: AFAIR we set something, let me check | 14:55 |
| ogra_ | the launcher does that automatically for a bunch of dirs ... | 14:55 |
| zyga | dragly: what do you need specifically? | 14:55 |
| ogra_ | (just make sure your libs are in the right location inside the snap) | 14:55 |
| dragly | I'm trying to set the QT_XKB_CONFIG_ROOT you mentioned, which made me set up a script that does this first | 14:56 |
| dragly | this however, required me to set LD_LIBRARY_PATH, and now I get "Could not initialize GLX", which lead me to believe that I might have set something the wrong way that shadows the OpenGL libs. | 14:56 |
| zyga | dragly: opengl stuff is handled separately | 14:57 |
| zyga | one sec | 14:57 |
| ogra_ | well, just make sure to always keep the existing LD_LIBRABRY_PATH if you actually append anything to it | 14:57 |
| zyga | dragly: we set SNAP_LIBRARY_PATH | 14:57 |
| zyga | to /var/lib/snapd/lib/gl: | 14:58 |
| zyga | looking what picks that up | 14:58 |
| zyga | the launcher is not | 14:58 |
| zyga | I guess you want your wrapper | 14:58 |
| dragly | I just need to set the QT_XKB_CONFIG env variable, so any way that enables me to do that without breaking OpenGL is what I need | 14:59 |
| dragly | seems like setting LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SNAP_LIBRARY_PATH didn't help | 14:59 |
| dragly | I must have messed up something else | 15:00 |
| dragly | is there a way to set env variables in the yaml? | 15:01 |
| zyga | nope | 15:01 |
| dragly | is launching the app like this in my wrapper the right way to do it? | 15:02 |
| dragly | $SNAP/bin/neuronify | 15:02 |
| zyga | yep | 15:03 |
| zyga | that will work | 15:03 |
| * zyga finished meeting and returns to bluez interface and snap | 15:06 | |
| josepht | sergiusens: are you able to build snaps with snapcraft on rpi2 and successfully upload to the store? | 15:09 |
| shuduo | cjwatson: let me try. thanks! | 15:09 |
| sergiusens | josepht what are you seeing? my rpi2 has been in the closet for a while; kyrofa has been playing with one though | 15:10 |
| sergiusens | josepht just in case you are missig the snap registration added last week (you need to go to the store and register the name yourself) | 15:11 |
| josepht | sergiusens: the snap fails to upload due to a checksum mismatch. I have registered the name. | 15:11 |
| sergiusens | dragly $SNAP/bin is in PATH so just `command: neuronify` should be enough | 15:12 |
| sergiusens | josepht oh; don't know about that; the store guys wrote the upload code for us; so not deeply familiar with it; I'll check or maybe be lazy and ask vila | 15:12 |
| dragly | sergiusens: Thanks. Still getting the same error about it being unable to initialize GLX. I think it comes from Qt, but I don't know what its missing. | 15:13 |
| dragly | sergiusens: Adding the QT_XKB_CONFIG_ROOT helped me get a step further, though. | 15:13 |
| josepht | sergiusens: I don't think it's related to the store though. I checked the last time I uploaded an rpi2 snap and I get a different checksum if I unsquashfs and resquashfs the snap using the commands from the snapcraft source (at the time) | 15:14 |
| dragly | Are there any OpenGL packages I should consider adding to stage-packages? | 15:15 |
| zyga | dragly: I don't think you should | 15:15 |
| sergiusens | dragly that I don't know, not a GUI person myself; I will fwd you to kgunn for the GLX question | 15:16 |
| kyrofa | josepht, sergiusens sorry guys, my rpi2 snap takes an entire day to build on the rpi so I started using the LP builders and uploading directly to myapps | 15:17 |
| sergiusens | kyrofa smart ;-) | 15:18 |
| vila | josepht: the upload doesn't (and won't) upload the checksum but I think the store checksums the /file/, not its content, but rebuilding the squashfs may change the resulting file | 15:18 |
| kyrofa | josepht, fails to upload, or fails review? | 15:19 |
| josepht | kyrofa: fails review | 15:19 |
| kgunn | dragly: sorry, can you briefly explain what you're up to? i presume building a qml app snap to run on 16.04 desktop? | 15:22 |
| dragly | kgunn: I suppose I'm pushing the limits here. I'm building an app with Qt5.7 (we need QtCharts) and trying to pack it with snapcraft. | 15:23 |
| dragly | I have made a custom plugin that copies all QML modules and Qt libs to the install folder. | 15:24 |
| kgunn | dragly: hmm...are you digging into our example here as a guide/for instance? | 15:25 |
| kgunn | http://bazaar.launchpad.net/~snappers/snappy-desktop-examples/trunk/files/head:/ubuntu-clock-app/ | 15:25 |
| dragly | So far so good, I've gotten all errors about missing platforms, QML modules and libraries to go away, but now I'm stuck with the error "Could not initialize GLX". | 15:25 |
| kgunn | you can see the clock.wrapper has all the env set | 15:25 |
| kgunn | dragly: so, accessing gl drivers provided by the host system in ubuntu-core is a very new feature... | 15:26 |
| dragly | nice, I'll have a look at it and see if I can add anything I'm missing. Thanks! | 15:26 |
| kgunn | so if you'd be willing to share all your work, it's possible you're just hitting a bug or unforeseen iss | 15:26 |
| kgunn | dragly: yep, try to look at the example first... | 15:26 |
| kgunn | if you think you've got it...and still hitting it, then file a bug on ubuntu-core with your work | 15:27 |
| kgunn | thanks for being an early adopter | 15:27 |
| zyga | tyhicks: hey, have you seen jamie today? | 15:29 |
| kyrofa | zyga, I believe he's out today | 15:30 |
| zyga | ah | 15:30 |
| zyga | thanks | 15:30 |
| tyhicks | zyga: hey - he'll be back tomorrow | 15:31 |
| zyga | tyhicks: do you have time for a quick apparmor question? | 15:31 |
| tyhicks | zyga: sure | 15:31 |
| zyga | tyhicks: is it safe/okay to use #include statements inside a particular profile? | 15:32 |
| zyga | tyhicks: normally we include bits earlier | 15:32 |
| zyga | tyhicks: but one interface we're working on now does that per plug connection | 15:32 |
| tyhicks | zyga: are you asking if the #include has to happen at the top of the profile? | 15:32 |
| zyga | yep | 15:33 |
| tyhicks | zyga: #include's can go anywhere | 15:33 |
| zyga | ah, thanks! | 15:33 |
| tyhicks | no problem | 15:33 |
| tyhicks | zyga: the parser simply inserts the contents of the #included file right where the #include is found so you'll be fine as long as the inserted contents do not cause a compiler error | 15:34 |
| josepht | kyrofa: how do I use the LP builders to build my snap? | 15:38 |
| kyrofa | josepht, it's actually pretty easy. First of all, you need to have an LP project, and push your code there | 15:39 |
| kyrofa | josepht, are you hosting your code there already, or elsewhere? | 15:39 |
| josepht | kyrofa: nowhere yet :) | 15:39 |
| kyrofa | josepht, ah! | 15:39 |
| josepht | kyrofa: I'll setup a project and push my code there | 15:40 |
| kyrofa | josepht, yeah, create an LP project and either use bzr or git to get your code up there. Once you have that, come back and I'll continue walking you through :) | 15:40 |
| sergiusens | kyrofa josepht should even work from +junk | 15:43 |
| josepht | sergiusens, kyrofa: the builder uses 'architectures' from snapcraft.yaml? | 15:45 |
| cjwatson | josepht: not yet | 15:46 |
| josepht | okay | 15:46 |
| josepht | kyrofa: I've got my project pushed | 15:46 |
| cjwatson | josepht: https://bugs.launchpad.net/snapcraft/+bug/1533713 | 15:46 |
| ubottu | Launchpad bug 1533713 in Snapcraft "Add metadata describing the architectures that a snap can be built for" [Wishlist,Triaged] | 15:46 |
| kyrofa | josepht, click on the branch you pushed | 15:47 |
| cjwatson | josepht: (i.e. currently that field does not appear to have the semantics we need) | 15:47 |
| kyrofa | josepht, and one of the options should be to "Creat a snap package" | 15:47 |
| kyrofa | with an e in there somewhere | 15:47 |
| josepht | kyrofa: check | 15:48 |
| cjwatson | kyrofa: as sergiusens says, you really don't need a full project, and a full project is likely inappropriate in most cases | 15:48 |
| kyrofa | cjwatson, sergiusens alright thanks :) | 15:48 |
| sergiusens | cjwatson https://lists.ubuntu.com/archives/snappy-app-devel/2016-April/000654.html in case you have an opinion; sorry I forgot to link that to the bug | 15:48 |
| cjwatson | I mean, not a project just for the snap stuff. If there's an existing upstream project for the thing you're packaging then it would normally make sense to put the branch in there | 15:49 |
| kyrofa | josepht, so you have a snap, but I believe by default it'll only build for x86 and amd64 | 15:49 |
| kyrofa | josepht, so select the snap package, and go to "Edit snap package" | 15:49 |
| kyrofa | josepht, select the archs you want | 15:49 |
| cjwatson | sergiusens: can't say I really care about the exact name :) | 15:50 |
| sergiusens | cjwatson ok; I was planning on fixing it last week but chasing the snapd story consumed most of our time | 15:50 |
| kyrofa | josepht, then you should be able to hit "Request builds" on the snap package | 15:50 |
| cjwatson | sergiusens: sure; likewise probably won't get round to the LP side of it for a little bit, need to focus on the auto-upload-to-store story | 15:51 |
| cjwatson | sergiusens: but it would at least make it possible :) | 15:51 |
| kyrofa | cjwatson, what are the limitations on the snap name? Do they need to be unique? Unique to the project? Unique to the user? | 15:52 |
| josepht | kyrofa: ack. My branch will need to have the source in it as well. i.e. it can't pull from github.com? | 15:52 |
| === chihchun is now known as chihchun_afk | ||
| oparoz | What's the easiest way to add a path to the Snap's LD_LIBRARY_PATH from Snapcraft? | 15:53 |
| kyrofa | josepht, ah, indeed. I host on github as well, but push to LP for building. Anything beyond that (auto-sync or whatever) is a question for cjwatson probably | 15:53 |
| kyrofa | oparoz, write a wrapper | 15:53 |
| josepht | pwd | 15:54 |
| josepht | :) | 15:54 |
| cjwatson | kyrofa: unique to the user | 15:54 |
| oparoz | kyrofa, It's already in a wrapper since it's in an init script, but I don't want to have to deal with the various paths used by various architectures | 15:54 |
| oparoz | kyrofa, so wondering if that path could be "built" while creating the snap | 15:55 |
| cjwatson | kyrofa: usual naming constraints for names of things on LP, basically alphanumeric plus [+.-], with the first character alphanumeric only | 15:55 |
| cjwatson | josepht: git-to-git imports are on the near-term plan; in the meantime, just mirror stuff to LP manually | 15:56 |
| kyrofa | cjwatson, can multiple branches be associated with the same snap? | 15:56 |
| josepht | cjwatson: ack, thanks | 15:56 |
| cjwatson | josepht: but I think both kyrofa and I misunderstood your question slightly | 15:56 |
| cjwatson | josepht: only the snapcraft.yaml needs to be in a branch hosted on LP; the rest can be pulled from github or wherever | 15:57 |
| josepht | cjwatson: oh! hrm, my amd64 build failed to clone the nmap repo from github | 15:57 |
| kyrofa | cjwatson, ah, good catch. josepht I assumed the repo you were referring to WAS the snapcraft.yaml | 15:57 |
| cjwatson | kyrofa: snapcraft.yaml can reference whatever it likes. the only thing LP knows about directly is the branch that contains snapcraft.yaml, and it only makes sense for there to be one of those | 15:58 |
| cjwatson | josepht: URL? | 15:58 |
| josepht | cjwatson: https://launchpadlibrarian.net/256016424/buildlog_snap_ubuntu_xenial_amd64_nmap_BUILDING.txt.gz | 15:58 |
| kyrofa | cjwatson, I was more thinking for a little CI infrastructure around a snap being creating by multiple devs collaborating. I actually have PRs and stuff coming in for the owncloud snap, and I'd like to get snaps automatically building. Those are multiple branches | 15:59 |
| kyrofa | oparoz, you could make use of the SNAP_ARCH variable, or you could add it to a local plugin (or just a part with a Makefile) to generate it at build time | 16:00 |
| cjwatson | josepht: could you give me the URL that contains /+build/ instead? | 16:00 |
| kyrofa | The part with a Makefile would probably be easier | 16:00 |
| cjwatson | kyrofa: no, that doesn't exist. you could fairly easily just create the necessary snap objects on the fly though. | 16:00 |
| kyrofa | cjwatson, just name then randomly, essentially? | 16:01 |
| kyrofa | cjwatson, or delete when done? | 16:01 |
| cjwatson | kyrofa: either | 16:01 |
| kyrofa | cjwatson, sounds good | 16:01 |
| oparoz | Thanks kyrofa. I'll give it a try. I'm currently using a nil plugin since it's just adding a deb | 16:01 |
| kyrofa | cjwatson, and I just noticed the web hooks there as well | 16:02 |
| josepht | cjwatson: https://code.launchpad.net/~joetalbott/+snap/nmap/+build/777 | 16:02 |
| kyrofa | cjwatson, how long to the built snaps live before they're removed? | 16:02 |
| cjwatson | josepht: only http/https is proxied; you need to use https:// rather than git:// | 16:04 |
| josepht | cjwatson: ah, thanks | 16:05 |
| cjwatson | kyrofa: there's actually no pruning right now, but there should be; expect no more than a couple of days | 16:06 |
| kyrofa | cjwatson, yeah that seems reasonable | 16:06 |
| sborovkov | Hi. I see this variable - "SNAP_USER_DATA=/root/snap/screenly-client/100001" -> Is this basically home directory for the snap? | 16:07 |
| kyrofa | sborovkov, a similar question was recently asked here: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data | 16:07 |
| josepht | kyrofa: thanks a bunch for helping me | 16:09 |
| josepht | cjwatson: thank you for helping as well | 16:09 |
| cjwatson | np | 16:09 |
| kyrofa | josepht, hey any time. Thanks to cjwatson for putting it all in place! | 16:09 |
| sborovkov | kyrofa: cool, that's what I was interested in, thanks | 16:11 |
| cjwatson | kyrofa: (but we'll probably try to get auto-upload to the store working before we start pruning; there aren't so many snaps at the moment so we should be able to get away with that) | 16:12 |
| kyrofa | cjwatson, good to know, but I'll make sure I don't rely on it :) | 16:13 |
| kyrofa | Hey ogra_ I'm curious what magic you go through to create OS snaps. I don't suppose that's documented anywhere? | 16:13 |
| ogra_ | kyrofa, livecd-rootfs/live-build builds a normal rootfs like you'd do for any other image ... at the point where that gets usually tarred up we intercept and create a snap meta dir and call snapcraft snap | 16:15 |
| dpm | wow, really nice answer kyrofa, thanks! -> http://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data | 16:15 |
| kyrofa | ogra_, oh that's pretty easy, okay | 16:15 |
| kyrofa | dpm any time! | 16:15 |
| ogra_ | kyrofa, line 322-346 http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/build#L322 is the code we actually use to snap it up | 16:16 |
| kyrofa | ogra_, excellent, thank you! | 16:17 |
| ogra_ | if you want to set up your own build env, perhaps take a look at project-rootstock-ng (rather outdated, but the principle didnt change) | 16:17 |
| dpm | JamesTait, beuno, what exactly can I use the share link in a snap for? Which kind of access does it grant in the store to the people I send it to? | 16:17 |
| kyrofa | ogra_, isn't rootstock deprecated though? (https://wiki.ubuntu.com/ARM/RootStock) why use that instead of live-build? | 16:20 |
| ogra_ | kyrofa, -ng ... it is deprecated, but -ng is a wrapper around live-build | 16:20 |
| kyrofa | ogra_, ahh | 16:20 |
| ogra_ | just so you get an impression how your build chroot should be set up | 16:21 |
| ogra_ | (and the env around it) | 16:21 |
| kyrofa | ogra_, gotcha, exactly what I was looking for, thank you :) | 16:21 |
| JamesTait | dpm, I'm not actually completely sure. IIRC, it gives you permission to download the package from a device, so in that respect it's similar to having store reviewer permissions. I think it also gives you permission to manage the package through the web UI, as if it were your own. | 16:22 |
| dpm | JamesTait, ah, the latter is the bit I'm interested in, so I guess it's a way to have a team manage package uploads and editing metadata, right? | 16:23 |
| JamesTait | e.g. I have a snap package that someone shared with me, and I can upload a new revision, unpublish, make it private, and edit at least some of the metadata. | 16:23 |
| JamesTait | Exactly. ☺ | 16:23 |
| dpm | ah, great, exactly what I was looking for :) | 16:23 |
| oparoz | Is it Snapcraft or the store which signs snaps? | 16:33 |
| kyrofa | oparoz, the store | 16:33 |
| oparoz | Thanks kyrofa | 16:34 |
| wililupy | Do any of you know of a way to actually see the package contents of a .snap? | 16:36 |
| oparoz | unsquashfs | 16:36 |
| wililupy | I didn't think of that. I'm trying to see why my kernel.snap says there is no kernel and yet is 74MB. | 16:37 |
| ogra_ | All modules ? ;) | 16:37 |
| sergiusens | oparoz you will eventually be able to sign snaps as well | 16:40 |
| oparoz | Is there a helper in snappy which writes users to extrausers or do we need to echo users to those files? | 16:40 |
| oparoz | Thanks sergiusens | 16:40 |
| sergiusens | oparoz iirc adduser worked | 16:41 |
| sergiusens | ogra_ didn't I add a flag to write to extrausers, or maybe you did? | 16:42 |
| oparoz | sergiusens, it might be because I'm using an older version of core, but it fails | 16:43 |
| oparoz | groupadd: cannot lock /etc/group; try again later. | 16:43 |
| sergiusens | kyrofa one step further with electron; although nodejs is hurting my brain! | 16:51 |
| kyrofa | sergiusens, haha, I believe it! | 16:51 |
| ogra_ | oparoz, yu need the --extrausers arg for adduser | 16:58 |
| ogra_ | oparoz, though why would you even add users there at all ? your snap should surely not use the system password db | 16:58 |
| oparoz | ogra_, without adding any other flags, it still fails with: /usr/bin/chfn: unrecognized option '--extrausers' | 16:59 |
| oparoz | ogra_, but you're right, I may not need extra users. I'm testing things. It's for a Samba server | 17:00 |
| ogra_ | you can ignore that bit (there is a bug open for it i need to SRU) | 17:00 |
| ogra_ | (the chfn) | 17:00 |
| oparoz | ogra_, thanks for the heads up about the bug | 17:00 |
| kyrofa | sergiusens, elopio I totally lost track of time | 17:15 |
| sergiusens | kyrofa oh, me too, no worries; let's skip and keep on rolling desktop snaps | 17:16 |
| kyrofa | sergiusens, whew, okay sounds good | 17:16 |
| sergiusens | kyrofa any luck on your side? | 17:16 |
| edsiper | is Ubuntu core already released for the Dragonboard _ | 17:17 |
| edsiper | ? | 17:17 |
| kyrofa | sergiusens, no. I finished fleshing out the indicators/notifications bug, now I'm hunting for another qt example to snap | 17:18 |
| kyrofa | sergiusens, I'm gonna go with the simple text editor. That shouldn't require any special interfaces | 17:20 |
| kyrofa | sergiusens, have you messed with .desktop files yet? | 17:23 |
| wililupy | I'm trying to clean-cache with the latest u-d-f and it keeps keeps saying unknown command. How do I clear the cache to get the latest builds? | 17:58 |
| ogra_ | look under ~/.cache | 18:00 |
| wililupy | orgra_ any specific directory? There are 2 .fr-* directories with data.tar.xz, is that it? | 18:02 |
| kyrofa | zyga, is there any documentation about using .desktop files in meta/gui ? | 18:05 |
| zyga | kyrofa: not that I know of | 18:05 |
| zyga | kyrofa: I can tell you how it works | 18:05 |
| zyga | kyrofa: and how to use it | 18:05 |
| kyrofa | zyga, please do :) | 18:05 |
| zyga | kyrofa: but I don't think it's written down anywhere | 18:05 |
| zyga | kyrofa: desktop files from meta/gui are parsed, sanitized and placed in /var/lib/snapd/desktop | 18:05 |
| zyga | kyrofa: ${SNAP} is expanded (exactly ${SNAP}, nothing else) to point to the snap install/mound directory | 18:06 |
| zyga | kyrofa: the icon needs to refer to ${SNAP}/something (e.g. ${SNAP}/meta/gui/icon.png) to work | 18:06 |
| zyga | kyrofa: that's all I remember | 18:06 |
| kyrofa | zyga, when you say "sanitized" I assume that means there are limitations to what I can put in there? | 18:07 |
| zyga | you can put anything, we just filter out some things | 18:07 |
| zyga | and "allow" only certain things that are safe | 18:07 |
| zyga | e.g. no TryExec | 18:07 |
| zyga | it's pretty crude but the idea is that untrusted .destkop files are okay | 18:07 |
| kyrofa | Alright, thanks :) | 18:08 |
| sergiusens | kyrofa desktop files, just drop them in `setup/gui/<app>.desktop` | 18:17 |
| kyrofa | sergiusens, yeah, I was just curious about the parsing/sanitization | 18:17 |
| kyrofa | zyga, does the home interface not automatically connect? | 18:32 |
| ogra_ | no | 18:32 |
| kyrofa | ogra_, is that a bug or is there a reason for that? | 18:33 |
| sergiusens | kyrofa on purpose | 18:33 |
| ogra_ | security ;) | 18:34 |
| kyrofa | Huh. I wish `snap install` would have told me :P | 18:35 |
| ogra_ | we can key-log all your Xorg keystrokes, but cant store them in your home dir ;) | 18:35 |
| zyga | kyrofa: no, it's super dangerous as you can steal almost all user data | 18:37 |
| kyrofa | zyga, and X isn't? | 18:37 |
| zyga | kyrofa: that's on a TODO list, we just basically had no way to do it lately | 18:37 |
| kyrofa | ogra_, yeah exactly, haha | 18:37 |
| ogra_ | shhh | 18:37 |
| zyga | kyrofa: X is bad but then most apps don't work without X | 18:38 |
| zyga | kyrofa: but most apps *can* work without your real HOME | 18:38 |
| kyrofa | zyga, nah, I understand. Just caught me by surprise | 18:38 |
| kyrofa | sergiusens, alright, first (relative) success: https://github.com/kyrofa/qt-example-snaps/tree/master/application | 18:44 |
| kyrofa | zyga, is there a way to access the webcam via interfaces? | 18:50 |
| zyga | kyrofa: no, not today | 18:59 |
| zyga | kyrofa: we need hooks to make that sane | 18:59 |
| kyrofa | zyga, alright | 19:00 |
| zyga | kyrofa: as those are typically dynamic objects | 19:00 |
| kyrofa | zyga, right yeah, all that hw-assign stuff is | 19:00 |
| zyga | kyrofa: having said that, I was working on the pi2 camera iface a while ago | 19:02 |
| zyga | kyrofa: the interface itself wasn't hart, what was the problem at the time was lack of proper firmware and shared libs in the base image | 19:02 |
| zyga | kyrofa: I'm sure the next few weeks will see a rapid evolution of interfaces | 19:02 |
| kyrofa | zyga, rapid evolution + SRU = ? :P | 19:03 |
| sergiusens | kyrofa does it look good? is it in the store already? :-) | 19:08 |
| kyrofa | sergiusens, no, should I put it in the store? And yeah, it's not bad | 19:09 |
| sergiusens | kyrofa is it all your code or some upstream project? | 19:09 |
| kyrofa | sergiusens, upstream | 19:09 |
| kyrofa | sergiusens, they're qt examples | 19:09 |
| sergiusens | ah | 19:10 |
| sergiusens | kyrofa maybe get a gtk example in next ;-) | 19:10 |
| kyrofa | sergiusens, alright I've got one more qt one, then gtk | 19:10 |
| sergiusens | kyrofa heh, will and seb might take on gtk | 19:13 |
| Domi | Hello, where do I get the images for raspberry pi 3? | 19:19 |
| kallisti5 | ... is not of type 'object' | 19:30 |
| kallisti5 | I don't get it.. I pretty much get that from snapcraft for everything | 19:30 |
| kyrofa | kallisti5, sounds like your YAML isn't right | 19:31 |
| kyrofa | kallisti5, want to put it in http://pastebin.ubuntu.com/ ? | 19:31 |
| kallisti5 | http://pastebin.ubuntu.com/16055433/ | 19:32 |
| kallisti5 | err.. ignore r1scsi there... that should read "thing" | 19:32 |
| josepht | kallisti5: it looks like you're missing 'command:" in your app | 19:34 |
| kallisti5 | heyyy | 19:35 |
| kallisti5 | that did it | 19:35 |
| kyrofa | kallisti5, yeah that was just invalid YAML | 19:37 |
| dragly | when running "snapcraft", is it possible to specify that a part with "plugin: copy" should rerun (i.e. clean and then copy the files again) | 19:39 |
| dragly | cloning and building the rest of the project takes some time | 19:39 |
| kyrofa | dragly, yes, you can give snapcraft specific parts | 19:42 |
| kyrofa | dragly, e.g. snapcraft stage part1 | 19:42 |
| kyrofa | dragly, you also don't need to clean completely | 19:42 |
| kyrofa | dragly, try cleaning only back to the build step: snapcraft clean -s build | 19:42 |
| kyrofa | dragly, or cleaning only part1 back to the build step: snapcraft clean part1 -s build | 19:43 |
| dragly | thanks! | 19:43 |
| dragly | is it possible to "chroot" into the snap to inspect the environment somehow? | 19:47 |
| dragly | kgunn: Thanks for showing me the example. I got a bit further now, but both with the example and my own package I get the following error: | 19:54 |
| dragly | libGL error: No matching fbConfigs or visuals found | 19:54 |
| kgunn | dragly: interesting, so if you build and sideload the example snap that occurs? | 19:54 |
| dragly | sorry, I don't know what sideload means | 19:55 |
| kgunn | dragly: sideload==you build it locally and did sudo snap install mylocallybuild.snap | 19:55 |
| kgunn | vs download/install from the snap store | 19:55 |
| dragly | yes | 19:55 |
| kgunn | oh ok, this is weird then | 19:55 |
| dragly | sudo snap install ubuntu-clock-app_3.6+snap2_amd64.snap; ubuntu-clock-app.clock | 19:55 |
| kgunn | i wouldn't have expected that | 19:56 |
| dragly | I have Nvidia drivers on my host system, if that matters | 19:56 |
| kgunn | dragly: it shouldn't...but possibly | 19:56 |
| kgunn | dragly: do you have a hybrid gpu system? | 19:56 |
| dragly | not on this machine, no | 19:57 |
| kgunn | like 2 gpus and drivers available at the same time ? | 19:57 |
| * kgunn thinks for a moment | 19:57 | |
| kgunn | dragly: on your machine do you have something like /usr/lib/nvidia-<xxx> | 19:59 |
| kgunn | containing the nvidia drivers? | 19:59 |
| dragly | here are some findings, if they help: /var/lib/snapd/lib/gl/ is empty on the host, /usr/lib/nvidia-361 exists on the host and has a libGL.so, but in the snap I only find libGL.so in ./usr/lib/x86.../mesa | 20:01 |
| dragly | looking at the older snaps I had for my own project, I see they copied nvidia-361 to ./usr/lib | 20:03 |
| kgunn | dragly: right, the idea implemeted was to permit the snap to leverage the libgl from the host system, rather than copy in... | 20:03 |
| dragly | this however stopped at some point (I realize now I should have used version control while working on this too) | 20:04 |
| kgunn | b/c otherwise you're stuck to that gpu/impl | 20:04 |
| dragly | that makes sense | 20:04 |
| kgunn | dragly: but like i say that was a very recent addition | 20:04 |
| kgunn | of a feature to ubuntu-core/snapd etc | 20:04 |
| dragly | I'm using snapcraft as installed with "sudo apt install" by the way | 20:04 |
| dragly | version 2.8.4 | 20:05 |
| kgunn | dragly: i think that's fine... | 20:05 |
| kgunn | dragly: this is more about not being able to find the drivers at run | 20:05 |
| kgunn | dragly: interesting...someone else seemed to have a very similar prob last week | 20:06 |
| kgunn | http://askubuntu.com/questions/759647/opengl-error-in-snaps-ubuntu-16-04/760096#760096 | 20:06 |
| kgunn | so i'm wondering if there's just a niggly nvidia symbolic link issue going on | 20:06 |
| kgunn | what else is /usr/lib/nvidia-361 have inside? | 20:07 |
| dragly | seems reasonable, considering other's findings like here: https://askubuntu.com/questions/541343/problems-with-libgl-fbconfigs-swrast-through-each-update | 20:07 |
| kgunn | dragly: :-/ bummer...but wonder if some sort of reinstall of those drivers might help? | 20:08 |
| kgunn | i don't have nvidia myself...i've asked someone in another channel, just to give it a go | 20:08 |
| dragly | http://pastebin.com/ABU2THVw | 20:08 |
| kgunn | i do know one of the snappy team guys tried the feature out building on intel/run on nvidia then vice/versa...and the feature worked... | 20:09 |
| dragly | I'll try reinstalling and doing a quick reboot | 20:10 |
| dragly | I can also try it on a machine with intel, just give me a couple of minutes | 20:11 |
| kgunn | dragly: hey, when did you start trying snapcraft and ubuntu-core on desktop? | 20:12 |
| kgunn | reason i ask, is at one point i ran into problems with an update... | 20:12 |
| kgunn | and i did have to reinstall...but if you've only started in the last week or so...may be a red herring | 20:13 |
| kgunn | but at one point i had to run a script like this | 20:13 |
| kgunn | https://pastebin.canonical.com/155170/ | 20:13 |
| kgunn | and then reinstall ubuntu-snappy-cli and ubuntu -core etc | 20:13 |
| kgunn | fwiw | 20:13 |
| dragly | I started yesterday | 20:15 |
| dragly | cannot access the pastebin | 20:16 |
| dragly | but I can try reinstalling those | 20:16 |
| dragly | moving the clock .snap to a laptop with intel produces the following error: | 20:29 |
| kgunn | dragly: sorry bout that | 20:29 |
| kgunn | http://pastebin.com/68FTk1gv | 20:29 |
| dragly | QXcbConnection: Could not connect to display :0 | 20:30 |
| dragly | building and running on Intel laptop works | 20:32 |
| dragly | That is, it has Nvidia Prime, but I've disabled Nvidia and running only on Intel now. | 20:32 |
| dragly | I'll try moving it to the other machine. | 20:32 |
| dragly | same error, I'll try the script you sent now | 20:33 |
| kgunn | dragly: sorry, confused...so you did have success running on intel? | 20:34 |
| dragly | yes, building and running the clock example on intel works | 20:34 |
| dragly | building on intel, running on nvidia doesn't work | 20:34 |
| dragly | building on nvidia, running on either doesn't work | 20:34 |
| wililupy | I have a custom kernel snap and I build my image using u-d-f, and when I install it to my device and try to boot up, I get the following error: http://pastebin.ubuntu.com/16056244/ and it goes back to the grub menu. | 20:35 |
| wililupy | system will boot when using the stock snappy image, but I need custom modules so I build my kernel snap and it builds successfully, everything looks good in the .snap file, but I can't boot the device. Any pointers? | 20:36 |
| dragly | kgunn: After running the script and reinstalling snapd and snapcraft (should I have reinstalled others?), installing the package built on intel and running it on nvidia gives the QXcbConnection error (not seen on that machine before) | 20:40 |
| dragly | and, the same happens if I run the script once again and build the whole example from scratch. So still having some issues, but the error message changed. | 20:41 |
| pedronis | dragly: does the snap asks for unity7 and x11 plugs? | 20:41 |
| kgunn | pedronis: he's using the clock example i think | 20:42 |
| dragly | yes, it's the clock example. "plugs: [unity7,opengl]" | 20:42 |
| dragly | really strange, reinstalling the snap on the nvidia system (no rebuild) gives the previous "libGL error: No matching fbConfigs or visuals found" | 20:43 |
| dragly | I don't see how the reinstall changes anything | 20:43 |
| pedronis | mmh, this sounds more like the issue of security not being regenerated on updates | 20:43 |
| dragly | I'll diff the folders... | 20:43 |
| pedronis | (we are working on it) | 20:43 |
| kgunn | dragly: confirmed with another guy who has nvidia...he's seeing your libgl err | 20:44 |
| dragly | kgunn: ok, thanks | 20:44 |
| kgunn | so i think this might be a bug, we'll need to work with mvo on it tomorrow | 20:44 |
| pedronis | yes, that one seems a genuine different problem | 20:45 |
| pedronis | (the cannot access display more the security not setup on update one instead) | 20:45 |
| dragly | kgunn: Great. Let me know if I can help. I really like this project and would love to see it succeed. | 20:46 |
| sergiusens | kyrofa elopio telegram seems busted here, I get notifications but can't see messages | 20:46 |
| dragly | pedronis: Ok, thanks for letting me know. I'll keep that in mind when I see the error next time. | 20:47 |
| dragly | Is there a way to specify where snapcraft outputs the folders like "parts", "stage" and so on? | 20:58 |
| wililupy | I feel like I'm missing a module from my kernel config for loop in my snapcraft.yaml for the kernel_initrd_modules... | 20:58 |
| ogra_ | wililupy, heh, no, that wouldnt help you with grub :) | 21:03 |
| ogra_ | wililupy, you want loop support builtin | 21:03 |
| ogra_ | if grub fails with a "cant find loop" error you are far before the initrd in your boot process | 21:04 |
| wililupy | ogra_ the funny thing is that I created an image using u-d-f with all the defaults, and it works, but when I change the --kernel=my-kernel.snap, it doesn't boot up. | 21:09 |
| ogra_ | did you use snapcraft to create the kernel snap ?? | 21:10 |
| wililupy | ogra_ yes. | 21:10 |
| ogra_ | well, then the snap structure should be ok i guess | 21:10 |
| wililupy | ogra_ I verified it by unsquashfs and everything looks good. | 21:11 |
| zerwas | On Ubuntu 16.04 Desktop (upgraded from 15.10), the snap command does not work for me. It immediately exits with: "error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps?q=test&sources=store: dial unix /run/snapd.socket: connect: no such file or directory". What might cause this? | 22:20 |
| zerwas | I just realized it might have to do with me still using upstart instead of systemd. | 22:23 |
| ogra_ | uuuh | 22:27 |
| === zyga_ is now known as zyga | ||
| Domi | Hello, i get the error "Unable to locate package snappy-tools" what is wrong? | 22:43 |
| zerwas | Domi: Do you need a package called snappy-tools? | 22:45 |
| Domi | yes I want to create a .snap with snapcraft | 22:46 |
| Domi | In the documentaion is written that I just have to "sudo apt install snappy-tools" | 22:48 |
| Domi | https://developer.ubuntu.com/en/snappy/build-apps/get-started/ | 22:51 |
| oparoz | Domi, what happens if you jhust try to apt install snapcraft? | 22:51 |
| Domi | i think i need the other tools too. Do you use Snappy ? | 22:52 |
| oparoz | Domi, yes, I use Snapcraft | 22:53 |
| Domi | how did you install it? | 22:53 |
| oparoz | The link you gave me has either just been updated or is telling me to install snapcraft | 22:53 |
| oparoz | The old documentation required snappy-tools | 22:53 |
| oparoz | Domi: I followed this guide: https://github.com/owncloud/ubuntu-snap/wiki/Building-your-first-snap | 22:55 |
| oparoz | But that's to build snaps from within Snappy | 22:56 |
| Domi | did you install snapcraft on ubuntu core or on a deskop version of ubuntu? | 22:59 |
| oparoz | Domi on core | 22:59 |
| Domi | oh ok. I thought it would be possible to pack the snap on my normal deskop machine and then upload it to core | 23:01 |
| Domi | because it says "Once your Ubuntu host system is up and running, you can then install the snappy-tools package, which will in turn install the optimal selection of Snappy development software to your system." | 23:02 |
| oparoz | Domi, yes, it should be possible, but I haven't tried yet and if I'm not mistaken, core is a bit behind and unstable, so you may run into some surprises | 23:02 |
| Domi | ok I just want so python core running and use the GPIOs of the raspberry pi. | 23:03 |
| oparoz | whereas if you develop in a VM using core, you should be able to test things right away | 23:03 |
| oparoz | I use an amd64 vm for bigger stuff and develop straight on the Pi for lighter stuff | 23:04 |
| oparoz | It works pretty well, thanks to the launchpad builders | 23:04 |
| Domi | launchpad builders? | 23:07 |
| oparoz | If you push your git code to launchpad, you can ask LP to build snaps for various architectures | 23:07 |
| Domi | ok, but it is not possible to use any IDE on core or? | 23:08 |
| oparoz | What I do is push files from my workstation to the core VM, so I can use any desktop IDE I want | 23:09 |
| oparoz | It's probably possible to launch an IDE from core, if you can find one | 23:10 |
| Domi | so you write your code on the workstation and than move it to core. On core you make a .snap and than you install the .snap | 23:11 |
| oparoz | That reminds me that I'm able to use snapcraft on core because I still have classic mode, but that's been removed... | 23:12 |
| oparoz | There is one piece of the puzzle I'm missing. If I wanted to build from the desktop, how do I make sure I target core and not the desktop... | 23:14 |
| oparoz | Because if the latest images of snappy don't have classic mode, I don't know how you're going to build a snap | 23:15 |
| Domi | ok without classic mode there is no way to build the snap on core. Should I ask tomorrow someone on how to install snapcraft on desktop? | 23:17 |
| oparoz | Installing Snapcraft is not the problem | 23:18 |
| oparoz | just apt install | 23:18 |
| oparoz | but the documentation goes from install snapcraft to "your first snap" | 23:19 |
| Domi | no the documentation says install snappy-tools which is not available in apt | 23:20 |
| oparoz | No, that's the old documentation | 23:20 |
| oparoz | https://developer.ubuntu.com/en/snappy/build-apps/get-started/ | 23:20 |
| oparoz | $ sudo apt install snapcraft | 23:20 |
| oparoz | That's the doc for 16.04 | 23:20 |
| Domi | ok thank you, i read https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md which is for 16.04 too. very confusing | 23:22 |
| Domi | I will follow this guide tomorrow. Thank you for your greate help | 23:25 |
| oparoz | You're welcome | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!