| mup | PR snapcraft#1140 opened: catkin plugin: support building with an underlay <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1140> | 00:28 |
|---|---|---|
| === tgm4883_ is now known as tgm4883 | ||
| mup | PR snapd#2853 closed: cmd: autoconf for RHEL <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2853> | 00:58 |
| mup | PR snapd#2854 opened: Fix error message using GET /v2/users as non-root <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2854> | 01:11 |
| sparkin | hi | 01:47 |
| === markusfluer1 is now known as markusfluer | ||
| === durksauce_ is now known as durksauce | ||
| === petevg_ is now known as petevg | ||
| === arosales_ is now known as arosales | ||
| === andyrock_ is now known as andyrock | ||
| === victorbjelkholm_ is now known as victorbjelkholm | ||
| === nottrobin_ is now known as nottrobin | ||
| === ulkesh_ is now known as ulkesh | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#2854 closed: Fix error message using GET /v2/users as non-root <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2854> | 06:37 |
| mup | PR snapd#2855 opened: add intel realsense udev rules into camera interface <Created by swem> <https://github.com/snapcore/snapd/pull/2855> | 07:02 |
| mup | PR snapd#2840 closed: unity7: support missing signals and methods for status icons <Created by 3v1n0> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2840> | 07:09 |
| mup | PR snapd#2832 closed: interfaces/builtin: add network-setup-control which allows rw access to netplan <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2832> | 07:10 |
| mup | PR snapd#2856 opened: debian: add "Recommends: squashfuse" <Created by mvo5> <https://github.com/snapcore/snapd/pull/2856> | 07:20 |
| mup | PR snapd#2857 opened: Add /boot/uboot/config.txt read/write/lock support to core-support <Created by mvo5> <https://github.com/snapcore/snapd/pull/2857> | 07:58 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#2830 closed: allow core_support interface to modify /etc/default/swapfile <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2830> | 09:31 |
| mup | PR snapd#2858 opened: Add missing newline character to end of deprecated command warnings <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2858> | 09:31 |
| === caribou_ is now known as caribou | ||
| mup | PR snapd#2851 closed: tests: failover test for rc.local crash <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2851> | 10:22 |
| ogra_ | sergiusens_, hey ... | 10:29 |
| mup | PR snapd#2856 closed: debian: add "Recommends: squashfuse" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2856> | 11:06 |
| === chihchun is now known as chihchun_afk | ||
| === sergiusens_ is now known as sergiusens | ||
| sergiusens | ogra_: hey | 11:36 |
| mup | PR snapd#2859 opened: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Created by pedronis> <https://github.com/snapcore/snapd/pull/2859> | 12:04 |
| mup | PR snapd#2859 closed: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2859> | 12:05 |
| mup | PR snapd#2860 opened: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2860> | 12:06 |
| ogra_ | sergiusens, i'm struggling with an old problem ... | 12:15 |
| ogra_ | sergiusens, namely with bug #1611439 | 12:16 |
| mup | Bug #1611439: snapcraft should be able to autofill the version field based on some property of the build and/or stage files. <Snapcraft:Won't Fix> <https://launchpad.net/bugs/1611439> | 12:16 |
| ogra_ | sergiusens, we need to somehow start using the snapd version string in the core snap version field | 12:17 |
| ogra_ | i tried sed'ing snapcraft.yaml during build on LP but that doesnt work, same goes for putting my own meta/snap.yaml in place ... would it be possible to allow the latter ? | 12:18 |
| mup | PR snapd#2859 opened: [WIP] overlord: switching to explicit targets for enabled/auto aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2859> | 12:18 |
| ogra_ | or simply have snapcraft read an env var that gets set during the build and use that for the version ? | 12:18 |
| ogra_ | SNAPCRAFT_VERSION_OVERRIDE ... or some such ... | 12:18 |
| ogra_ | iirc the snap.yaml is generated, so it should be possible to inject something there i think | 12:19 |
| ogra_ | sadly i cant manage that from the outside of the build, since the person building is free to use any PPA for the core builds ... which means i dont actually know what the final snapd version will be (and it is used that way by a few teams) | 12:20 |
| ogra_ | and indeed launchpad doesnt allow me to do the build in steps either so that i could skip prime | 12:20 |
| mup | PR snapd#2570 closed: snap: add contact: line in `snap info` <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2570> | 12:22 |
| mup | PR snapd#2861 opened: [WIP] interface hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2861> | 12:27 |
| pstolowski | mardy, hey, the next PR for interface hooks ^ in case you want to keep an eye on it. not yet fully ready for review, but close | 12:31 |
| mardy | pstolowski: thanks! | 12:32 |
| pstolowski | alecu, ^ | 12:33 |
| alecu | pstolowski: amazing! | 12:40 |
| === chihchun_afk is now known as chihchun | ||
| === coreycb` is now known as coreycb | ||
| mup | PR snapd#2791 closed: store: use xdelta3 from core if available and not on the regular system <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2791> | 12:52 |
| sergiusens | ogra_: you can go all the way to `snapcraft prime` and them replace `prime/meta/snap.yaml` or sed it and then `snapcraft snap prime` | 12:52 |
| ogra_ | sergiusens, how ... i'm building on launchpad | 12:53 |
| sergiusens | ogra_: I don't mind doing this over envvars though and not promote it `SNAPCRAFT_PROJECT_VERSION=2.21 snapcraft` | 12:53 |
| sergiusens | ogra_: but how will you get launchpad to use it? | 12:54 |
| ogra_ | sergiusens, hmm, but i dont know the version before i call snapcraft | 12:54 |
| sergiusens | ogra_: is this related to my comment on version on the list? | 12:54 |
| ogra_ | yeah, kind of | 12:54 |
| ogra_ | we discussed it in the standup and the outcopme was that version: should be the snapd version inside the core snap | 12:54 |
| ogra_ | so we can tie features to stable snapd versions in the docs | 12:55 |
| mup | PR snapd#2862 opened: cmd/snap, store: change error messages to reflect latest UX doc <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2862> | 12:55 |
| sergiusens | ogra_: I don't know how to solve this from a snapcraft PoV, we are peeling an onion to get the version, then putting the layers back on top and applying that to the meta data | 12:55 |
| sergiusens | ogra_: wouldn't it be better to have a special feature for this on launchpad? | 12:55 |
| ogra_ | sergiusens, well, you could check for a pre-existing snap.yaml and in that case not generate one | 12:56 |
| sergiusens | ogra_: if you are going to go throught the trouble of creating a snap.yaml why not just set the version? | 12:56 |
| ogra_ | sergiusens, how ? the version is already seeded when snapcraft reads snapcraft.yaml at the beginning of the build | 12:57 |
| sergiusens | ogra_: ok, I see. so I can compromise on "existence of file in project root .snapcraft_project_version" | 12:57 |
| ogra_ | sergiusens, i only know the version i need later ... during the build | 12:57 |
| ogra_ | sergiusens, sonmething like this http://paste.ubuntu.com/24000747/ (indeed i made up yaml.read() there) | 12:58 |
| ogra_ | that way i could just copy a snap.yaml in place during the build or generate it from the makefile | 12:59 |
| === alan_g is now known as alan_g|lunch | ||
| sergiusens | ogra_: had a crash and we aren't chatting on rocket, will need to repeat from what last I said ;-) | 13:04 |
| ogra_ | sergiusens, but i'd be fine with .snapcraft_project_version as well indeed ... if you prefer that | 13:04 |
| ogra_ | <ogra_> sergiusens, i only know the version i need later ... during the build | 13:05 |
| ogra_ | <ogra_> sergiusens, sonmething like this http://paste.ubuntu.com/24000747/ (indeed i made up yaml.read() there) | 13:05 |
| ogra_ | <ogra_> that way i could just copy a snap.yaml in place during the build or generate it from the makefile | 13:05 |
| ogra_ | but as i said, .snapcraft_project_version would indeed work as well for my case | 13:05 |
| ogra_ | as long as prime reads it :) | 13:05 |
| sergiusens | ogra_: I'd rather not go the route and just overload the version | 13:06 |
| ogra_ | fine with me then | 13:06 |
| ogra_ | sergiusens, should i re-open the old bug ? | 13:09 |
| ogra_ | (i am on rocket btw, we can move there if that helps) | 13:09 |
| Son_Goku | sergiusens: yo | 13:16 |
| Son_Goku | how's it going? | 13:16 |
| sergiusens | ogra_: read topic ;-) | 13:18 |
| * sergiusens finally has a reason to say that | 13:18 | |
| Son_Goku | phooey | 13:18 |
| Son_Goku | snapcraft discussion isn't on IRC anymore? :( | 13:18 |
| ogra_ | well, like snapd development hasnt been on IRC in a long time | 13:19 |
| Son_Goku | that's even worse | 13:19 |
| sergiusens | Son_Goku: good good | 13:19 |
| Son_Goku | sergiusens: :) | 13:19 |
| sergiusens | Son_Goku: you? | 13:23 |
| Son_Goku | sergiusens: I'm okay these days | 13:23 |
| Son_Goku | life stuff making things annoying, as always :) | 13:24 |
| sergiusens_ | Son_Goku: great, I'll be working on repo stuff tomorrow or even this evening if time allows for it btw, will ping you for a review (probably straight on github) | 13:25 |
| Son_Goku | awesome | 13:25 |
| Son_Goku | looking forward to it | 13:25 |
| === alan_g|lunch is now known as alan_g | ||
| caiortp | Hi folks! I'm embedded developer and I have some question about the snappy | 13:48 |
| caiortp | I saw that it's possible to create a private snappy store... | 13:49 |
| caiortp | There's some tool (like resin.io / openstack ) to manage the snappys instances installed in each board? | 13:51 |
| caiortp | tks | 13:51 |
| caiortp | ;) | 13:51 |
| tommy_ | hello | 14:46 |
| === tommy_ is now known as Guest12115 | ||
| Guest12115 | do you know if it is possible to install snapd on a Wheezy Debian ? | 14:47 |
| === matteo` is now known as matteo | ||
| === matteo is now known as Guest52378 | ||
| ogra_ | Guest12115, https://github.com/snapcore/snapd/wiki/Distributions | 14:48 |
| Guest12115 | i did it but it doesnt work | 14:48 |
| Guest12115 | it cant recognize snapd | 14:48 |
| Guest12115 | do you know the source ? | 14:49 |
| ogra_ | what do you mean by "recognize" ? | 14:49 |
| Guest12115 | paquet not found | 14:49 |
| ogra_ | ah, right, wheezy is 7.0 ... afaik snapd only works in testing and unstable | 14:50 |
| ogra_ | and there is is the the archive | 14:51 |
| ogra_ | i doubt you can make it run on anything older | 14:52 |
| Guest12115 | humm ok | 14:58 |
| Guest12115 | thanks | 14:58 |
| Guest12115 | have a nice day | 14:59 |
| Guest12115 | i will dig a little | 14:59 |
| niemeyer | jdstrand: ping | 15:20 |
| mup | PR snapd#2863 opened: cmd/snap-confine: ensure that hotfs is root owned <Created by zyga> <https://github.com/snapcore/snapd/pull/2863> | 15:24 |
| mup | PR snapd#2858 closed: Add missing newline character to end of deprecated command warnings <Created by robert-ancell> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2858> | 15:25 |
| jdstrand | niemeyer: hey | 15:27 |
| niemeyer | jdstrand: Heya | 15:28 |
| niemeyer | jdstrand: Do you have a moment to meet with pedronis and myself? | 15:28 |
| jdstrand | niemeyer: actually, not atm. I have an appt in a few minutes. I can do it in ~3.5 hours | 15:28 |
| niemeyer | That sounds late for pedronis | 15:29 |
| pedronis | it's doable but slightly late | 15:29 |
| jdstrand | first thing tomorrow would be fine with me | 15:29 |
| niemeyer | Ok, let's do it tomorrow then | 15:29 |
| jdstrand | whichever you decide is fine with me | 15:29 |
| jdstrand | ok | 15:29 |
| jdstrand | my morning is open, so ping me at 14:00 or later when you want to meet | 15:30 |
| jdstrand | 14:00 UTC | 15:30 |
| ahayzen | didrocks, hey, to be able to properly test my change to the desktop-helpers, is there a way i can tell snapcraft to use a local version of the part rather than the cloud version? | 15:33 |
| didrocks | ahayzen: sure, you can cp the part from snapcraft.yaml you are interested in | 15:34 |
| didrocks | and change source: | 15:34 |
| ahayzen | didrocks, ah i see thanks :-) | 15:35 |
| didrocks | ahayzen: yw! easiest way to test AFAIK :) | 15:35 |
| flexiondotorg | ogra_ We discussed snapd-xdg-open the other day. | 15:42 |
| flexiondotorg | I have concerns. | 15:42 |
| ogra_ | tell me | 15:42 |
| flexiondotorg | We talked about it need SRU to Trusty, which "fixes" a problem for Ubuntu. | 15:42 |
| flexiondotorg | But snapd-xdg-open isn't in Debian 9, or other distros. | 15:42 |
| flexiondotorg | Meaning the cross-distro story is broken. | 15:43 |
| flexiondotorg | Particular for snaps such as Spotify and Skype for Linux Alpha. | 15:43 |
| ogra_ | flexiondotorg, well, talk to the snapd team, perhaps we can include it in the snapd package itself | 15:44 |
| flexiondotorg | niemeyer It that possible? ^ | 15:44 |
| flexiondotorg | ogra_ Thanks. | 15:44 |
| flexiondotorg | jdstrand Your thoughts on the above? | 15:45 |
| ogra_ | thats the only idea i have beyond ... well ... pushing it into the other distros as well | 15:45 |
| flexiondotorg | Would need switch action for Debian 9. | 15:45 |
| flexiondotorg | mvo Is that still a possibility at this late stage? | 15:46 |
| niemeyer | flexiondotorg, ogra_: We have better plans for that | 15:46 |
| jdstrand | flexiondotorg: I agree it would have to be part of snapd | 15:46 |
| flexiondotorg | That is reassuring. | 15:46 |
| ogra_ | after all the package only contains a single binary and a dbus service file | 15:46 |
| * jdstrand hasn't heard the better plans | 15:46 | |
| flexiondotorg | niemeyer Is there a bug to track those plans? | 15:47 |
| niemeyer | jdstrand: You probably have, but it wasn't super high profile | 15:47 |
| niemeyer | flexiondotorg: Probably, can't remember as we haven't touched that conversation in a few weeks | 15:47 |
| * jdstrand -> appt | 15:48 | |
| niemeyer | flexiondotorg: The idea is simple: instead of using dbus, we'll use snapctl | 15:48 |
| flexiondotorg | niemeyer Thanks. | 15:48 |
| flexiondotorg | OK, I'll go hunting. If I don't turn up an existing bug I'll raise a new one. | 15:48 |
| ogra_ | after all you only want to forward a url to xdg-open ... | 15:49 |
| * ogra_ thinks there already way to much plumbing around it today, an overhaul will be healthy | 15:50 | |
| niemeyer | ogra_: I don't think we're even using the real xdg-open today | 15:50 |
| niemeyer | It just looks like it | 15:51 |
| ogra_ | well, the final call goes to xdg-open (at least it should) | 15:51 |
| ogra_ | because that knows what to do with specific urls | 15:51 |
| niemeyer | I don't think it does, and I don't think it necessarily should either | 15:51 |
| ogra_ | well, it needs to use the mimetypes to identify the right app to fire up for a certain handler | 15:51 |
| ogra_ | you dont want to duplicated this on our side | 15:52 |
| ogra_ | but i have never looked at the code of snapd-xdg-open so you ar probably right :) | 15:52 |
| niemeyer | Yeah, it doesn't really.. it uses g_app_info_launch_default_for_uri | 15:52 |
| niemeyer | ogra_: We're not duplicating code.. and we're chosing *which code* we're not duplicating. ;) | 15:53 |
| ogra_ | heh | 15:53 |
| niemeyer | s/heh/Good idea Gustavo!/ | 15:54 |
| ogra_ | oh, it just uses glib, i see | 15:54 |
| * ogra_ just looked at the code for the first time | 15:54 | |
| niemeyer | Either way, this is the status quo | 15:54 |
| ogra_ | yeah | 15:54 |
| niemeyer | We most probably won't be using glib in the new implementation because we don't want more dependencies | 15:54 |
| ogra_ | yeah | 15:55 |
| niemeyer | (it will be inside snapd itself) | 15:55 |
| niemeyer | I'd rather not use the mess of xdg-open.. but we'll see | 15:55 |
| ogra_ | i'd just let xdg-open do its job and hand over the url from snapd | 15:55 |
| ogra_ | simply because then it isnt our job to take care after the handoff | 15:55 |
| ogra_ | heh, now i scared seb | 15:56 |
| niemeyer | We'll not implement tool-picking ourselves for sure.. but I'd prefer something cleaner if it exists | 15:56 |
| niemeyer | We'll see | 15:56 |
| * ogra_ would love if we could get rid of the ugly bits in the core snap ... more than caring about the handoff actually | 15:57 | |
| Cynerva_ | any advice or best practices for passing args to a daemon that needs them? | 15:59 |
| Cynerva_ | right now we're using a single "args" config, e.g. `snap set kube-apiserver args='--etcd-servers 10.123.123.14'` | 15:59 |
| ogra_ | i'd use a wrapper script ... | 16:00 |
| Cynerva_ | and a wrapper script that passes them into the daemon | 16:00 |
| ogra_ | yeah, that sounds like an okayish approach | 16:00 |
| Cynerva_ | okay, cool :) do you think it'd be better for us to break up the config? | 16:02 |
| ogra_ | well, snap set doesnt really tell your config hook which the arg was, so in the end you will re-generate the whole config anyway | 16:03 |
| ogra_ | s/arg/key/ actually | 16:04 |
| Cynerva_ | ah sorry, i mean more from an usability perspective, i guess | 16:07 |
| Cynerva_ | like instead of "args", we could have configs for "etcd-servers", "kubeconfig", etc -- all the flags that our daemon takes | 16:07 |
| ogra_ | yeah, i'd do that long term | 16:07 |
| ogra_ | and split it into categories so you can "yaml'ify" it later | 16:08 |
| Cynerva_ | okay great. Thanks ogra_! | 16:09 |
| ogra_ | :) | 16:09 |
| niemeyer | jdstrand: Comment fixed and improved: https://github.com/snapcore/snapd/pull/2604#issuecomment-280045941 | 16:11 |
| mup | PR snapd#2604: interfaces: add classic-support interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2604> | 16:11 |
| mup | PR snapd#2864 opened: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/2864> | 16:12 |
| mup | PR snapd#2604 closed: interfaces: add classic-support interface <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2604> | 16:13 |
| mup | PR snapd#2865 opened: image,cmd/snap: refactoring and initial envvar support to use stores needing auth <Created by pedronis> <https://github.com/snapcore/snapd/pull/2865> | 16:21 |
| mup | Bug #1665029 opened: snapweb needs a link for device when store selected <Snappy:New> <https://launchpad.net/bugs/1665029> | 16:46 |
| EEight | popey: bad news for me, my game is still not listed in Ubuntu Software. It is listed if installed via snap install, but it is not the idea, I want to have exposure from the store. | 16:46 |
| === JanC_ is now known as JanC | ||
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#2852 closed: cmd/libsnap: add privilege elevation helpers <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2852> | 17:16 |
| kyrofa | Hey barry, what is the recommended way to use ubuntu-image? From the snap, or from the deb? | 17:21 |
| ogra_ | kyrofa, from the deb it depends on your host machine (for xenial you need the PPA with a newer ext4 lib) ... i'D go for the snasp from edge | 17:26 |
| ogra_ | *snap | 17:27 |
| ogra_ | *for the deb | 17:27 |
| kyrofa | Ah, good to know, thanks ogra_ | 17:27 |
| elopio | jdstrand: zyga is asking for you in rocket chat. | 17:29 |
| elopio | he has "technical reasons" :) | 17:29 |
| alex-abreu | kyrofa, ping | 17:35 |
| kyrofa | alex-abreu, hey there! In standup right now but I'll be available in a minute. What's up? | 17:35 |
| alex-abreu | kyrofa, np I can wait, just a few questions around configure hooks ... the usual | 17:36 |
| alex-abreu | kyrofa, when a snap is getting installed, the configure hook is run before any daemon that the snap could host is started? | 17:40 |
| kyrofa | alex-abreu, no, the configure hook is run _after_ the daemons are fired up | 17:43 |
| kyrofa | alex-abreu, it's why bug #1661126 was logged | 17:46 |
| mup | Bug #1661126: Add One-shot Install/Uninstall Hook <feature> <hook> <install> <request> <snapd:Confirmed> <https://launchpad.net/bugs/1661126> | 17:46 |
| alex-abreu | kyrofa, yes ! ... so in general is there an easy mechanism to e.g. do a systemctl reload when a snap configuration is updated or infor the snap of a conf change? | 17:52 |
| alex-abreu | kyrofa, thx for the bug # ... | 17:52 |
| barry | kyrofa: really, it's entirely up to you. consume it how you like. :) one thing to keep in mind is that the snap version (currently) has some minor limitations, e.g. you can't put your model or extra snaps in /tmp and you can't output your images to /tmp. other than that there shouldn't be much visible difference | 18:08 |
| kyrofa | alex-abreu, the method I use personally is to set the daemons up to restart always | 18:10 |
| kyrofa | alex-abreu, and then my scripts just kill the services in question (since systemctl is off limits) | 18:10 |
| kyrofa | alex-abreu, then systemd brings them back u | 18:10 |
| kyrofa | p | 18:10 |
| kyrofa | barry, ah, good to know, thank you | 18:12 |
| alex-abreu | kyrofa, this crossed my mind but sounded too "scary", ... :) | 18:12 |
| alex-abreu | kyrofa, do you have a snap example for that? | 18:12 |
| kyrofa | alex-abreu, definitely | 18:12 |
| kyrofa | alex-abreu, remember though that every daemon is different. This is for apache, which has a script that wraps it and utilizes a pid file, so I could just ask it to stop: https://github.com/nextcloud/nextcloud-snap/blob/master/src/https/utilities/https-utilities#L138 | 18:13 |
| kyrofa | alex-abreu, but that could just as easily have been a kill -15 | 18:14 |
| mup | PR snapd#2866 opened: cmd/libsnap: add helper for dropping permissions <Created by zyga> <https://github.com/snapcore/snapd/pull/2866> | 18:17 |
| alex-abreu | kyrofa, totally, thx | 18:19 |
| kyrofa | alex-abreu, I find it actually works pretty well. It would be pretty awesome if we could call systemctl for in-snap daemons though | 18:24 |
| alex-abreu | kyrofa, definitely ... is there a bug # for that? or a strong not to be able to ? | 18:24 |
| kyrofa | alex-abreu, I suspect there are technical issues with that, but jdstrand could answer better. Or morphis, I think he ran into it recently | 18:25 |
| kyrofa | By the way, jdstrand did you see my responses to https://github.com/snapcore/snapd/pull/2837 ? | 18:27 |
| mup | PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837> | 18:27 |
| kyrofa | alex-abreu, to answer your question, I don't know of a bug for that | 18:31 |
| mup | PR snapd#2859 closed: [WIP] overlord: switching to explicit targets for enabled/auto aliases <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2859> | 18:40 |
| mup | PR snapd#2860 closed: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2860> | 18:40 |
| mup | PR snapcraft#1141 opened: Use the existing code to find origin's snapcraft.yaml <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1141> | 18:42 |
| kyrofa | pmcgowan, you pinged me a while back about nextcloud not working on the dragon board. I'm sorry it took so long, but I finally got around to testing this myself, and at least the latest revision works fine. Have you tried recently? | 18:44 |
| pmcgowan | kyrofa, I haven't tried lately, I recall it was just a memory usage issue | 18:45 |
| kyrofa | pmcgowan, yeah I wouldn't be surprised | 18:45 |
| pmcgowan | kyrofa, did you run from stable or other channel | 18:46 |
| kyrofa | pmcgowan, stable, yeah. I think some efficiency gains landed in nextcloud v11 | 18:47 |
| pmcgowan | ok will give it a try | 18:48 |
| === jdstrand_ is now known as jdstrand | ||
| kyrofa | pmcgowan, no rush, I just have the dragon up now so I can experiment if you run into issues | 18:49 |
| jdstrand | kyrofa: re https://github.com/snapcore/snapd/pull/2837, but haven't had a chance to circle back yet. hopefully today | 18:53 |
| mup | PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837> | 18:53 |
| mariogrip | jdstrand: Hi, I pushed a snap to the store, but it seem to be stuck on "Revision waiting for review of a previous upload." even though the review of the previous upload is done | 18:53 |
| kyrofa | jdstrand, of course, no problem | 18:54 |
| pmcgowan | hmm kyrofa interesting you cannot refresh a disabled snap | 18:57 |
| kyrofa | pmcgowan, ah, I never tried. But that kinda makes sense... it's disabled | 18:57 |
| jdstrand | mariogrip: what is the link? | 18:57 |
| pmcgowan | kinda, but thats cause it doesnt run correctly | 18:57 |
| kyrofa | pmcgowan, hahaha | 18:57 |
| kyrofa | pmcgowan, good point | 18:57 |
| mariogrip | jdstrand: https://myapps.developer.ubuntu.com/dev/click-apps/6986/ | 18:58 |
| pmcgowan | kyrofa, so I would remove and install instead | 18:58 |
| kyrofa | pmcgowan, or enable and refresh | 18:58 |
| pmcgowan | yeah, but then it sucks up my memory and my other snaps dont work :) | 18:58 |
| kyrofa | Yeah, remove/install might be a better path | 18:59 |
| kyrofa | pmcgowan, that might explain why it's working alright here-- I don't have any other snaps installed | 18:59 |
| jdstrand | mariogrip: I'm not sure how it got to that state... can you request a manual review and then I can reject it and the next one will get reviewed | 18:59 |
| pmcgowan | kyrofa, reminds me of a recent thread on not having snaps start right after install | 18:59 |
| mariogrip | jdstrand: It might be because i uploaded a new one before the review was done | 18:59 |
| mariogrip | jdstrand: but could you reject rev2 so it uses 3rev insted | 19:00 |
| mariogrip | jdstrand: manual review requested | 19:02 |
| jdstrand | nessita: fyi, https://myapps.developer.ubuntu.com/dev/click-apps/6986/rev/2/ seems stuck in 'Task state is unknown.' | 19:04 |
| jdstrand | nessita: mariogrip requested that it be rejected so rev3 may be auto-reviewed | 19:04 |
| nessita | jdstrand, hi, let me check | 19:04 |
| nessita | jdstrand, can you reload? | 19:05 |
| nessita | I see it failed | 19:05 |
| mariogrip | jdstrand: it says "Manual review pending" for me | 19:05 |
| jdstrand | nessita: ok, it isn't stuck. it took quite a while to get there. sorry for the noise | 19:06 |
| nessita | :-) | 19:06 |
| jdstrand | mariogrip: ok, rev2 rejected | 19:06 |
| mariogrip | jdstrand: Thanks :) | 19:06 |
| mup | PR snapd#2867 opened: screen-inhibit-control: add methods for delaying screensavers <Created by 3v1n0> <https://github.com/snapcore/snapd/pull/2867> | 19:22 |
| jdstrand | alex-abreu: we can't call systemctl from snaps without patching systemd. systemd isn't diesigned to be isolated and the snap requires a ton of privileges | 19:25 |
| jdstrand | systemctl isn't designed to isolate calls to applications that is | 19:26 |
| jdstrand | it could be made to do so. better would be to update snapctl so snapd could call ystemctl on the snap's behalf | 19:26 |
| alex-abreu | jdstrand, thx for the update, ... makes sense yes, something like a systemctl facility or expanding systctl could be very handy | 19:27 |
| alex-abreu | snapsctl I mean | 19:27 |
| kyrofa | jdstrand, agreed, we've tried to isolate snapd and snapd from knowing they're running on systemd anyway | 19:27 |
| kyrofa | snapd and snaps* | 19:27 |
| * jdstrand nods | 19:27 | |
| kyrofa | So snapctl seems the best solution | 19:27 |
| jdstrand | yeah | 19:28 |
| kyrofa | jdstrand, from a technical standpoint though, can apparmor not parse cli args to a binary? | 19:28 |
| lutostag | any ideas what I'm hitting with https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1665102 ? | 19:45 |
| mup | Bug #1665102: Snap refresh not working <snapd (Ubuntu):New> <https://launchpad.net/bugs/1665102> | 19:45 |
| sethj | wasn't there a bug report about being required to sign in to install a snap? | 19:59 |
| EEight | i poked popey directly, but if anyone knows about exposing a snap application in the ubuntu software (16.04 only) let me know, my app is not listed. | 20:13 |
| EEight | I think that only .debs will be listed there? Am I wrong? | 20:13 |
| nacc | isn't ubuntu software centre deprecated? gnome software seems to find sanps | 20:15 |
| nacc | EEight: what's your snap called? | 20:15 |
| kyrofa | EEight, I'm still not completely clear: does your snap not show up at ALL in xenial's software center, or just not in the correct categories? | 20:15 |
| kyrofa | nacc, I assume that's what EEight means | 20:15 |
| nacc | kyrofa: i always have to double-check in #ubuntu :) | 20:15 |
| kyrofa | nacc, fair enough! | 20:16 |
| EEight | nacc: bayam | 20:16 |
| nacc | EEight: is it french? | 20:16 |
| EEight | should be in Games / Kids | 20:16 |
| EEight | bilangual | 20:17 |
| nacc | my gnome software found a bayam snap | 20:17 |
| nacc | (on 16.10) | 20:17 |
| kyrofa | EEight, indeed, same here (on xenial) | 20:17 |
| EEight | yes, but I don't want people to search for it, I want the exposition of the categories | 20:17 |
| kyrofa | EEight, then you need to be clear with your problem! | 20:17 |
| EEight | my bad! | 20:18 |
| kyrofa | EEight, you said "my app is not listed [in ubuntu software]" which isn't the case | 20:18 |
| nacc | note that i don't see bayam under games/all eitehr | 20:18 |
| EEight | what is the process behind this, is there real people reviewing the snap submission? | 20:19 |
| kyrofa | EEight, not unless your snap requires manual review | 20:20 |
| kyrofa | EEight, I expect this is a limitation right now, of either the store or snapd | 20:20 |
| kyrofa | (or both) | 20:20 |
| kyrofa | EEight, I suggest logging a bug | 20:20 |
| nacc | yeah, it seems like snaps don't hav ea "Category" field set (visibly at least) | 20:20 |
| kyrofa | nacc, they kinda do, on the store side | 20:21 |
| kyrofa | nacc, but I don't think anything consumes that | 20:21 |
| nacc | kyrofa: right, i meant on the client side, sorry | 20:21 |
| nacc | kyrofa: whereas debs do show one visibly | 20:21 |
| kyrofa | nacc, indeed | 20:21 |
| nacc | yeah, seems like just an oversight (I assume the field would have to be found somewhat differently between debs and snaps) | 20:21 |
| kyrofa | Agreed | 20:22 |
| kyrofa | EEight, specifically, I suggest logging a bug against gnome software, since that's where the issue is surfacing. It'll get triaged and also-applied from there: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+filebug | 20:23 |
| kyrofa | EEight, again, be specific. Say that your snap shows up, but not in the categories you've requested | 20:23 |
| EEight | but the category from the .desktop file or from the myapps.developer.ubuntu ? | 20:24 |
| kyrofa | EEight, good question. I expect from myapps, since the desktop file is hidden away in the snap at that poit | 20:24 |
| kyrofa | point* | 20:24 |
| EEight | Then the myapps. should be updated to reflect all the categories... | 20:24 |
| kyrofa | EEight, heh, one problem at a time | 20:25 |
| kyrofa | EEight, plus I'm not certain that's the case, anyway | 20:25 |
| EEight | Well the myapps.dev website is in french here (cannot change the language). The field html name is department_id... and it should have a category (Games) and a sub-category (Kids). But like you said, one thing at a time. | 20:29 |
| EEight | Did my best: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1665126 | 20:39 |
| mup | Bug #1665126: snap not listed in categories <snap> <gnome-software (Ubuntu):New> <https://launchpad.net/bugs/1665126> | 20:39 |
| kyrofa | EEight, looks great, thank you. I tweaked the description ever so slightly, but nice job | 20:49 |
| === cjwatson_ is now known as cjwatson | ||
| cjwatson | elopio: yeah, I need to finish fixing yakkety/zesty snap builds on LP | 21:40 |
| cjwatson | I see you ran headfirst into that | 21:41 |
| mup | PR snapcraft#1142 opened: Asset Tracking - Store versions of stage-packages <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1142> | 21:48 |
| mwhudson_ | hm | 23:14 |
| mwhudson_ | ogra_: around? | 23:14 |
| mwhudson_ | running /var/lib/classic/enable.sh in an unpacked core snap makes snapd think it's a classic system | 23:14 |
| mwhudson_ | which is a pain | 23:15 |
| mwhudson_ | oh it's because it overwrites lsb-release i think | 23:20 |
| kyrofa | mwhudson_, classic mode needs to act like classic ubuntu (regarding lsb-release) or various tools break | 23:21 |
| === Guest52378 is now known as matteo | ||
| mwhudson_ | ah hm | 23:21 |
| mwhudson_ | what i am actually trying to do is make a core snap with an upgraded console-conf in it | 23:21 |
| kyrofa | mwhudson_, snapcraft, catkin, etc. | 23:22 |
| kyrofa | Ah | 23:22 |
| mwhudson_ | maybe there is a better way to do this these days | 23:22 |
| mwhudson_ | i guess i can just build my own core snap from scratch but ehh | 23:22 |
| mwhudson_ | actually i think i can just unpack the new debs | 23:23 |
| mwhudson_ | in this case | 23:24 |
| mwhudson_ | but that won't work in full generality | 23:24 |
| mup | PR snapd#2868 opened: Don't return null result for async responses <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2868> | 23:31 |
| ogra_ | mwhudson_, why the heck would you ever run that script ? | 23:42 |
| ogra_ | mwhudson_, that script is the backend for the classic snap ... | 23:42 |
| ogra_ | nothing you should run by hand :) | 23:42 |
| === mwhudson_ is now known as mwhudson | ||
| === mwhudson is now known as Guest32650 | ||
| ogra_ | snap install --devmode --edge classic; sudo classic .... | 23:43 |
| Guest32650 | bah | 23:43 |
| ogra_ | then you use the script the right way | 23:43 |
| mwhudson_ | ogra_: ok | 23:45 |
| ogra_ | mwhudson_, to change the core snap itself, you should use unsquash it ... unpack your deb in the squashfs-root dir that created and then snapcraft snap squashfs-root ... then you can sideload it | 23:45 |
| mwhudson_ | ogra_: yeah, that's what i did | 23:45 |
| ogra_ | but do that on a PC ... | 23:46 |
| mwhudson_ | i guess it hardly matters that the dpkg database is wrong... | 23:46 |
| mwhudson_ | ogra_: no fear, i am not in the "snappy == iot" brigade :-) | 23:46 |
| ogra_ | the dpkg database is gone | 23:46 |
| ogra_ | we rip it out :) | 23:47 |
| === mwhudson_ is now known as mwhudson | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!