| liuxg | I have compiled a .snap file for the java sample app at https://github.com/ubuntu-core/snapcraft/tree/master/examples/java-hello-world, and I have deployed onto my KVM. what is the correct command to run the java? I did "java-hello-world.wrapper", but I got error like "java-hello-world.wrapper" command is not found error. | 01:10 |
|---|---|---|
| liuxg | I have compiled a .snap file for the java sample app at https://github.com/ubuntu-core/snapcraft/tree/master/examples/java-hello-world, and I have deployed onto my KVM. what is the correct command to run the java? I did "java-hello-world.wrapper", but I got error like "java-hello-world.wrapper" command is not found error. | 01:38 |
| woodrowshen | hi, i have a problem about snapcraft, may someone give a hand ? | 06:51 |
| dholbach | good morning | 07:53 |
| zyga | good morning :) | 08:02 |
| fgimenez | good morning zyga and all | 08:04 |
| longsleep | Good morning snappy | 09:27 |
| longsleep | Now with snapcraft and snappy on GitHub, do you guys accept and review pull requests there or is that still to be done through launchpad/bzr ? | 09:28 |
| * longsleep hopes to get rid of git-bzr eventually | 09:28 | |
| mvo | longsleep: we prefer github now | 09:43 |
| mvo | longsleep: we will stop the bzr repos at some point (once the migration is fully done) | 09:44 |
| longsleep | mvo: yay i like this! | 09:52 |
| === davidcalle_ is now known as davidcalle | ||
| dholbach | niemeyer, do you know when the snapcraft daily builds will be set up to build from github? | 09:58 |
| dholbach | can we also set https://launchpad.net/snapcraft up so that bugs are not accepted any more? | 09:59 |
| woodrowshen | hi, can I ask snapcraft related problems here ? @@a | 10:04 |
| ogra_ | woodrowshen, indeed | 10:05 |
| ogra_ | (not all people that can answer might be awake yet though, so be patient) | 10:05 |
| woodrowshen | ogra_: thanks. :) | 10:06 |
| woodrowshen | woodrowshen: i just clear one thing about snapcraft, can the snapcraft build a armhf snap ? | 10:07 |
| woodrowshen | i just clear one thing about snapcraft, can the snapcraft build a armhf snap ? | 10:07 |
| ogra_ | yes, but it needs an armhf environment | 10:07 |
| ogra_ | (i.e. a native armhf install on a board, or an armhf container or a vm) | 10:08 |
| ogra_ | there is no cross building yet | 10:08 |
| woodrowshen | ogra_: ok, that's point i'm stuck... | 10:09 |
| ogra_ | what do you want to do ? | 10:09 |
| woodrowshen | use snapcraft to build grafana snap for armhf | 10:10 |
| ogra_ | well, there are several ways to do that | 10:10 |
| ogra_ | create an armhf chroot on your PC is most likely the easiest but wont work aith all compilers (go and .net/mono definitely have issues) | 10:11 |
| ogra_ | *with | 10:11 |
| ogra_ | assuming you have an arm board for testing your snap, using a chroot on the arm board would then be my second choice | 10:12 |
| ogra_ | and third you can indeed run a full arm VM in which you build, though thats the slowest option | 10:13 |
| woodrowshen | thanks your suggestion. Fortunately, we have a native arm env on cloud, scaleway :) | 10:16 |
| woodrowshen | for originally, i just wrote makefile to use cross-toolchain to build it under snapcraft, and gave a armhf in the field of architecture in the snapcraft.yaml | 10:17 |
| woodrowshen | but i found the output snap filename and package.yaml was still amd64 string. XD | 10:18 |
| longsleep | woodrowshen: See https://github.com/ubuntu-core/snapcraft/pull/53 - it has instructions in the description how to set the output arch for snapcraft by using environment variables. | 10:19 |
| woodrowshen | longsleep: cool! so i don't need a arm platform, right ? | 10:21 |
| longsleep | mvo: Is travis supposed to work for snapcraft? https://travis-ci.org/ubuntu-core/snapcraft/builds/88307476 does not seem to be related to whatever i changed | 10:21 |
| longsleep | woodrowshen: Not for packaging previously built stuff with snapcraft or for non binary stuff. | 10:21 |
| longsleep | mvo: found the travis pr, so ignore the question :) | 10:24 |
| mvo | longsleep: one issue with the integration tests, otherwise its looking good in the PR | 10:26 |
| svij | I've just tried out snapcraft the first time and found a bug. Should I open a bug report or directly fix it in a PR? | 10:34 |
| pindonga | so, I managed to successfully build both and amd64 and an armhf snap of flexget, now I'd like to create a snap that works in both architectures... what's the best way to do that right now? | 10:44 |
| longsleep | pindonga: last time i asked that it was not easily possible - you can do it manually by some wrapper scripting similar to what webdm is doing. | 10:46 |
| pindonga | so, basically manually combine the contents of both snaps and add a wrapper that runs the arch specific binary ? | 10:47 |
| longsleep | pindonga: thats how webdm is doing it yes | 10:48 |
| pindonga | ack, thx | 10:48 |
| woodrowshen | longsleep: thank you, i think i still needs arm machine because i used plugin: make to build the grafana and there's no deb for armhf. | 10:50 |
| longsleep | woodrowshen: yeah if you need to compile or use any other plugin than copy (or debs) then you need armhf environment | 10:51 |
| woodrowshen | longsleep: anyway, i got lots of useful information, thanks your great help | 10:53 |
| ogra_ | ls | 12:15 |
| ogra_ | bah ! | 12:15 |
| ogra_ | ogra@anubis:~/Devel/branches/project-rootstock-ng$ time ./rootstock-touch -s xenial -a amd64 -t ubuntu-core -m http://localhost:9999/ubuntu | 12:23 |
| ogra_ | .... | 12:23 |
| ogra_ | real2m24.491s | 12:23 |
| ogra_ | user1m40.186s | 12:23 |
| ogra_ | sys0m44.196s | 12:23 |
| ogra_ | WHEE ! | 12:23 |
| sergiusens | pindonga, thanks | 12:24 |
| pindonga | sergiusens, thank you :) | 12:25 |
| * pindonga this > < close to finally submit a snap to the store for real | 12:25 | |
| === rickspencer3_ is now known as rickspencer3 | ||
| pindonga | just need to make the snap multi arch | 12:25 |
| sergiusens | tedg, did you find it | 12:45 |
| sergiusens | afaik, you don't need plugins bzr fast-export --plain . | git fast-import | 12:46 |
| zyga | sergiusens: hey, so snapcraft is no longer using bzr? | 12:46 |
| sergiusens | zyga, don't you read email ;-) | 12:47 |
| zyga | sergiusens: I have too much, I just hold hoping it will eventually stop ;) | 12:47 |
| zyga | sergiusens: (still catching up after holidays) | 12:47 |
| sergiusens | zyga, https://github.com/ubuntu-core/snapcraft | 12:47 |
| zyga | sergiusens: yeah, I see | 12:47 |
| zyga | sergiusens: so everything including issues is now on github? | 12:47 |
| sergiusens | zyga, yes | 12:47 |
| zyga | sergiusens: nice! | 12:48 |
| zyga | sergiusens: that's a very interesting move | 12:48 |
| sergiusens | zyga, I haven't killed the issues on lp yet as there are active conversations I don't want to destroy | 12:48 |
| zyga | sergiusens: right | 12:48 |
| zyga | sergiusens: oh, snappy is there too | 12:49 |
| zyga | mmm, cool | 12:49 |
| dholbach | sergiusens, tedg: do you know what we're going to do with daily builds and lp bugs of snapcraft after the move to github? | 12:55 |
| sergiusens | dholbach, I alreday moved the bugs to github issues | 12:55 |
| sergiusens | dholbach, daily builds I need to sync with mvo | 12:56 |
| dholbach | ok, cool | 12:56 |
| dholbach | or well "cool" :) | 12:57 |
| dholbach | sergiusens, can we close LP bugs for snapcraft completely? | 12:57 |
| sergiusens | dholbach, I'll be closing bugs today, but not the tracker as conversations are happening there right now | 12:57 |
| dholbach | ok, thanks | 12:58 |
| mvo | sergiusens: hi | 12:58 |
| sergiusens | mvo, hello hello | 12:59 |
| mvo | sergiusens: I can set them up for you, you will need a code import and update the daily build recipe | 12:59 |
| sergiusens | mvo, oh, and we need to talk about other things too | 12:59 |
| sergiusens | mvo, does it support gbp? | 12:59 |
| mvo | sergiusens: I think it does not matter as long as there is debian/* dir | 13:00 |
| sergiusens | oh, that works; but it needs to be bzr, right? | 13:00 |
| mvo | sergiusens: iiirc/afaik bzr-builddeb and the bzr daily builders are different tools | 13:00 |
| mvo | sergiusens: yes, thats why you need the code import | 13:00 |
| sergiusens | mvo, right, it could of been a straight git code import too ;-) | 13:01 |
| sergiusens | mvo, have we seen what stgraber is doing with lxd? | 13:01 |
| mvo | sergiusens: its easy we do it for snappy | 13:02 |
| tedg | sergiusens: I just pulled fast-import from LP in the plugins dir | 13:11 |
| tedg | Worked :-) | 13:12 |
| sergiusens | tedg, oh, by dir is possible too? nice | 13:19 |
| sergiusens | mvo, heh, but but I wanted to remove ./debian/ from master and put it in a debian branch ;-) | 13:19 |
| mvo | sergiusens: if you use full branches, that works as well, just make sure you import the right branch | 13:19 |
| sergiusens | mvo, it won't be useful for daily builds though as we would have to constantly sync 'master' with 'debian' | 13:20 |
| mvo | sergiusens: indeed | 13:25 |
| rickspencer3 | so, I am snapping frotz (for "interactive fiction") | 13:40 |
| rickspencer3 | frotz puts the save files next to the data files that it opened | 13:41 |
| rickspencer3 | so, for example, if I have ~/zork/ZORK1.DAT , it will make the save file ~/zork/game1.SAV | 13:41 |
| rickspencer3 | so, where should I put the data files in my snap so the save files work? i.e. in a readable/writable space? | 13:42 |
| tedg | Could you put a link to the data file in the writable directory and then run it with that as the path to the data? | 13:42 |
| rickspencer3 | can you tell me more about that strategy? | 13:42 |
| fancycode | finally got u-d-f to cross-build an armhf system image including built-in snaps on my amd64 machine :-) pull-request/proposed branch are ready for review | 13:42 |
| tedg | So do a ln -s $SNAP_APP_PATH/zork.DAT $SNAP_APP_USER_DATA_PATH/ | 13:43 |
| tedg | Then do a frotz $SNAP_APP_USER_DATA_PATH/zork.DAT | 13:43 |
| rickspencer3 | tedg, will frotz $SNAP_APP_USER_DATA_PATH/zork.DAT work in the binaries declaration of snapcraft? | 13:44 |
| tedg | rickspencer3: It would, but I think you'll need a shell script to do the link anyway. | 13:45 |
| tedg | So you'll probably want a wrapper that sets things up and does an exec | 13:45 |
| rickspencer3 | ok | 13:46 |
| * rickspencer3 tries | 13:46 | |
| mvo | jdstrand: hey, I noticed your security-cleanup branch, is there anything I can help with? | 13:47 |
| jdstrand | mvo: not just yet. everything seems to work but I need to add a bunch of tests | 13:47 |
| jdstrand | mvo: actually that isn't true, hw-assign needs work still | 13:48 |
| jdstrand | anyway, it is a really good start | 13:49 |
| mvo | jdstrand: I'm exciting if it means the hook is gone afterwards :) | 13:49 |
| mvo | jdstrand: uh, excited of course | 13:49 |
| jdstrand | mvo: you could answer me this: what is the *Remote* code expected to do? I've been ignoring it thus far | 13:50 |
| mvo | jdstrand: remote code? | 13:50 |
| jdstrand | mvo: oh yes, the hook will be gone, so will sc-filtergen (ie, no python), all the weird directories cleaned up (ie, just /var/lib/snappy/apparmor afterwords) and security-override is getting revamped to be: | 13:51 |
| jdstrand | binaries: | 13:51 |
| jdstrand | - foo | 13:51 |
| jdstrand | apparmor: | 13:51 |
| jdstrand | read-paths: /path/to/something | 13:51 |
| jdstrand | (instead of doing the weird json override) | 13:52 |
| mvo | jdstrand: can I use the branch for testing already? for the squashfs work, the hooks will no longer work because the click manifest can not be generated because at build time the origin is unknown. so having this would make my life a lot easier (even if tests are missing :) | 13:52 |
| jdstrand | mvo: yes, like, install remote and stuff | 13:52 |
| jdstrand | mvo: sure, that's fine. most of the code is changed in security.go. obviusly, I had to change the other parts to use the new internal api | 13:52 |
| mvo | jdstrand: nice, I have a look | 13:53 |
| jdstrand | mvo: I did rip out aaClickHook, etc where I found it, but I did not remove .click or the manifest | 13:53 |
| jdstrand | mvo: I figured I'd focus on the security bits and let others do the nail in the coffin for click compat | 13:53 |
| mvo | jdstrand: so "install remote", I'm probably a bit slow today, but I still don't know exactly what you mean | 13:53 |
| jdstrand | ok, let me get the function name | 13:54 |
| mvo | jdstrand: yeah, I will create a branch based on yours and kill the rest of the click compat :) | 13:54 |
| jdstrand | RemoteSnapPart, RemoteManifest, (s *RemoteSnapPart) Install(), etc, etc | 13:55 |
| jdstrand | mvo: fyi, I'm going to keep the launcher json .additional file for this branch to reduce the (already massive) changes | 13:56 |
| mvo | jdstrand: aha, ok. so thats just a snap on the server, to install it, snappy will download it and install it as a SnapPart, i.e. a normal snap | 13:56 |
| jdstrand | mvo: I would expect someone (could be anyone) to clean that up in a separate step | 13:57 |
| mvo | jdstrand: can I write some tests for you to get the branch landed earlier :) I'm really keen (and excited) about it, massive win for me | 13:57 |
| jdstrand | mvo: ok, so that remote stuff I can ignore | 13:57 |
| jdstrand | mvo: I would love help. I'm sprinting next week and low on resources in general | 13:57 |
| mvo | jdstrand: hangout or irc so that you can give me hints what needs to be done? | 13:58 |
| mvo | jdstrand: I will also migrate the branch to git along the way if you don't mind | 13:59 |
| jdstrand | mvo: it isn't heavily tested. things I know need work are finishing hw-assign, making sure framework-policy updates work as expected and deal with the upgrade path | 13:59 |
| jdstrand | mvo: re git, that's fine-- I started this right before the announcement | 13:59 |
| jdstrand | mvo: if you focus on the tests and code reviews outside of hw-assign, I think that would be the best first step | 14:00 |
| jdstrand | mvo: there is an additional cmd/policygen, that I expect to be used as part of a systemd unit for detecting policy updates when system policy changes | 14:01 |
| mvo | jdstrand: ok | 14:02 |
| jdstrand | mvo: my thoughts were: create a ssytemd unit, run something that checks if the system poicy (ie, ubuntu-core-security, apparmor, libseccomp) was changed. if so, see what snaps are affected. for those that are affected, run policygen | 14:03 |
| jdstrand | mvo: maybe it makes sense to move cmd/policygen into 'snappy policygen' | 14:03 |
| jdstrand | mvo: I haven't gone that far yet. if you want to think about how all that should work, that would be helpful as well | 14:04 |
| jdstrand | mvo: or not, I know you're busy, but I figured that would be an area where the snappy core team would definitely want input | 14:05 |
| jdstrand | mvo: but with this we solve the 'seccomp policy not updated on upgrades' card | 14:05 |
| jdstrand | (and move apparmor to the new mechanism, since it is currently using aa-clickhook) | 14:06 |
| jdstrand | anyway, that is probably information overload. thinking about if policygen should be its own command or in snappy is one thing to consider, and thinking about my design thoughts on upgrades is another | 14:07 |
| mvo | jdstrand: in a meeting right now, but https://github.com/mvo5/snappy/tree/from-bzr/snappy-security-cleanup is the imported branch if you want to continue with that | 14:09 |
| jdstrand | ok, thanks | 14:09 |
| jdstrand | mvo: thanks | 14:10 |
| === zyga is now known as zyga-afk | ||
| fgimenez | elopio, we could use build tags, take a look at http://stackoverflow.com/a/28007631 | 14:36 |
| * elopio looks. | 14:37 | |
| elopio | ah, nice! | 14:37 |
| mvo | jdstrand: thanks, meeting is over, I updated https://github.com/mvo5/snappy/tree/from-bzr/snappy-security-cleanup with master, fixed the imports and its doing fine, I look at the missing tests you mentioned now | 14:41 |
| jdstrand | mvo: note, the existing framework-policy updates and hw-assign tests need to be gone through and some certainly need to be reworked | 14:42 |
| mvo | jdstrand: interessting, they don't fail right now | 14:49 |
| jdstrand | mvo: no, because I stripped out the failing parts. hw-assign isn't done, so iirc, I just removed the failing tests expecting to add new tests | 14:49 |
| jdstrand | mvo: framework-policy I removed the 'touch' bits since that was only relevant for touching the symlink for aa-clickhook to work | 14:50 |
| jdstrand | mvo: but, we need to have tests making sure that policy is getting updated if framework-policy does | 14:50 |
| mvo | jdstrand: indeed, thanks | 14:50 |
| mvo | jdstrand: I let me know how best to coordindate, my plan is to go over the diff now and tweak if something stands out, add tests and then get back to what you wrote here and in +2h I will stop with the branch. sounds ok? | 14:52 |
| jdstrand | you plan to write all the tests in 2 hours? wow :) | 14:53 |
| jdstrand | sure, that sounds fine-- thanks for the help | 14:53 |
| mvo | jdstrand: nono :) its just that I need to stop in +2h for dinner :) | 14:53 |
| mvo | jdstrand: if I manage a single test I will consider myself lucky | 14:53 |
| jdstrand | hehe | 14:54 |
| longsleep | jdstrand: yesterday you told me about /{dev,run}/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/* - that does not seem to exist. Should i add a bug for it? | 15:02 |
| jdstrand | longsleep: yes. against ubuntu-core-launcher | 15:02 |
| jdstrand | longsleep: basically, it should do the same thing for that as is being dome in $HOME | 15:03 |
| jdstrand | done* | 15:03 |
| longsleep | jdstrand: all right | 15:03 |
| longsleep | jdstrand: see bug #1511762 | 15:07 |
| ubottu | bug 1511762 in Snappy Launcher "/{dev,run}/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/ folders not created" [Undecided,New] https://launchpad.net/bugs/1511762 | 15:08 |
| jdstrand | longsleep: thanks! | 15:16 |
| === genii is now known as zombiegenii | ||
| === zombiegenii is now known as genii | ||
| elopio | Hello fancycode. | 16:03 |
| fancycode | elopio: Hi | 16:04 |
| elopio | heh, I had a huge lag :) | 16:05 |
| mvo | jdstrand: quick question about findCaps() - the "template" parameter is only used to test for emptiness. is that intended? | 16:27 |
| snappy_ | ubuntu core not updating on snappy edge. Any suggestions? | 16:42 |
| rickspencer3 | tedg, so, if I am using your method of sym linking to the app data directory, and execing the sh file ... | 16:44 |
| rickspencer3 | sorry, I mean exec'ing in the sh file | 16:44 |
| rickspencer3 | in snapcraft.yaml, do I exec the sh file? | 16:44 |
| rickspencer3 | i.e. this is in the shell script I put in bin : exec $SNAP_APP_USER_DATA_PATH/frotz $SNAP_APP_USER_DATA_PATH/ | 16:45 |
| rickspencer3 | so do I define the binary like this? | 16:45 |
| rickspencer3 | zork1: | 16:45 |
| rickspencer3 | exec: bin/zork1 | 16:45 |
| rickspencer3 | also, is there reference documentation for the allowable yaml that I could read? | 16:46 |
| tedg | Yeah, that should work. Make sure to make the script executable. | 16:47 |
| tedg | Let me find that doc | 16:47 |
| jdstrand | mvo: yes | 16:49 |
| jdstrand | mvo: if the template and caps are empty, we set caps to 'network-client' | 16:49 |
| jdstrand | mvo: that is the only reason why template is needed | 16:50 |
| mvo | jdstrand: aha, thanks | 16:51 |
| tedg | rickspencer3: https://developer.ubuntu.com/en/snappy/guides/package-metadata/ | 16:51 |
| rickspencer3 | thanks tedg | 16:51 |
| jdstrand | mvo: when reviewing this, do remember that 'security-override' is revamped | 16:52 |
| jdstrand | mvo: if you recall, before it would point to a json file that was something aa-clickhook would use | 16:52 |
| elopio | ogra_: could you check why the latest images don't have the boot fixes by Chipaca? | 16:53 |
| elopio | snappy_: are you getting an error? | 16:53 |
| Chipaca | elopio: at a pinch, i'd wager it's because it was built from lp and not from github | 16:53 |
| jdstrand | mvo: that is rather weird for a compat-less snappy, so I took the important parts out of that json and put it into the yaml directly | 16:53 |
| mvo | jdstrand: thanks, I started with some tests and tiny refactoring and pushed to git, when you have time I would appreciate if you could fork/remerge. I will stop soon for today | 16:53 |
| mvo | jdstrand: yeah, thats pretty nice | 16:53 |
| elopio | ah, so we'll have the daily sync, then the daily release. | 16:54 |
| jdstrand | mvo: that has a number of nice qualities like, you can use the default template but add a single syscall | 16:54 |
| mvo | jdstrand: look al lvery nice, I'M super happy about this branch, thanks a lot! | 16:54 |
| jdstrand | mvo: nice! yw | 16:55 |
| jdstrand | it was always something I wanted to do, but alas, time | 16:55 |
| mvo | jdstrand: :) | 16:56 |
| mvo | jdstrand: a common problem | 16:56 |
| mvo | jdstrand: hm, looks like I broke something, so please do not merge just yet | 16:56 |
| snappy_ | elopio: no errors. just stuc in version 117 | 17:07 |
| elopio | snappy_: I don't have 117 and that's too old to download from the server. snappy_ please report a bug. | 17:08 |
| mvo | jdstrand: ok, unbroke it, tests started and coverage increased etc, still work left of course, let me know if its looking ok and when you have a git repo so that I can merge from there too | 17:11 |
| snappy_ | elopio: it says updated to version 229. and "reboot to use the new ubuntu-core" when I run update. But it doesn't update on reboot | 17:18 |
| elopio | snappy_: ah, you should have some information on the console. Is that kvm? | 17:20 |
| snappy_ | elopio: yes. its kvm | 17:28 |
| elopio | snappy_: boot your machine with something like kvm -m 512 -redir :8090::80 -redir :8022::22 -snapshot /media/elopio/vms/images/snappy/ubuntu-snappy-rolling-edge-amd64-generic-214.img --serial stdio > out.log | 17:50 |
| elopio | try to reproduce the problem, and attach the out.log to the bug report. | 17:51 |
| snappy_ | elopio: k | 17:51 |
| snappy_ | elopio: how to download current .img.xz for snappy edge? | 18:08 |
| elopio | snappy_: I prefer to use u-d-f. Something like: | 18:11 |
| elopio | sudo ubuntu-device-flash core rolling –channel edge –developer-mode -o ubuntu-snappy-rolling-edge-amd64-generic.img | 18:11 |
| beuno | (amd64)ubuntu@localhost:~$ sudo snappy update | 18:11 |
| beuno | another snappy is running, try again later | 18:11 |
| beuno | snappy has been stuck there for a good 30 minutes | 18:11 |
| beuno | how can I know what it's doing? | 18:12 |
| elopio | beuno: try sudo journalctl -u snappy-autopilot.service | 18:14 |
| elopio | on the next version, that message is improved a little. | 18:14 |
| beuno | ah | 18:14 |
| beuno | it answered itself while I was waiting | 18:14 |
| beuno | snappy autopilot triggered a reboot to boot into an up to date system-- temprorarily disable the reboot by running 'sudo shutdown -c' | 18:14 |
| beuno | The system is going down for reboot at Fri 2015-10-30 18:24:37 UTC! | 18:14 |
| elopio | beuno: so it was just a slow download. Sounds like you are in latin america. | 18:15 |
| beuno | elopio, gathering from the fact that I am wearing flip-flops: yes | 18:16 |
| ogra_ | is that the continent thats connected via a dialup line to europe ? | 18:16 |
| beuno | mvo, sergiusens, Chipaca, I wonder if we could return a more information-rich message? | 18:16 |
| beuno | ogra_, it's mostly connected by salt water | 18:16 |
| ogra_ | lol, true | 18:16 |
| elopio | beuno: the new message says: | 18:18 |
| elopio | The snappy autopilot is updating your system in the background. This may take some minutes. Will try again in %d seconds... | 18:18 |
| elopio | Press ctrl-c to cancel. | 18:18 |
| elopio | how does it sound to you? | 18:18 |
| beuno | a lot better! | 18:18 |
| elopio | I agree, mvo makes cool stuff. | 18:19 |
| beuno | +1000 | 18:19 |
| tetor1 | hellow everybody! I have some problem. I tried to create framework type snap named 'cURL for Snappy Core'. It's a wrapper of cURL, the users can use curl command at Snappy Ubuntu. | 18:35 |
| tetor1 | And I can create it and publish but some errors thrown at web register page. I think those problems are permission or setting file is incorrect. | 18:37 |
| tetor1 | But I have no idea to fix it. | 18:38 |
| tetor1 | I create 'ask Ubuntu' question. Can you help me, someone? | 18:38 |
| tetor1 | http://askubuntu.com/questions/690953/lint-control-architecture-valid-contents-error | 18:39 |
| === tetor1 is now known as tetor | ||
| beuno | tetor, for starters, it won't be accepted in the store as a framework | 18:44 |
| elopio | tetor: why are you making it a framework? | 18:44 |
| elopio | tetor: framework need to be manually reviewed before putting them in the store, so you'll have to wait for somebody to take a look | 18:45 |
| elopio | they will probably tell you that you don't need a framework to make a curl snap. | 18:45 |
| snappy_ | elopio: thx | 18:47 |
| beuno | I can tell you already, it won't get in | 18:50 |
| beuno | found binaries for architecture 'all': bin/curl lint_control_architecture_valid_contents | 18:50 |
| tetor | Oh, year? I thought the cause of reject was setting file (package.yaml) was incorect. | 18:50 |
| beuno | is because you've specified that it runs on all architectures, but it's compiled so clearly it targets specific architectures | 18:50 |
| tetor | beuno: yes! it's error message! | 18:51 |
| tetor | I got it. I'll write target arch e.g. x86_64 and try re publish! | 18:56 |
| tetor | Why I'm making it is, I want to run some command in Snappy. e.g. curl tmux zsh... Without these, I can't work well. | 18:59 |
| beuno | tetor, again, note that it won't be approved as a framework | 19:01 |
| tetor | I have more one question. where is the reference of package.yaml? | 19:02 |
| tetor | beuno umm.. how can I be the 'not starter'? | 19:03 |
| ogra_ | tetor, "for starters" = "first of all" ... | 19:40 |
| ogra_ | frameworks are for shared system resources that other snaps can use ... for example bluetooth | 19:41 |
| ogra_ | a single app will not be accepted as a framework | 19:41 |
| tetor | Sorry, English is too difficult for me… | 19:44 |
| tetor | I see, I'll try to re-create cURL for Snappy as application. Many thanks all!! | 19:45 |
| elopio | tetor: take a look at snapcraft: https://github.com/ubuntu-core/snapcraft/tree/master/examples/downloader-with-wiki-parts | 20:26 |
| elopio | it will make things easier. | 20:27 |
| tetor | elopio: awesome!! Thank you! | 20:40 |
| === genii is now known as zombiegenii | ||
| === zombiegenii is now known as genii | ||
| === genii is now known as zombiegenii | ||
| === zombiegenii is now known as genii | ||
| === genii is now known as zombiegenii | ||
| === zombiegenii is now known as genii | ||
| snappy_ | mir not starting on snappy 1504 edge | 22:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!