| mup | PR snapcraft#1139 closed: plainbox-provider plugin: filter out sitecustomize <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1139> | 01:30 |
|---|---|---|
| mup | PR snapd#2843 opened: cmd/snap-confine: look for PROCFS_SUPER_MAGIC <Created by zyga> <https://github.com/snapcore/snapd/pull/2843> | 01:31 |
| mup | PR snapd#2844 opened: dirs: differentiate between "distro" and "core" libexecdir <Created by zyga> <https://github.com/snapcore/snapd/pull/2844> | 01:39 |
| mup | PR snapd#2845 opened: dirs: use the right snap mount dir for the distribution <Created by zyga> <https://github.com/snapcore/snapd/pull/2845> | 01:42 |
| mup | PR snapd#2846 opened: cmd: autoconf for centos <Created by zyga> <https://github.com/snapcore/snapd/pull/2846> | 01:43 |
| === markusfluer1 is now known as markusfluer | ||
| mup | Bug #1664427 opened: thefuck snap gets an apparmor denial even in classic confinement <classic> <Snappy:New> <https://launchpad.net/bugs/1664427> | 02:20 |
| zyga | Pharaoh_Atem: around? | 02:37 |
| mup | PR snapd#2846 closed: cmd: autoconf for centos <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2846> | 02:50 |
| Son_Goku | zyga: hm? | 02:53 |
| Son_Goku | oh, btw, I think the Fedora EPEL buildroots are actually RHEL systems | 02:54 |
| Son_Goku | though I'm not sure about that | 02:54 |
| Son_Goku | so you'll need to add "redhat" | 02:54 |
| Son_Goku | and "rhel" | 02:54 |
| Son_Goku | actually, I think the identifier is just "rhel" | 02:55 |
| Son_Goku | yep, rhel | 02:55 |
| Son_Goku | zyga: you need to add "rhel" otherwise snap-confine won't build right in epel | 03:16 |
| === chihchun_afk is now known as chihchun | ||
| mup | Bug #1650187 changed: Can't run any snap application on Mint 18 <Snappy:Expired> <https://launchpad.net/bugs/1650187> | 04:17 |
| === JanC is now known as Guest77653 | ||
| === JanC_ is now known as JanC | ||
| liuxg | ogra_, ping | 06:25 |
| liuxg | ogra_, I cannot console-conf my pi3 device. it just shows that (Client.Timeout exceeded while awaiting headers). error: while creating users: cannot create use 'xxxxx". I have sent an email titled with "Currernt config hook implementation scales very badly". There are some attached picttures there. how can I resolve this problem? | 06:28 |
| liuxg | ogra_, sorry, the email was tittled with "Issue with ubuntu OS snap first time boot." | 06:28 |
| liuxg | lool ping | 07:14 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#2515 closed: snap run: create "current" symlink in user data dir <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2515> | 08:30 |
| mup | Bug #1664484 opened: Missing interface to record audio from pulseaudio <Snappy:New> <https://launchpad.net/bugs/1664484> | 09:16 |
| ogra_ | liuxg, how is that related to the config hooks ? | 09:27 |
| zyga | Pharaoh_Atem: hey, I've sent a few patches that make the code work on fedora/centos/rhel | 09:29 |
| zyga | Pharaoh_Atem: I'll refresh the package once 2.23 which includes those fixes is out | 09:29 |
| liuxg | ogra_, ping | 09:59 |
| ogra_ | yes | 09:59 |
| ogra_ | i'm here :) | 09:59 |
| didrocks | he is here \o/ | 10:00 |
| ogra_ | lol | 10:03 |
| liuxg | ogra_, currently I cannot get my pi3 device console-conf I just reported a bug at https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1664471 | 10:04 |
| mup | Bug #1664471: Creating user failed when doing console-conf for raspberry pi3 device <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1664471> | 10:04 |
| liuxg | ogra_, is that a network problem? | 10:04 |
| ogra_ | liuxg, sounds like a store bug to me | 10:04 |
| ogra_ | or do you have some proxy in place | 10:05 |
| liuxg | ogra_, interestingly, my pi2 device can get the job done. | 10:05 |
| ogra_ | both through wired lan ? | 10:05 |
| liuxg | ogra_, no, I do not have any proxy. my colleague in shanghai did get the work done. | 10:05 |
| liuxg | ogra_, yes. | 10:05 |
| ogra_ | and through the same lan specifically ? | 10:05 |
| liuxg | ogra_, exactly, the same cable. | 10:06 |
| ogra_ | and it is properly plugged ? :) | 10:06 |
| liuxg | ogra_, I think so. otherwise, it cannot go the last step. | 10:06 |
| ogra_ | true, you wouldnt get an IP | 10:06 |
| ogra_ | (or do you use static ?) | 10:06 |
| liuxg | ogra_, I tried it for the whole morning. I did not set anything, I think. | 10:07 |
| liuxg | ogra_, I just attached the syslog file in the bug report. | 10:08 |
| lool | liuxg: pong | 10:29 |
| lool | ppisati_: Hi! | 10:30 |
| lool | ppisati_: one of the MWC demos is on RPis, and it breaks with a kernel backtrace when refreshing snaps: | 10:30 |
| lool | https://bugs.launchpad.net/snapd/+bug/1664368 | 10:30 |
| mup | Bug #1664368: snap refresh hangs on arm architecture <snapd:New> <https://launchpad.net/bugs/1664368> | 10:30 |
| liuxg | lool, I am now having a problem on console-conf my pi3 device. I reported a bug at https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1664471.. ogra_just now helped me to answer me. | 10:30 |
| mup | Bug #1664471: Creating user failed when doing console-conf for raspberry pi3 device <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1664471> | 10:30 |
| lool | ppisati_: would you mind scheding some light ont his? | 10:31 |
| lool | *this | 10:31 |
| lool | liuxg: oh cool, sorry for the delay | 10:31 |
| lool | hadn't opened IRC since yesterday morning | 10:31 |
| liuxg | lool, it is ok. :) | 10:32 |
| ogra_ | liuxg, your syslog looks fine, i really bet its a login.ubuntu.com issue | 10:32 |
| liuxg | ogra_, yeah, it is a little bit weird. my colleague also experienced the same problem. but he tried a few times more, then it became successful.. | 10:33 |
| liuxg | ogra_, lool another colleague didrocks got 10 mins to configure a device. | 10:33 |
| didrocks | (that was in december, under the same network that I'm complaining snapd to regularly fail) | 10:34 |
| ogra_ | yeah, thats rather normal ... still being researched (part of it is that the initial snapd configuration eats all CPU cores at 100% for a while) | 10:34 |
| didrocks | liuxg: btw, I know ogra_ and lool for years (almost 10), no need to present me :) | 10:34 |
| lool | isn't it a nice thing though? | 10:35 |
| ogra_ | the system is under high load and very slow at that point ... sometimes you are lucky and it is fast ... but thats rather the exception | 10:35 |
| ogra_ | lool, well, your CPU is completely eaten ... not sure IO nicing would change that | 10:35 |
| lool | haha | 10:36 |
| lool | it took me a while to even get the joke, tells you how fried my CPU is | 10:36 |
| ogra_ | bug 1632124 btw | 10:36 |
| mup | Bug #1632124: snapd pegging cpu at 100% <Snappy:Expired> <https://launchpad.net/bugs/1632124> | 10:36 |
| ogra_ | oh, mvo closed it ... | 10:37 |
| didrocks | I think you are mixing the snapd network issue with this, but yeah, it could be 2 separated things | 10:37 |
| ogra_ | didrocks, if it succeeds it is the systerm load most likely | 10:37 |
| didrocks | (when snapd disconnect, it's really due to the network/snapd interactions, even when io load and CPU are next to 0) | 10:37 |
| mvo | ogra_: it expired, looking at it again it looks like for the wrong reasons | 10:38 |
| ogra_ | yeah | 10:38 |
| ogra_ | i know someone dug into it (Chipaca ?) ... but i dont remember it being fixed | 10:39 |
| zyga | o/ | 10:40 |
| zyga | hey guys, I've been here just busy with meetings | 10:40 |
| ogra_ | stop having meetings then ! | 10:40 |
| ogra_ | :) | 10:40 |
| zyga | I moved all of them to one day | 10:40 |
| zyga | (next step is to take a day off on that day) ;-) | 10:41 |
| ogra_ | do you call it the pain-day ? :) | 10:41 |
| ppisati_ | lool: replied to that lp bug and assigned to me | 10:52 |
| lool | ppisati_: <3 | 10:53 |
| ogra_ | didrocks, mvo, hah, my bug search actually failed me ... i was actually meaning bug 1638537 above | 10:57 |
| mup | Bug #1638537: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1638537> | 10:57 |
| ogra_ | the classic does 100% cpu one is indeed in the works | 10:58 |
| ogra_ | (silly me, was just searching for "100% CPU" and hit the wrong one) | 10:58 |
| didrocks | ogra_: oh btw, is your classic snap a chroot or a lxd container? | 11:03 |
| didrocks | I was aked when reading the tutorial, I was telling it's a container | 11:04 |
| ogra_ | chroot | 11:05 |
| ogra_ | we dont have lxd support in the core snap by default | 11:05 |
| ogra_ | (you need the lxd snap) | 11:05 |
| didrocks | ogra_: ok, thanks for the clarification :) | 11:08 |
| mup | PR snapcraft#1127 closed: Release changelog for 2.27 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1127> | 11:18 |
| mup | PR snapd#2775 closed: cmd: add functions to load/save fstab-like files <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2775> | 11:35 |
| zyga | jdstrand: hey, can you please try to review https://github.com/snapcore/snapd/pull/2827/files today | 11:35 |
| mup | PR snapd#2827: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827> | 11:35 |
| zyga | jdstrand: it's based on the earlier mount work and is very small (doesn't get used in snap-confine yet, just adds the library functions) | 11:36 |
| zyga | jdstrand: using this I can propose nice chunks of update-ns next | 11:36 |
| mup | PR snapd#2588 closed: cmd/snap: add shell completion to connect <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2588> | 11:53 |
| mup | PR snapd#2251 closed: interface hooks: support for setting/getting slot/plug attributes with snapctl (step 3) <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2251> | 12:01 |
| mup | PR snapd#2421 closed: tests: add basic test for docker <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2421> | 12:03 |
| mup | PR snapd#2475 closed: tests: nested image testing <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2475> | 12:12 |
| mup | PR snapd#2654 closed: i18n: look into core snaps when checking for translations <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2654> | 12:36 |
| mup | PR snapd#2626 closed: interfaces: relax path requirements for serial <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2626> | 12:41 |
| mup | PR snapd#2847 opened: tests: enable docker test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2847> | 12:42 |
| mardy | pstolowski: hi! Quick question: if an interface is auto-connectable, and then I manually disconnect and reconnect it, will the interface hooks be run at this last step? | 13:20 |
| pstolowski | mardy, hey. interesting question, I think they will be run, but to be 100% sure I'd need to check the code | 13:22 |
| pstolowski | mardy, btw, my branch #3 landed | 13:22 |
| mardy | pstolowski: I saw, great stuff! :-) | 13:22 |
| mardy | pstolowski: should I file a bug to track when the interface hooks will be run for auto-connectable interfaces, or do you already have a task for that? | 13:23 |
| pstolowski | mardy, no need for bug, it's on my list I shared with alecu and i've it on my whiteboard at home ;) | 13:26 |
| mardy | pstolowski: send a pic | 13:27 |
| mardy | pstolowski: joking ;-) | 13:27 |
| ogra_ | he cant, he has all his passwords written there too ;) | 13:27 |
| pstolowski | autoconnect is going to be the most complex of all changes, since this code is currently kind of a special case which doesn't work the way connect does | 13:28 |
| pstolowski | mardy, http://imgur.com/a/hILGi ;) | 13:32 |
| pstolowski | mardy, see, i'm not making this up ;) | 13:32 |
| mardy | pstolowski: :-D | 13:32 |
| mup | PR snapd#2848 opened: cmd/snap-update-ns: add compare function for mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/2848> | 13:49 |
| jdstrand | zyga: historically setuid executables are attacked in their failure conditions | 14:10 |
| jdstrand | zyga: everything is typically fine when things go right, but when they go wrong, there may be latent bugs. that is mitigated somewhat on Ubuntu because of the apparmor profile (though it necessarily allows a lot), but many distros don't have that | 14:12 |
| zyga | jdstrand: I understand that, we could make the debug code somewhat more paranoid (e.g. we could quote the paths and filesystem type) | 14:13 |
| jdstrand | zyga: I thought I was quite clear weeks ago that lots of string handling code (ie, a greater attack surface) would not be used in production, only debug | 14:13 |
| jdstrand | zyga: and I thought all the new code I was reviewing was working towards that | 14:13 |
| zyga | jdstrand: I think that right now we still do logging and (and do so less carefully) and this PR was aiming to fix that | 14:13 |
| zyga | jdstrand: no that wasn't clear, I though you wanted that to be off by default (hence the lazy compute of the command) | 14:14 |
| zyga | jdstrand: at some point without code like this the debug / die messages are useless | 14:14 |
| jdstrand | zyga: I didn't think anything was using sc_mount_cmd yet, as it was only added to the library | 14:14 |
| zyga | jdstrand: if you want to remove those we need a plan on how the app will be debuggable | 14:14 |
| zyga | jdstrand: nothing is using it yet, only thew two new calls added in this PR | 14:14 |
| jdstrand | zyga: env var aside, it isn't off by default if when you die() you run through all the code | 14:15 |
| zyga | jdstrand: yes, and I did that on purpose | 14:15 |
| jdstrand | I'm confused then | 14:15 |
| jdstrand | you just said "I though you wanted that to be off by default" and then you said "I did that on purpose" | 14:15 |
| zyga | jdstrand: I misunderstood you earlier and I implemented the lazy code so that we don't do it usually | 14:15 |
| zyga | jdstrand: but we do compute it when the message is needed (either because debug is on or because we need to die) | 14:16 |
| zyga | jdstrand: if you are saying I cannot, under no conditions, compute the message in production then that's fine | 14:17 |
| zyga | jdstrand: but what is the app going to do then | 14:17 |
| zyga | jdstrand: I think this is a reduction in functionality compared to what we have now (hand-made message in each case) | 14:17 |
| jdstrand | zyga: I expected the die() to have a simpler must_snprintf hand-made message | 14:17 |
| zyga | jdstrand: then the whole point of this branch is lost | 14:18 |
| jdstrand | no it isn't | 14:18 |
| jdstrand | someone trying to reproduce can use it with debugging enabled | 14:18 |
| jdstrand | or | 14:18 |
| jdstrand | you make this config file option | 14:19 |
| jdstrand | and the config file is root owned | 14:19 |
| jdstrand | or | 14:19 |
| jdstrand | you permanently drop privileges | 14:19 |
| zyga | jdstrand: nobody will do any of those things when they report a bug with a message they got, for debugging done by an experienced person various things are possible | 14:19 |
| zyga | jdstrand: actually | 14:19 |
| zyga | jdstrand: how about that last idea? | 14:19 |
| zyga | jdstrand: I have a branch for that | 14:19 |
| zyga | jdstrand: adds library function for dropping/raising/permanently dropping privs | 14:20 |
| zyga | jdstrand: I did that after the sprint | 14:20 |
| jdstrand | zyga: what inexperienced person is going to debug the finer points of snap-confine's mount operations? | 14:20 |
| zyga | jdstrand: after tyler's suggestion | 14:20 |
| zyga | jdstrand: exactly, nobody | 14:20 |
| zyga | jdstrand: so they will just throw a bug with a message that they get | 14:20 |
| zyga | jdstrand: the point of this branch is to have that message as good as we can use | 14:20 |
| jdstrand | zyga: yes, so, an experienced person could flip a setting in a config file | 14:20 |
| zyga | jdstrand: well, you assume you can reproduce, that's not always the case | 14:21 |
| jdstrand | anyway, there is also dropping privileges | 14:21 |
| zyga | jdstrand: (weird kernel/setting) | 14:21 |
| zyga | jdstrand: I'd much rather drop privs | 14:21 |
| zyga | jdstrand: and for the config, that's more parsing (but we can explore that as it would have some value) | 14:21 |
| zyga | jdstrand: so if you are +1 on doing this after dropping privs then I'll just do it | 14:21 |
| jdstrand | if we *permanently* drop privileges, I have no problem | 14:22 |
| zyga | perfect | 14:22 |
| zyga | jdstrand: thank you and I'm sorry for the confusion | 14:22 |
| zyga | jdstrand: I recall we spoke about this as an option (compile time choice) | 14:22 |
| zyga | jdstrand: but I didn't think we agreed on that | 14:22 |
| * jdstrand shrugs | 14:22 | |
| zyga | jdstrand: it's just been in review and iteration for too long and I must have forgotten (the whole mount code change) | 14:22 |
| zyga | jdstrand: I'll get right to it :) | 14:23 |
| zyga | jdstrand: oh | 14:23 |
| jdstrand | one way to reduce attack surface is to not have the code compiled | 14:23 |
| zyga | jdstrand: can you review a 3 line difff? | 14:23 |
| zyga | for the next release tomorrow: https://github.com/snapcore/snapd/pull/2843 | 14:23 |
| mup | PR snapd#2843: cmd/snap-confine: look for PROCFS_SUPER_MAGIC <Created by zyga> <https://github.com/snapcore/snapd/pull/2843> | 14:23 |
| jdstrand | zyga: I was going to that when you pinged me | 14:23 |
| jdstrand | the release is tomorrow? | 14:23 |
| zyga | jdstrand: this makes snap-confine functional on the 3.10 kernel | 14:23 |
| jdstrand | jeez | 14:23 |
| zyga | jdstrand: I think it is, I'm not sure | 14:23 |
| zyga | jdstrand: especially with the state of reexec being in the middle | 14:24 |
| zyga | jdstrand: but mvo mentioned that deadline is tomorrow | 14:24 |
| jdstrand | I thought it was always on thursday | 14:24 |
| zyga | jdstrand: probably what mvo meant was EOD tomorrow is when master feezes | 14:24 |
| zyga | s/probably/possibly/ (or maybe) | 14:25 |
| mvo | jdstrand, zyga: 2.23 is EOD tomorrow, I plan to make the 2.23 release in my morning on Thursday | 14:25 |
| mvo | (not having any more context, I assume this is what you asked?) | 14:26 |
| zyga | mvo: what is the state of reexec code? | 14:26 |
| zyga | mvo: yes | 14:26 |
| zyga | mvo: I think we wanted to polish that to the point where we can reenable everything I removed from the policy | 14:26 |
| popey | https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662181 # this bug is blocking a couple of snaps - can we get a plan of record on that bug? zyga ? | 14:26 |
| jdstrand | zyga: you requested that https://github.com/snapcore/snapd/pull/2749 not land until snap-confine is executed from the core | 14:26 |
| mup | Bug #1662181: Aliases didn't enable out of the box <isv> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662181> | 14:26 |
| mup | PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749> | 14:26 |
| jdstrand | zyga: but there are 3 or 4 PRs that already landed that use arg filtering | 14:26 |
| jdstrand | zyga, mvo: does that mean https://github.com/snapcore/snapd/pull/2749 won't be in 2.23? | 14:27 |
| zyga | popey: that's something for pedronis I think | 14:27 |
| zyga | jdstrand: I see | 14:27 |
| mvo | jdstrand: I added it to the 2.23 list, at least it will get priority this way | 14:28 |
| jdstrand | also, I thought that snap-confine executed from core was going to land Friday-ish | 14:28 |
| jdstrand | I thought I saw it merged, I'm I mistaken? | 14:28 |
| zyga | mvo: I think that we need to have a clear story on how this is going to affect 2.23, I think it's fine to delay for next week if that is required, otherwise we'd have to do more changes (negative) to the security profiles | 14:28 |
| Son_Goku | zyga, I left a comment on https://github.com/snapcore/snapd/pull/2845 | 14:28 |
| mup | PR snapd#2845: dirs: use the right snap mount dir for the distribution <Created by zyga> <https://github.com/snapcore/snapd/pull/2845> | 14:28 |
| mvo | jdstrand: snap-confine from core is still under review, I hope we can get this in | 14:29 |
| zyga | jdstrand: I gave +1 on one of the branches but that will break debian/14.04 I'm sure | 14:29 |
| zyga | Son_Goku: hey | 14:29 |
| mvo | zyga: ok, if its fine to delay, w edelay | 14:29 |
| zyga | Son_Goku: thank you | 14:29 |
| jdstrand | let me see if there is anything else that would break. quota and ioctl were the two we undid. I thought there were others | 14:30 |
| zyga | Son_Goku: replied | 14:30 |
| zyga | jdstrand: it's not merged yet: https://github.com/snapcore/snapd/pull/2810 | 14:32 |
| mup | PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810> | 14:32 |
| Son_Goku | zyga: replied ;) | 14:33 |
| zyga | Son_Goku: replied, also given the merge window closing I think the more elaborate checks will have to wait a few weeks | 14:35 |
| Son_Goku | okay | 14:35 |
| zyga | Son_Goku: did you see my tweet last night? | 14:37 |
| Son_Goku | do we need https://github.com/snapcore/snapd/pull/2844 when https://github.com/snapcore/snapd/pull/2845 already has its commit? | 14:37 |
| mup | PR snapd#2844: many: differentiate between "distro" and "core" libexecdir <Created by zyga> <https://github.com/snapcore/snapd/pull/2844> | 14:37 |
| mup | PR snapd#2845: dirs: use the right snap mount dir for the distribution <Created by zyga> <https://github.com/snapcore/snapd/pull/2845> | 14:37 |
| Son_Goku | zyga: I did | 14:37 |
| jdstrand | zyga, mvo: the other one I was thinking of was 'setpriority PRIO_PROCESS 0 <=19', but that isn't a problem because PRIO_PROCESS has been in snap-confine for ages | 14:37 |
| jdstrand | mvo: it it help if I rebased https://github.com/snapcore/snapd/pull/2749 on https://github.com/snapcore/snapd/pull/2810? is there another way in github to say that one branch depends on another? | 14:38 |
| mup | PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749> | 14:38 |
| mup | PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810> | 14:38 |
| jdstrand | s/it it/would it/ | 14:38 |
| * jdstrand remove the netlink rule from https://github.com/snapcore/snapd/pull/2842 since if we allow it, it will be with arg filtering | 14:39 | |
| mup | PR snapd#2842: interfaces: misc updates for network-control, firewall-control, unity7, x11 and default policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2842> | 14:39 |
| mvo | jdstrand: maybe, but let me try to get a review for #2810 | 14:40 |
| Cynerva | zyga: you available to help me figure out permission errors on the kubelet snap? | 14:44 |
| balloons | Can you guys have a look at https://bugs.launchpad.net/juju/+bug/1660273 ? It seems like /snap/bin is missing from PATH | 14:50 |
| mup | Bug #1660273: /etc/environment does not include /snap/bin in $PATH <cloud-images:Invalid> <juju:New> <Snap Layer:Fix Released> <snapd:New> <https://launchpad.net/bugs/1660273> | 14:50 |
| jdstrand | mvo: can you add https://github.com/snapcore/snapd/pull/2842 to the 2.23 list? I reverted the commit that zyga, tyhicks, tsdgeos and I were discussing. the rest has a +1 from zyga | 14:50 |
| mup | PR snapd#2842: interfaces: misc updates for network-control, firewall-control, unity7 and default policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2842> | 14:50 |
| jdstrand | mvo: so just need another +1 | 14:50 |
| zyga | Cynerva: hey | 14:51 |
| zyga | Cynerva: can you tell me more about the problem please | 14:51 |
| zyga | Cynerva: I'll try to help but I'll be also coding on a few other branches while we speak | 14:51 |
| zyga | balloons: I just did, can you be more specific please | 14:52 |
| Cynerva | zyga: cool, thanks. we're working on a kubelet snap, we have it working with classic confinement, but trying to make it strict | 14:54 |
| balloons | zyga, ty. /snap/bin is missing from PATH in /etc/environment. This means non-login shells don't have PATH set properly for snaps | 14:55 |
| Cynerva | zyga: we're hitting permission errors on several files i can't find an interface for - a bunch related to cgroups, like /proc/self/cgroup, /sys/fs/cgroup/memory, and several others | 14:56 |
| Cynerva | zyga: full list is here https://gist.github.com/Cynerva/9150f379cdf1d41aac9ae233597c1f64 | 14:56 |
| zyga | balloons: I don't think we can add it there, we only add it through /etc/profile.d/apps-bin-path.sh | 14:57 |
| Cynerva | zyga: it looks like it's also trying to move the docker pid in /var/run/docker.pid (we have the docker snap installed and connected from stable channel) | 14:57 |
| zyga | Cynerva: for everything apart from docker: do file a bug report on launchpad.net/snapd, tag it with snapd interface | 14:58 |
| zyga | Cynerva: snapd-interface (with a dash) | 14:58 |
| zyga | Cynerva: there's no interface for cgroups that I'm aware of and snapd also uses cgroups in some ways some please describe as much as you can what the app is doing and why | 14:59 |
| ryebot | nessita: are you available to discuss snap store namespaces? I'm wondering if there's a way to either transfer a snap to another namespace, rename a snap, or delete a snap. | 14:59 |
| zyga | Cynerva: for the /var/run/docker.pid, can you tell me what's going on there? why would the app move it? | 15:00 |
| nessita | ryebot, hi! yes we can do first and last option | 15:00 |
| nessita | ryebot, renames are not a thing yet | 15:00 |
| nessita | ryebot, what's the snap? | 15:00 |
| balloons | zyga, I think we want PATH to be consistent | 15:00 |
| zyga | balloons: want != can | 15:00 |
| ogra_ | balloons, where is that ? classic ? | 15:00 |
| zyga | balloons: whatever we want is done somehow, there's no way that we know of that would let us stick an item in path other than /etc/environemt | 15:01 |
| Cynerva | zyga: okay, will do on the others, thanks :) as for the docker pid, i really have no idea, but i can look into it | 15:01 |
| ryebot | nessita: ah, that's excellent, thanks! There's three of them: kube-apiserver, kube-controller-manager, and kube-scheduler | 15:01 |
| zyga | balloons: and there are plenty of small places that keep a copy of "vanilla path" that still break | 15:01 |
| nessita | ryebot, let me check a few things first | 15:01 |
| zyga | balloons: I'd like to know why the current approach that we do doesn't work in the places that were mentioned in the bug | 15:01 |
| ryebot | nessita: I think just deleting them would be fine | 15:01 |
| nessita | ryebot, I can certainly delete them, but may I ask what's the reason? | 15:03 |
| pedronis | popey: we are likely changing how aliases work, so that bug won't be quite the same | 15:03 |
| ryebot | nessita: I posted them to the store for testing purposes, but we'll be making a namespace for them in the future and I didn't want the tests to be in the way. Poor choice of name the first time around, basically. | 15:04 |
| zyga | nessita: my suggestion would be to take advantage of the new project for the store and route all such requests through bugs there | 15:04 |
| ogra_ | balloons, note that this is a bash "feature" ... | 15:04 |
| zyga | nessita: you'll get free accountability and tracking | 15:04 |
| nessita | zyga, did those messages are truly for me? | 15:05 |
| zyga | nessita: yes, | 15:06 |
| nessita | zyga, ah, I see what you mean :-) | 15:06 |
| zyga | nessita: all the store request are informal / on irc; I think it would be a good idea, for transparency to request that they are filed as bugs on the store | 15:06 |
| pedronis | popey: anyway short story both now and in the future you need to ask on snapcraft list or a reviewer to get the aliases enabled | 15:06 |
| balloons | ogra_, zyga, perhaps it's better in /etc/bash.bashrc? | 15:06 |
| nessita | zyga, sounds good, thanks for the suggestion | 15:06 |
| pedronis | popey: through a store mechanism | 15:06 |
| balloons | and you are right.. ksh or other users are busted too :-) | 15:07 |
| ogra_ | balloons, i thin thats not read if you have ~/.bashrc ... which we cant midify | 15:07 |
| ogra_ | *modify | 15:07 |
| balloons | mm.. Indeed | 15:07 |
| ogra_ | (and which is created by default usually when a user is created) | 15:07 |
| ogra_ | balloons, where do you have that issue ? on classic | 15:07 |
| nessita | ryebot, following the suggestion from zyga, would you mind filing a bug-request at https://bugs.launchpad.net/snapstore with the delete request? then I can execute asap | 15:08 |
| balloons | ogra_, I imagine you would have it for all non-login shells | 15:08 |
| ogra_ | note that we have a bit more freedon regarding /etc/environment on the core images | 15:08 |
| ryebot | nessita: Not at all, thanks a ton! | 15:08 |
| balloons | ogra_, but yes this is on non-core ubuntu images | 15:08 |
| ogra_ | and the last edge images actually have that path in /etc/environment | 15:08 |
| zyga | nessita: \o/ thank you, I think this is very important | 15:08 |
| ogra_ | for all other setups you need to add a snippet to your bashrc to source profile.d | 15:09 |
| ryebot | nessita: https://bugs.launchpad.net/snapstore/+bug/1664601 | 15:09 |
| mup | Bug #1664601: Please remove kube-apiserver, kube-controller-manager, and kube-scheduler from the store <Snap Store:New> <https://launchpad.net/bugs/1664601> | 15:09 |
| mup | PR snapd#2849 opened: cmd: don't reexec on RHEL family <Created by zyga> <https://github.com/snapcore/snapd/pull/2849> | 15:10 |
| zyga | mvo: ^^ along with the other branches | 15:10 |
| ryebot | Out of curiosity, is renaming/deleting/transferring snaps going to be a user-doable thing in the future? | 15:10 |
| balloons | ogra_, is adding /snap/bin to /etc/environment for non-core images not an option? Do we feel this can't be modified? | 15:10 |
| ogra_ | balloons, right ... you can try to convince foundations if you feel like ... but i guess chances are low they want that :) | 15:11 |
| nessita | ryebot, excellent! thanks | 15:11 |
| ryebot | nessita: thank you :) | 15:11 |
| ogra_ | balloons, you cant really modify this file from a package ... snapd isnt necessary always installed everywhere so it shouldnt be in the default path in /etc7environment but instead enhance the path | 15:12 |
| popey | pedronis: hm, okay. Any chance of a public reply on the bug so we can point people at it? | 15:12 |
| pedronis | popey: yes | 15:12 |
| pedronis | will write something | 15:12 |
| balloons | ogra_, snapd actually has the prominece since xenial. I've assumed it was there akin to apt | 15:12 |
| ogra_ | balloons, debootstrap wont install it for example :) | 15:13 |
| ogra_ | balloons, bring it up with foundations, they own the classic images ... i'Äd happily drop the hack we use for the core images and just inherit their path from the default file | 15:13 |
| ogra_ | but i fear i know the answer when you ask them :) | 15:14 |
| ogra_ | balloons, beyond that: ssh user@host "source /etc/profile; /path/script.sh" | 15:15 |
| ogra_ | that will definitely work around it as a quick hack | 15:15 |
| balloons | ogra_, ack. Given you are correct in that it's not "always" there, asking for a change seems impossible. However, my bigger fear even assuming the change made sense was getting onto xenial at this point | 15:16 |
| balloons | thanks for your comments. I'll add them to the bug | 15:17 |
| ogra_ | yeah, /etc/environment is created by the installer iirc ... | 15:17 |
| ogra_ | and usually not modified after install ... | 15:17 |
| ogra_ | i never understood why bash has this special treatment of remote sessions ... but there surely is a valid reason | 15:18 |
| balloons | yea, it's a bit fun when trying to debug something you can run interactively, but not via cron | 15:21 |
| ogra_ | yup | 15:21 |
| popey | pedronis: thanks! | 15:21 |
| mup | PR snapd#2850 opened: config: make helpers reusable <Created by stolowski> <https://github.com/snapcore/snapd/pull/2850> | 15:26 |
| Cynerva | zyga: looks like it's just reading /var/run/docker.pid, and when that fails, falls back to pidof. so maybe that one's not really a problem | 15:27 |
| zyga | Cynerva: I see, can you check why it is doing that? | 15:27 |
| mup | PR snapd#2851 opened: tests: failover test for rc.local crash <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2851> | 15:32 |
| Cynerva | zyga: ah, looks like it's putting the docker process in a cgroup | 15:34 |
| mup | PR snapd#2834 closed: release: add galliumos support <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2834> | 15:46 |
| zyga | Cynerva: I see, ok | 15:52 |
| zyga | Cynerva: that feels like a separate feature; Can you please report a second bug with the details describing this (why, which cgroup) | 15:52 |
| Cynerva | zyga: will do, thanks :) | 15:53 |
| zyga | Cynerva: thank you, we'll get to it but not today | 15:57 |
| mup | PR snapd#2718 closed: cmd: add non-stub implementation of snap-update-ns <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2718> | 16:03 |
| mup | PR snapd#2488 closed: interaces: add new boot-config interface <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2488> | 16:05 |
| zyga | jdstrand: can you have a quick look if this is the kind of API you were thinking about? | 16:06 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/2852 | 16:07 |
| mup | PR snapd#2852: cmd/libsnap: add privilege elevation helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2852> | 16:07 |
| mup | PR snapd#2852 opened: cmd/libsnap: add privilege elevation helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2852> | 16:07 |
| zyga | jdstrand: (I will patch the code to actually do the effective == 0 but real != 0 checks as well, this is just for the API itself | 16:10 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/2749 adds a spread test in a location that is not used anymore | 16:28 |
| mup | PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749> | 16:28 |
| zyga | jdstrand: you need to put all the new tests in tests/ at the top of the tree | 16:28 |
| zyga | jdstrand: I'll move the old tests there one by one, I should have finished that already :/ | 16:28 |
| lazyPower | nessita - can i piggy back on ryebot's bug with my own? https://bugs.launchpad.net/snapstore/+bug/1664634 -- similar situation. i've had this since initial POC and the naming was poor for a test repository | 16:33 |
| mup | Bug #1664634: Please delete the kubectl snap from the snap-store <Snap Store:New> <https://launchpad.net/bugs/1664634> | 16:33 |
| mup | PR snapd#2769 closed: snap-exec: support nested environment variables in environment: <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2769> | 16:37 |
| nessita | lazyPower, sure! will check that out right after my lunch | 16:37 |
| lazyPower | thanks nessita appreciate the alley-oop | 16:38 |
| nessita | \o/ | 16:38 |
| zyga | jdstrand: I just pushed to 2852 again, this time with code that I think is real; you can now review both the .h and the .c files | 16:39 |
| zyga | jdstrand: please suggest tests for this if you feel they are useful (can be done, just costly) otherwise let's land this and use it in the mount branch and in various parts of snap-confine | 16:40 |
| mup | PR snapd#2850 closed: config: make helpers reusable <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2850> | 16:41 |
| pedronis | popey: I wrote a comment in that bug | 16:48 |
| zyga | Pharaoh_Atem: I got an email notifying me about deletion of golang-github-mvo5-uboot-go-0-0.2.git5927df7.fc23 | 17:05 |
| zyga | Pharaoh_Atem: is tha because f23 if EOLd? | 17:05 |
| mup | PR snapcraft#1137 closed: Build-depend on git <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1137> | 17:33 |
| === mwenning is now known as mwenning-lunch-r | ||
| mup | PR snapd#2849 closed: cmd: don't reexec on RHEL family <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2849> | 18:36 |
| === cjwatson_ is now known as cjwatson | ||
| cory_fu | Is there a PPA for getting latest stable snapd on trusty? | 19:19 |
| kyrofa | ogra_, mwhudson does console-conf place something in /etc/network/interfaces.d/ ? | 19:49 |
| kyrofa | (after first boot) | 19:49 |
| kyrofa | Ah, netplan | 19:50 |
| kyrofa | ogra_, mwhudson so if I wanted to connect to a wireless network after I connected to a wired network, would I put something in /etc/netplan/ or /etc/network/interfaces.d/ ? | 19:51 |
| mup | PR snapd#2844 closed: many: differentiate between "distro" and "core" libexecdir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2844> | 20:06 |
| mup | PR snapd#2845 closed: dirs: use the right snap mount dir for the distribution <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2845> | 20:16 |
| kyrofa | ondra, any chance you're around? | 20:19 |
| mup | PR snapd#2843 closed: cmd/snap-confine: look for PROCFS_SUPER_MAGIC <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2843> | 20:22 |
| ondra | kyrofa hi | 20:35 |
| ondra | jdstrand on holidays, but around for bit | 20:35 |
| ondra | jdstrand sorry was for kyrofa | 20:36 |
| ondra | kyrofa what's up? | 20:36 |
| kyrofa | ondra, ah, no, go away! | 20:36 |
| ondra | kyrofa lol | 20:36 |
| kyrofa | ondra, I think I've got it | 20:36 |
| ondra | kyrofa just tell me | 20:36 |
| ondra | kyrofa killing a bit of free time here | 20:36 |
| kyrofa | ondra, okay I'll be quick | 20:37 |
| kyrofa | ondra, after first boot on ubuntu core, the networking config is done via netplan. Are you familiar with that piece? | 20:37 |
| ondra | kyrofa as much as changing config on devices | 20:38 |
| kyrofa | ondra, therein lies my question. Is changing the netplan config the recommended way to change network config? | 20:38 |
| kyrofa | ondra, or should I be doing that in /etc/network/interfaces.d/ still? | 20:38 |
| ondra | kyrofa I was hoping so, as I do it on some of my devices quite often | 20:38 |
| kyrofa | Heh | 20:39 |
| kyrofa | ondra, okay, so you use netplan as opposed to the old way? | 20:39 |
| ondra | kyrofa I typically edit /etc/netplan/...yaml | 20:39 |
| kyrofa | Okay good deal | 20:39 |
| kyrofa | And then run `netplan apply`? | 20:39 |
| ondra | kyrofa yeah edit yaml, then netplan generate + apply | 20:39 |
| ondra | kyrofa yeah generate before apply | 20:40 |
| kyrofa | ondra, ah, what does generate do? | 20:40 |
| kyrofa | "backend specific configuration files" | 20:40 |
| kyrofa | Backend being systemd-networkd? | 20:41 |
| kyrofa | As opposed to network manager? | 20:41 |
| ondra | kyrofa let me show you my yaml, as I had case where I have device with 4 ethernet ports and wanted to configure it to share connections | 20:41 |
| kyrofa | ondra, oh sweet | 20:41 |
| ondra | kyrofa this is for example I use on my deice http://paste.ubuntu.com/23997012/ | 20:42 |
| ondra | kyrofa not even sure how to configure this one through using /etc/network/interfaces.d/ | 20:43 |
| kyrofa | ondra, yeah fair enough, this is handy. Okay, thanks for the help! | 20:43 |
| ondra | kyrofa I did try network manager, but even with help of morphis I was not successful | 20:43 |
| ondra | kyrofa very welcome | 20:43 |
| kyrofa | ondra, enjoy holidays, and thanks for your time :) | 20:44 |
| ondra | kyrofa no worries :) | 20:44 |
| cory_fu | So, my previous question was due to user error, of course. :) However, I'm trying to use snapd on Travis and it's failing. Does anyone know if there's any way to make this work: https://travis-ci.org/juju-solutions/layer-cwr/builds/201647356 | 21:07 |
| kyrofa | cory_fu, no, snaps don't work on travis | 21:08 |
| cory_fu | :( | 21:09 |
| cory_fu | Is there any expectation that this could be resolved at some point? Or is it just not feasible due to how Travis runs builds? | 21:09 |
| kyrofa | What are you trying to do, exactly? | 21:10 |
| kyrofa | cory_fu, it's totally up to travis | 21:10 |
| kyrofa | cory_fu, their kernel, their OS | 21:10 |
| kyrofa | cory_fu, keep in mind that they JUST moved to ubuntu 14.04 | 21:10 |
| kyrofa | From 12.04 | 21:11 |
| kyrofa | And it's still beta, I thin | 21:11 |
| kyrofa | k | 21:11 |
| cory_fu | Yeah, that just makes it difficult to run our tests which depend on projects that have moved to snaps. This particular instance, charm-tools, has an apt package but it's broken at the moment. | 21:12 |
| kyrofa | cory_fu, yeah we're going to run into that soon as well. I wonder if elopio has some magic | 21:17 |
| kyrofa | He's the travis master | 21:17 |
| elopio | kyrofa: cory_fu: according to the table from zyga, travis should support snaps. | 21:22 |
| cory_fu | elopio: Table from zyga? | 21:23 |
| kyrofa | elopio, eh? Really? | 21:23 |
| elopio | cory_fu: https://github.com/snapcore/snapd/wiki/Distributions | 21:23 |
| cory_fu | elopio: I don't see Travis mentioned there? | 21:24 |
| kyrofa | elopio, where are you getting that? | 21:24 |
| elopio | from that error you are getting, I suppose they still need to enable something in apparmor. | 21:24 |
| kyrofa | Travis isn't even on there | 21:24 |
| EEight | on ubuntu 15.04 sudo apt install snapd = package not found! | 21:24 |
| nacc | EEight: 15.04 is eol | 21:24 |
| kyrofa | EEight, that's EOL I believe | 21:24 |
| elopio | kyrofa: cory_fu: no, but the kernel version required to support snaps in trusty. | 21:24 |
| EEight | But the doc: https://snapcraft.io/docs/core/install | 21:24 |
| kyrofa | elopio, ah, sure. But yeah, travis still needs to enable it | 21:25 |
| nacc | EEight: on ubuntu implies supported/current ubuntu of course | 21:25 |
| EEight | So Ubuntu 14.04 will work but not 15.04? | 21:25 |
| kyrofa | EEight, indeed as 14.04 is an LTS | 21:25 |
| EEight | Ok thx | 21:25 |
| cory_fu | elopio: Do you know what would need to be enabled? I could file an issue on Travis | 21:27 |
| ogra_ | kyrofa, ssh in and run sudo console-conf ... disable the wired device and configure the wlan ... | 21:27 |
| ogra_ | thats the most trivial approach | 21:27 |
| kyrofa | ogra_, haha! That's handy | 21:27 |
| elopio | cory_fu: well, the error says "Kernel needs AppArmor 2.4 compatibility patch." Please file the bug, and we can get zyga or jdstrand to comment there about the details. | 21:28 |
| elopio | cory_fu: this week I wanted to try running snaps on travis. Now that you have confirmed it fails, my plan b is to try a lxd container. | 21:30 |
| cory_fu | elopio: A LXD container on Travis? | 21:32 |
| elopio | cory_fu: yes. I tried that like a year ago and it kind-of-worked. But at that time, lxd didn't support snaps. | 21:32 |
| cory_fu | elopio: https://github.com/travis-ci/travis-ci/issues/7318 | 21:33 |
| cory_fu | elopio: Wouldn't that run in to the same kernel issue? | 21:34 |
| elopio | thanks cory_fu. | 21:34 |
| cory_fu | elopio: Also, I would expect it to hit https://github.com/juju/charm-tools/issues/303#issuecomment-279615158 at least for --classic snaps | 21:35 |
| elopio | I don't know how lxd works or what it does to support snaps. I thought it's worth a try, but now I don't have high hopes. | 21:35 |
| elopio | so many details failing everywhere... At least we are finding them, maybe try again next year :) | 21:37 |
| kyrofa | elopio, yeah, that'll certainly run into the same problem | 21:37 |
| cory_fu | elopio: https://bugs.launchpad.net/snappy/+bug/1628289/comments/18 | 21:39 |
| mup | Bug #1628289: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Triaged> <squashfuse (Ubuntu):Confirmed for doko> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289> | 21:39 |
| cory_fu | That's disheartening | 21:39 |
| elopio | cory_fu: well, but doesn't that mean that in trusty you get a xenial lxc and it will work? | 21:41 |
| cory_fu | I suppose so. | 21:41 |
| mup | Bug #1663060 changed: Add a title field to snap metadata <Developer registration portal:New> <Snappy:New> <gnome-software (Ubuntu):Confirmed> <snapcraft (Ubuntu):Confirmed> <snapd (Ubuntu):Triaged> <snapd-glib (Ubuntu):Confirmed> <https://launchpad.net/bugs/1663060> | 21:45 |
| EEight | When upload my snap on myapps.dev : You must wait 1 minute before the next snap-name registration for 16. ??? | 21:48 |
| EEight | After 10 mins, cannot do nothing (no option to click) | 21:48 |
| kyrofa | EEight, sounds like a question for nessita or noise][1 | 21:51 |
| EEight | kyrofa: my first app uploaded well on myapps.dev, but now I don't understand the error | 21:52 |
| kyrofa | EEight, there's rate limiting on registering new names so no one can go around registering the world. But it sounds like it's been a long time and you're still unable to register? | 21:52 |
| EEight | Ok, I see another unrelated error: You must register xxxx name for 16 before uploading, meaning that my filename (.snap) is not the same as the name I registered!? (will try) | 21:53 |
| EEight | That was it... | 21:54 |
| popey | EEight: are you all set? need help? | 21:54 |
| EEight | popey: thanks, just a feedback, it is not clear that you need to register a name exactly like the filename of your .snap is... | 21:55 |
| kyrofa | EEight, you don't, check the snap.yaml | 21:56 |
| popey | Interesting, I'll test that with a new app to follow the flow and report bugs where necessary. Thanks for the feedback | 21:56 |
| kyrofa | EEight, or the snapcraft.yaml. Are you sure the name is the same as the one you registered? | 21:57 |
| EEight | checking! | 21:58 |
| EEight | Ok I see, well of course the name in the snap is the same as the filename and then needs to be the same as registered in myapps. Cool | 22:02 |
| kyrofa | EEight, indeed, but the filename doesn't matter, the store checks the snap.yaml contained within the snap (which gets generated from the snapcraft.yaml) | 22:07 |
| EEight | popey: I am still not listed in Ubuntu Store under Games, is it because I need to add more info in snap.yaml or maybe because on myapps.dev I didn't select Default type: application? | 22:09 |
| EEight | Would like also to be listed under Games - Education that would be nice | 22:10 |
| EEight | Feedback, on Ubuntu 14.04 I can install snapd, then snap install myapp, but then I need to reboot (myapp: command not found, and not in the Application menu)? | 22:19 |
| popey | EEight: which app did you upload? | 22:20 |
| popey | EEight: feel free to give me the myapps url and I can take a look at it | 22:21 |
| popey | ok i see it | 22:21 |
| EEight | I just put the Default type: Application... not sure what it does | 22:22 |
| popey | what desktop are you using on 14.04? | 22:22 |
| EEight | both 14.04 & 16.04 | 22:22 |
| popey | ok and did the icon not show up in either right away? | 22:22 |
| popey | i have seen others report this, but not seen it myself recently | 22:23 |
| EEight | 2 problems : 1- not in Ubuntu Store; 2- need to reboot to use my app | 22:23 |
| popey | it's certainly published, because I just installed it with "snap install <appname>" | 22:23 |
| popey | you saying it doesnt show in ubuntu software, the graphical app? | 22:23 |
| kyrofa | Note that the reboot is because /snap/bin isn't in the path in the image, and only gets set once snapd is installed. But you already have an environment by then | 22:23 |
| EEight | popey: exactly the graphical app | 22:23 |
| kyrofa | popey, it's in the store, just not in the category, I think | 22:24 |
| popey | yeah | 22:24 |
| kyrofa | EEight, right? You can see it in the app, but not in the right category? | 22:24 |
| popey | yes, there is no category | 22:24 |
| popey | does that need setting in the store or the desktop file? | 22:24 |
| popey | Categories=Game;Simulation; | 22:25 |
| popey | for example in the .desktop file | 22:25 |
| EEight | kyrofa: in the graphical app (ubuntu software) not there at all, I need to search it (only in 16.04) | 22:25 |
| popey | EEight: just to confirm, on my 16.04 system, once installed I see the icon, so ou have done nothing wrong there. | 22:25 |
| kyrofa | Oh, that makes sense | 22:26 |
| EEight | popey: thx, on 14.04 also I see the icon in the Ubuntu menu (that is after rebooting if just installed snapd) | 22:26 |
| kyrofa | EEight, I don't think the software center in 14.04 will ever have that ability | 22:26 |
| EEight | kyrofa: ok | 22:26 |
| kyrofa | popey, don't you agree? | 22:27 |
| EEight | what about 16.04? | 22:27 |
| popey | correct | 22:27 |
| popey | 14.04 software centre has no snap support | 22:27 |
| EEight | my .desktop have Categories=game | 22:29 |
| EEight | maybe that is the problem? | 22:30 |
| EEight | case-sensitive! | 22:30 |
| popey | checked a steam game I have installed... | 22:32 |
| popey | Categories=Game; | 22:32 |
| popey | and it _does_ appear in the category "Games" in the store.. | 22:32 |
| EEight | thank you so much, do I need to bump my version? | 22:32 |
| popey | no, just fix and re-upload | 22:32 |
| EEight | excellent, thank you very much! | 22:32 |
| popey | and I checked, and one of my games is in the games category | 22:32 |
| popey | with the Category I mentioned above | 22:33 |
| popey | no problem, anytime | 22:33 |
| EEight | popey: do you know how to be in Games / Kids ? | 22:33 |
| EEight | ok got it KidsGame | 22:34 |
| popey | I expect there is a list of categories somewhere... lets see | 22:34 |
| EEight | found a post on stackoverflow | 22:34 |
| popey | https://standards.freedesktop.org/menu-spec/latest/apa.html | 22:35 |
| popey | looks like a likely candidate | 22:35 |
| EEight | Hey thanks better | 22:35 |
| === genii_ is now known as genii | ||
| === perrito667 is now known as perrito666 | ||
| === mup_ is now known as mup | ||
| === mterry_ is now known as mterry | ||
| === thibautr___ is now known as thibautr__ | ||
| === psivaa_ is now known as psivaa | ||
| === markusfluer1 is now known as markusfluer | ||
| === daker_ is now known as daker | ||
| === Trevinho_ is now known as Trevinho | ||
| popey | EEight: i just updated your app and note you've added Categories=KidsGame - but I don't see it in Ubuntu Software. I wonder if you need KidsGame;Game; ? | 22:49 |
| EEight | popey: Should I try? | 22:50 |
| popey | let me install someone elses game and see what they did | 22:50 |
| popey | one moment | 22:50 |
| EEight | sweet! I have to pay you a beer | 22:51 |
| popey | no worries :) | 22:51 |
| popey | Categories=Game;KidsGame; | 22:51 |
| popey | thats from raincat (whatever that is) | 22:52 |
| EEight | Excellent updating, and just like that flush 100mb from my Games (I need to be more careful with assets)! | 22:53 |
| EEight | All right done, let's see tomorrow (fingers crossed)! | 22:58 |
| popey | EEight: yay :) | 23:10 |
| mup | PR snapd#2853 opened: cmd: autoconf for RHEL <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2853> | 23:52 |
| mup | PR snapcraft#1130 closed: catkin plugin: produce build-ready staging area <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1130> | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!