[01:30] is Ubuntu core already released for the Dragonboard _ [01:30] ? === chihchun_afk is now known as chihchun [06:55] good morning [06:58] good morning. [06:59] is there any plan to have classic dimension back? ;) [06:59] should I expect snapcraft working in a chroot environment? [07:01] shuduo: I'm sure classic will work though I'm not quite sure when [07:01] shuduo: snapcraft and chroot, hmm, I heard that people had issues with kpartx [07:01] shuduo: you might be able to snapcraft in a chroot but only construct the squashfs manually or on the outside [07:03] 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] " when i build examples [07:04] shuduo: maybe try snapcraft from source, I don't know [07:05] zyga: yes, i just pulled it from github and build/install it in chroot. [07:05] shuduo: you can also use launchpad to build snaps AFAIR but I haven't used this much [07:06] zyga: sorry never heard of that. how? [07:07] I don't really know but from what I remember it's like a PPA [07:07] just builds snaps [07:11] zyga: i looked at lp. seems only target amd64 and i386. [07:11] ah, too bad [07:48] 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] always get the following error when running the app: [07:49] /bin/sh: 0: Can't open /snap/neuronify/100006/command-neuronify.wrapper [07:49] It goes away if I rename the snap and build/install again. Have anyone here seen this before? [07:49] dragly: yes, this is already (almost) fixed [07:50] dragly: though I don't know if my fix will land or if it will need larger changes [07:50] dragly: as a workaround, uninstall and install your snap each time [07:50] Oh, okay. I can live with that workaround while developing. Thanks! [08:00] That works. Now I just need to figure out how to get access to xkb working. [08:01] Do you know if I might be missing some "plugs" when I get this error? [08:01] xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb [08:01] I already have "plugs: [unity7,opengl,x11,system-observe]" [08:19] dragly: you can consult generated apparmor profile but I suspect that nothing grants x11/xkb access [08:19] dragly: please open a bug with the details of your snap, I will be working on interfaces a lot this week, [08:47] zyga: ok, du you prefer bugs on launchpad or github? [08:48] dragly: I think we want launchpad [08:49] What's wrong with this? [08:49] 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:57] Okay, ignoring a wrapper problem. [08:57] $ /snap/bin/xeyes [08:57] Bad system call [09:00] qengho: try with --devmode [09:00] qengho: (remove the snap and install it with --devmode) [09:01] qengho: then observe syslog [09:01] qengho: also check if the x11 plug is connected [09:01] qengho: I had a few people report intersting bugs lately [09:05] zyga: https://pastebin.canonical.com/155116/ [09:06] qengho: interesting, so you use encrypted home [09:06] qengho: you have to add the home plug and connect this [09:06] qengho: I'm not sure that it will suffice though [09:07] qengho: but please report a bug that snappy won't work at all with encrypted home directory [09:12] zyga: https://bugs.launchpad.net/snappy/+bug/1574526 [09:12] Launchpad bug 1574526 in Snappy "snappy doesn't work with encrypted home directory" [Undecided,New] [09:12] qengho: thank you === JamesTait is now known as Guest99393 [09:17] qengho: can you snap install links [09:18] qengho: and run links successfully? [09:20] qengho, I get the same dmesg, but the snap works fine [09:20] 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:21] zyga: "links" snap works. [09:22] qengho, thanks [09:22] so it's not encrypted home per se [09:22] qengho: is your snap trying to access regular home directory? [09:23] qengho, if you try uninstalling the snap and reinstalling it, do you get the bad system call again? [09:24] * zyga wonders if the encrypted-home option is available in the installer anywhere [09:24] zyga, you mean ubiquity? [09:24] zyga, it is [09:24] ara: yes, I'm looking but all i see is encrypted / [09:24] zyga, wait until it asks for your username [09:24] ara: ah, thanks [09:24] zyga, it will have a radio button to encrypt your home [09:25] qengho, was xeyes the first snap that you installed on your system? [09:26] ara: not the first. [09:27] $ sudo snap install ./xeyes_1_amd64.snap [09:27] [-] Make snap "xeyes" available to the system [09:27] $ /snap/bin/xeyes [09:27] Bad system call [09:27] cmiller@vetinari:/tmp$ sudo snap connect xeyes:x11 ubuntu-core:x11 [09:27] [|] Connect xeyes:x11 to ubuntu-core:x11 [09:27] cmiller@vetinari:/tmp$ /snap/bin/xeyes [09:27] Bad system call [09:29] qengho: and with devmode you get those messages about ~/.Private? [09:29] qengho: currently we don't get notices about seccomp denials in --devmode [09:30] zyga, the .ecryptfs messages are always shown [09:30] zyga, even without --devmode === vrruiz_ is now known as rvr [09:30] zyga, and even if the app works fine (like links) [09:30] zyga, for me, if I launch links successfully, I still get those messages [09:31] odd [09:31] thanks! [09:31] Yes, "links" also causes four ecryptfs DENIED rw [09:31] But no crash [09:32] qengho: apparmor gives EPERM but seccomp gives you sigkill [09:34] zyga, I thought that was going to change [09:34] ara: I don't think it did yet [09:34] Okay, so it's not dependent on ecryptfs. [09:34] ara: because seccomp needs kernel work [09:34] Is it? === Guest99393 is now known as JamesTait [09:35] Okay, so this bug is not dependent on ecryptfs? [09:35] qengho: it seems it's not [09:35] zyga: Your xeyes runs, then? [09:36] qengho: I'm still setting up an env [09:36] qengho: I'll try on my host [09:42] qengho: xeyes doesn't run [09:44] 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:45] that is getsockname [09:45] * zyga looks at snappy source [09:46] qengho: it doesn't work because x11 doesn't include that profile [09:46] qengho: unity7 will work [09:48] qengho: I just confirmed that it works with unity7 plug [09:48] qengho: I've updated the bug [09:49] with everything is a file/everything is over a socket, I find snappy interfaces related to networking rather limited [09:49] zyga: With devmode, it runs with no crash. Same dmesg output. [09:50] apparmor will need more work [09:50] qengho: change to "plugs: [unity7]" [09:50] qengho: then it works for me [09:51] * qengho boggles. [09:51] qengho: I've updated the bug [09:51] *Should* it have unity7 as plug? [09:51] qengho: no [09:51] qengho: it's just a bug [09:54] Okay, so I'm trying to figure out how to report it. "snappy's x11 plug doesn't work for 'getsockname' syscall"? [09:54] qengho: I renamed the existing bug [09:54] qengho: have a look [09:55] zyga: ah, perfect. Thank you. [09:58] 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] qengho: it's a bug [09:58] qengho: that message says "getsockname is denied" [09:58] qengho: it's a bug in snappy [09:59] qengho: the message is obviously cryptic :/ [10:08] I was just worried about *silence*. [10:08] Cryptic is fine. I've used linux since 1995. Cryptic, I got. [10:10] I reported https://bugs.launchpad.net/snappy/+bug/1574556 [10:10] Launchpad bug 1574556 in Snappy "apparmor denials reported for encryped HOME" [Undecided,New] [10:22] qengho: FYI: https://github.com/ubuntu-core/snappy/pull/1069 [10:22] jdstrand: https://github.com/ubuntu-core/snappy/pull/1069 [10:29] 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] sorry, not *ask, I meant help [10:30] I'm just wondering what the way is to recover from those errors they see on the output of `snap changes` [10:34] dpm: snap changes errors are harmless [10:34] dpm: they are just a trace that something went wrong [10:35] dpm: it seems that people still install using "$snap.$origin" (instead of just $snap) [10:36] dpm: the error with revision 2 there seems interesting though [10:36] zyga, thanks. Not sure, in that case, they're saying the install command was `sudo snap install ubuntu-clock-app` [10:36] dpm: yes, that was the command that was tried next [10:37] ah, I see what you mean now [10:38] zyga, any ideas on what to recommend? [10:38] dpm: I'm responding on askubuntu now [10:38] awesome, thanks! [10:47] zyga: what's the answer? How does he recover? I tried 'strace'ing once to find out. [10:47] I think the strace didn't pass through launcher. I think. [10:47] qengho: I don't know what his problem is yet [10:48] qengho: I asked for additional information: http://askubuntu.com/a/762340/532607 [10:48] qengho: at the end of the day it should be possible to wipe snappy state entirely [10:52] 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:55] plars: odd, I just tested this (including booting) on 0a58844b8b48b2c5d08154b44edd182287e6c589 [10:55] plars: seems like a bug in udf [10:58] zyga: is that the sha1 of your udf? That's not what I have [10:58] fails here too [10:58] * popey replied with pastebin to the list [10:59] popey: do you get the oops also? [11:00] yes [11:00] http://paste.ubuntu.com/16046785/ is my dmesg [11:01] gah, that mount process is unkillable [11:04] sounds more like a kpartx bug [11:07] plars: no, that's the head of devtools I'm on [11:07] ouch [ 588.493709] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [11:07] kernel bugz [11:10] 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:14] ogra_: snappy images? :) [11:16] zyga, sure [11:17] ogra_: where are those published? [11:17] nowhere atm ... you'd have to grab the snaps yourself [11:17] http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ [11:20] (and i'm nt sure what we should do with these snaps ... we dont have a 16.10 channel in the store) [11:28] 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] zyga, known bug? or something missing? [11:34] ara: known bug [11:34] ara: (we knew about this before releae) [11:35] zyga, but something that it is going to be addressed at some point? shall I file a bug as reminder? [11:36] ara: yes, certainly, we have a card for this, there's a bug as well somewhere AFAIR [11:36] zyga, can you point me to the card, please? [11:37] ara: https://trello.com/c/l1EpwBoT/98-re-enable-auto-refreshing-autopilot [11:37] ara: here you go :) [11:37] zyga, fantastic, thanks [11:53] * zyga refreshed the fix for bug https://github.com/ubuntu-core/snappy/pull/1049 === zyga_ is now known as zyga [12:09] Good morning === zyga_ is now known as zyga [12:12] mcphail, not sure if you got your question answered, but the ownCloud snap isn't compatible with the desktop just yet [12:13] I hasn't been released for Snappy 16-- it's still using rolling [12:19] niemeyer, zyga, so what are next steps for https://github.com/ubuntu-core/snappy/pull/1037 ? [12:21] morning [12:24] JamesTait, beuno, in the store, what's the difference between 'Make private' and 'Unpublish' for a snap? [12:24] 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] zyga ^ [12:25] dpm, "Make private" puts the package behind an ACL, whereas "Unpublish" removes it from the store. [12:26] 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:30] ssweeny: AFK, I'll reply in ~1 hour [12:30] zyga, ack [12:34] JamesTait, thanks. Actually, my next question was going to be... what's an ACL? :) [12:34] dpm, Access Control List. 😉 [12:34] oh, ok [12:35] thanks [12:35] 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:36] JamesTait, ok [12:51] kyrofa: thanks! [12:55] nice one, thanks for the askubuntu answer on snap refresh ara! [12:56] dpm, private snaps are only available to ~canonical, I think [12:56] (atm) [12:58] sergiusens: Thanks! I'll try that out. === devil is now known as Guest27374 [12:59] sergiusens, kyrofa: when do we want to do the clinic? [12:59] dholbach, I thought it was tomorrow? [12:59] did we say tomorrw at 15 UTC (the community Q&A slot)? [13:00] just wanted to double-check, so I can announce it now :) === Guest27374 is now known as devil_ [13:12] Hello, were do I get the builds for raspberry pi 3? [13:14] dholbach, yeah we didn't set a time, but I think 15 UTC works fine [13:14] kyrofa, perfect [13:14] sergiusens, ^ does that work for you too? [13:17] 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] anytime is good tomorrow fwiw [13:17] I don't mind pushing [13:17] That's a good point actually [13:18] the week after is UOS [13:18] that's a good time for demos and stuff anyway [13:18] dholbach, snappy 16 is not on ubuntu core yet-- weird situation [13:18] kyrofa, I'm not sure I understand [13:19] ssweeny: I'll catch up with the conversation on that pull request now [13:19] dholbach, unless things have changed since I used edge, snappy on the desktop and snappy on ubuntu core are different [13:19] zyga, great, much appreciated :) [13:20] sergiusens, ^ what do you think? [13:20] do you think the week after things should be better? [13:20] kyrofa we only care about snaps on the desktop/server though (for now) [13:21] sergiusens, ah, okay good to know [13:21] dholbach I am +1, let's see what olli| thinks [13:22] sergiusens, what "state" were you referring to, then, regarding pushing? [13:22] * olli| scrolls [13:22] kyrofa producing a full fledged desktop snap [13:22] not enough interfaces ready yet [13:23] or known issues made known :-) [13:23] sergiusens, ah, true. None of your attempts worked out either, huh? [13:24] kyrofa not really; I will know more this after the group meeting [13:24] well, it could be a developer desktop ;) installed with --devmode [13:24] ogra_, hahaha [13:24] kyrofa but the fact that most apps use network manager to get info about connectivity status brings down a lot of options [13:25] ogra_ hah [13:48] 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] zyga, ok fair enough [14:00] ssweeny: quick question, how do you test this? [14:01] 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:03] zyga, I use this snap btw https://code.launchpad.net/~ssweeny/+snap/bluez [14:03] ssweeny: and the VM, I assume it doesn't have bluetooth, or does it? [14:04] zyga, it doesn't, so I only test that bluetoothctl can connect to the daemon [14:04] ok [14:04] ah, right [14:04] that's all I need, thanks! [14:04] yw [14:08] dpm, hey, is the store supposed to list things calculator? is it amd64 only or supposed to work on i386 as well? [14:09] is there a snap status command or equivalent? [14:11] seb128: its an amd64 only build I believe [14:11] k, that explains -:/ [14:11] :-/ [14:11] popey, thanks [14:11] despite it being qml only, it's got lots of binaries lobbed in to make it work [14:12] seb128, the x86 build does not work for some reason [14:12] I see you guys look down on us i386 users :p [14:12] seb128, you mean *user? :P [14:13] :-) [14:13] :) [14:13] k, next question [14:13] $ sudo snap install hello-world [14:13] error: can't install "hello-world": snap "ubuntu-core" has changes in progress [14:13] how do I figure out what's going on? [14:13] seb128, I actually did an x86 build, but gets a "Bad system call" message when executed on an x86 machine [14:13] there is no status command? [14:13] seb128, `snap changes` perhaps [14:13] and then `snap changes $CHANGEID` to zoom in [14:14] thanks [14:15] 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] seb128: when I had the "changes in progress" issue, the only resolution I had was to nuke my snappy config (and apps) from orbit :( === jgrimm-afk is now known as jgrimm [14:16] popey, where do those live? [14:16] so i had to stop the snapd service, umount /snap/*/* and rm all of /var/lib/snapd/* iirc [14:16] then reinstall snapd and snap install ubuntu-core [14:16] seb128: reset-state from here should do it. https://github.com/zyga/devtools [14:16] it "fixed" it for me [14:17] ooh, we even scripted it! [14:17] josepht, popey, thanks [14:17] seb128: my pleasure [14:26] sergiusens, let's chat in the team mtg === willcooke is now known as wllck [14:44] ssweeny: hey, this is a totally crude attempt at this [14:44] ssweeny: I'll build the snap next but I wanted to show you https://github.com/zyga/snappy/commits/bluez-fix-rules [14:47] ssweeny: one thing I could do is to look at all the apps in the slot [14:47] ssweeny: and let the sender (with the plug) talk to each of those apps specifically [14:47] ssweeny: I'm not sure we want that though [14:47] jdstrand: hey, are you around? [14:54] 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:55] dragly: AFAIR we set something, let me check [14:55] the launcher does that automatically for a bunch of dirs ... [14:55] dragly: what do you need specifically? [14:55] (just make sure your libs are in the right location inside the snap) [14:56] 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] 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:57] dragly: opengl stuff is handled separately [14:57] one sec [14:57] well, just make sure to always keep the existing LD_LIBRABRY_PATH if you actually append anything to it [14:57] dragly: we set SNAP_LIBRARY_PATH [14:58] to /var/lib/snapd/lib/gl: [14:58] looking what picks that up [14:58] the launcher is not [14:58] I guess you want your wrapper [14:59] 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] seems like setting LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SNAP_LIBRARY_PATH didn't help [15:00] I must have messed up something else [15:01] is there a way to set env variables in the yaml? [15:01] nope [15:02] is launching the app like this in my wrapper the right way to do it? [15:02] $SNAP/bin/neuronify [15:03] yep [15:03] that will work [15:06] * zyga finished meeting and returns to bluez interface and snap [15:09] sergiusens: are you able to build snaps with snapcraft on rpi2 and successfully upload to the store? [15:09] cjwatson: let me try. thanks! [15:10] josepht what are you seeing? my rpi2 has been in the closet for a while; kyrofa has been playing with one though [15:11] 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] sergiusens: the snap fails to upload due to a checksum mismatch. I have registered the name. [15:12] dragly $SNAP/bin is in PATH so just `command: neuronify` should be enough [15:12] 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:13] 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] sergiusens: Adding the QT_XKB_CONFIG_ROOT helped me get a step further, though. [15:14] 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:15] Are there any OpenGL packages I should consider adding to stage-packages? [15:15] dragly: I don't think you should [15:16] dragly that I don't know, not a GUI person myself; I will fwd you to kgunn for the GLX question [15:17] 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:18] kyrofa smart ;-) [15:18] 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:19] josepht, fails to upload, or fails review? [15:19] kyrofa: fails review [15:22] 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:23] 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:24] I have made a custom plugin that copies all QML modules and Qt libs to the install folder. [15:25] dragly: hmm...are you digging into our example here as a guide/for instance? [15:25] http://bazaar.launchpad.net/~snappers/snappy-desktop-examples/trunk/files/head:/ubuntu-clock-app/ [15:25] 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] you can see the clock.wrapper has all the env set [15:26] dragly: so, accessing gl drivers provided by the host system in ubuntu-core is a very new feature... [15:26] nice, I'll have a look at it and see if I can add anything I'm missing. Thanks! [15:26] 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] dragly: yep, try to look at the example first... [15:27] if you think you've got it...and still hitting it, then file a bug on ubuntu-core with your work [15:27] thanks for being an early adopter [15:29] tyhicks: hey, have you seen jamie today? [15:30] zyga, I believe he's out today [15:30] ah [15:30] thanks [15:31] zyga: hey - he'll be back tomorrow [15:31] tyhicks: do you have time for a quick apparmor question? [15:31] zyga: sure [15:32] tyhicks: is it safe/okay to use #include statements inside a particular profile? [15:32] tyhicks: normally we include bits earlier [15:32] tyhicks: but one interface we're working on now does that per plug connection [15:32] zyga: are you asking if the #include has to happen at the top of the profile? [15:33] yep [15:33] zyga: #include's can go anywhere [15:33] ah, thanks! [15:33] no problem [15:34] 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:38] kyrofa: how do I use the LP builders to build my snap? [15:39] josepht, it's actually pretty easy. First of all, you need to have an LP project, and push your code there [15:39] josepht, are you hosting your code there already, or elsewhere? [15:39] kyrofa: nowhere yet :) [15:39] josepht, ah! [15:40] kyrofa: I'll setup a project and push my code there [15:40] 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:43] kyrofa josepht should even work from +junk [15:45] sergiusens, kyrofa: the builder uses 'architectures' from snapcraft.yaml? [15:46] josepht: not yet [15:46] okay [15:46] kyrofa: I've got my project pushed [15:46] josepht: https://bugs.launchpad.net/snapcraft/+bug/1533713 [15:46] Launchpad bug 1533713 in Snapcraft "Add metadata describing the architectures that a snap can be built for" [Wishlist,Triaged] [15:47] josepht, click on the branch you pushed [15:47] josepht: (i.e. currently that field does not appear to have the semantics we need) [15:47] josepht, and one of the options should be to "Creat a snap package" [15:47] with an e in there somewhere [15:48] kyrofa: check [15:48] kyrofa: as sergiusens says, you really don't need a full project, and a full project is likely inappropriate in most cases [15:48] cjwatson, sergiusens alright thanks :) [15:48] 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:49] 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] josepht, so you have a snap, but I believe by default it'll only build for x86 and amd64 [15:49] josepht, so select the snap package, and go to "Edit snap package" [15:49] josepht, select the archs you want [15:50] sergiusens: can't say I really care about the exact name :) [15:50] cjwatson ok; I was planning on fixing it last week but chasing the snapd story consumed most of our time [15:50] josepht, then you should be able to hit "Request builds" on the snap package [15:51] 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] sergiusens: but it would at least make it possible :) [15:52] 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] kyrofa: ack. My branch will need to have the source in it as well. i.e. it can't pull from github.com? === chihchun is now known as chihchun_afk [15:53] What's the easiest way to add a path to the Snap's LD_LIBRARY_PATH from Snapcraft? [15:53] 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] oparoz, write a wrapper [15:54] pwd [15:54] :) [15:54] kyrofa: unique to the user [15:54] 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:55] kyrofa, so wondering if that path could be "built" while creating the snap [15:55] kyrofa: usual naming constraints for names of things on LP, basically alphanumeric plus [+.-], with the first character alphanumeric only [15:56] josepht: git-to-git imports are on the near-term plan; in the meantime, just mirror stuff to LP manually [15:56] cjwatson, can multiple branches be associated with the same snap? [15:56] cjwatson: ack, thanks [15:56]