| blackboxsw | hi folks, I've just started seeing failures based on the systemd triggered auto-update of installed snaps | 01:50 |
|---|---|---|
| blackboxsw | cannot refresh snap-declaration for "<mysnap>": Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/<myid>: dial tcp: lookup assertions.ubuntu.com on 127.0.1.1:53: server misbehaving | 01:52 |
| blackboxsw | have we changed something with the snap store recently that could cause some of the snap auto-refresh services to fall over? | 01:52 |
| mup | PR snapd#2166 opened: snap: stop using ubuntu-core-launcher, use snap-confine <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2166> | 03:46 |
| mup | PR snapd#2163 closed: debian: update dependency of ubuntu-core-launcher to snap-confine <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2163> | 03:47 |
| dr1337 | hey guys, anyone know where the snappy builder repos are being pulled from? | 03:57 |
| dr1337 | like this one ? https://github.com/alexgg/ccimx6sbc-snappy | 03:57 |
| qengho | blackboxsw: No idea, without looking in source code. | 04:08 |
| blackboxsw | qengho, no worries, it seems intermittent | 04:13 |
| blackboxsw | I've seen many clients already update our snap via the auto-refresh mechanism. | 04:13 |
| blackboxsw | so I don't know if it was a temporary 404 of some content during a rollout | 04:13 |
| dr1337 | Does anybody know what SNAP_CONTEXT environmental variable is for? | 04:24 |
| === pbek_ is now known as pbek | ||
| qengho | https://github.com/snapcore/snapd/search?utf8=%E2%9C%93&q=SNAP_CONTEXT | 04:46 |
| mup | PR snapd#2165 closed: snap: stop using ubuntu-core-launcher, use snap-confine <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2165> | 05:15 |
| mup | PR snapd#2166 closed: snap: stop using ubuntu-core-launcher, use snap-confine <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2166> | 05:15 |
| zyga | jdstrand: https://github.com/snapcore/snap-confine/pull/172/files | 05:23 |
| mup | PR snap-confine#172: Improve decoding of mount flags <Created by zyga> <https://github.com/snapcore/snap-confine/pull/172> | 05:23 |
| zyga | jdstrand: https://github.com/snapcore/snap-confine/pull/172/files | 05:24 |
| zyga | oh, sorry | 05:24 |
| jdstrand | zyga: heh, nice :) | 05:29 |
| jdstrand | I'm not going to review it right this second as I want to be more awake for the review, but added to my list | 05:30 |
| dr1337 | qengho: thanks | 05:35 |
| mup | Bug #1621525 changed: classic environment variables for daemon snaps <Snappy:Fix Released> <https://launchpad.net/bugs/1621525> | 05:45 |
| ogra_ | cjwatson, did some LP branch land last night or did the store change .... ? | 06:33 |
| ogra_ | Launchpad uploaded this snap package to the store, but the store failed to | 06:33 |
| ogra_ | scan it: | 06:33 |
| ogra_ | __all__: The upload does not appear to be a valid package. | 06:33 |
| ogra_ | https://launchpad.net/~snappy-dev/+snap/core/+build/7240 | 06:33 |
| ogra_ | gotthat for all core and ubuntu-core builds tonight ... | 06:33 |
| cjwatson | ogra_: src/devportal/clickapp_forms.py: msg = _("The upload does not appear to be a valid package.") | 07:06 |
| cjwatson | ogra_: so this is an SCA problem I'll bet | 07:06 |
| cjwatson | last SCA rollout was Friday though | 07:09 |
| cjwatson | and this succeeded yesterday | 07:09 |
| ogra_ | cjwatson, yeah, weird ... i spoke to cprov when smoking about it | 07:10 |
| ogra_ | he is taking a look now | 07:11 |
| cjwatson | ogra_: could yet be that we're sending the wrong data in the form, but the "__all__" smells of a bug on the SCA side to me | 07:13 |
| ogra_ | yeah, smells like it mis-takes the architecture for the name or some such | 07:14 |
| cjwatson | ogra_: I don't think that's architecture, I think that's more like the __all__ special name in Python | 07:18 |
| cjwatson | given the double underscores | 07:18 |
| ogra_ | hmm, yeah, or that :) | 07:18 |
| cjwatson | but there is no good reason for that to leak into error messages absent a bug :) | 07:19 |
| mup | PR snapd#2167 opened: Do not remove seed <Created by chipaca> <https://github.com/snapcore/snapd/pull/2167> | 07:24 |
| kyrofa | enoch85, you trying to reach me? | 07:41 |
| mup | PR snapd#2168 opened: snap/squashfs: try to hard link instead of copying. Also, switch to osutil.CopyFile for cp invocation <Created by chipaca> <https://github.com/snapcore/snapd/pull/2168> | 08:01 |
| === chihchun_afk is now known as chihchun | ||
| zyga | jdstrand: hey, can you please ack and land https://github.com/snapcore/snap-confine/pull/172 | 08:29 |
| mup | PR snap-confine#172: Improve decoding of mount flags <Created by zyga> <https://github.com/snapcore/snap-confine/pull/172> | 08:29 |
| zyga | Pharaoh_Atem: hey | 08:30 |
| zyga | Pharaoh_Atem: can you perhaps get into the xdistro room if you are not in a session now | 08:31 |
| dr1337 | ogra_ is the system-a and system-b partition structure with writable still apply to the /snap partition structure? | 08:40 |
| dr1337 | what about /var/snap ? | 08:40 |
| ogra_ | dr1337, thats dead since 15.04 | 08:47 |
| dr1337 | :/ | 08:47 |
| dr1337 | ogra_ where's the new documentation? | 08:48 |
| mup | PR snapcraft#777 closed: go plugin: don't put debugging symbols in generated binaries <Created by teknoraver> <Closed by teknoraver> <https://github.com/snapcore/snapcraft/pull/777> | 08:49 |
| cprov | ogra_: other LP built snaps are working fine, including store release. Come by, when you have time, so we can take a closer look on what's going on and how to improve the error message. | 08:54 |
| cjwatson | ogra_,cprov: c-r-t passes on that snap, at least; I wonder if the scan data is nonsense | 09:04 |
| cprov | cjwatson: what's the LP snap url ? | 09:06 |
| cjwatson | cprov: https://launchpad.net/~snappy-dev/+snap/core/+build/7241 | 09:07 |
| cjwatson | cprov: well, ogra_ reported https://launchpad.net/~snappy-dev/+snap/core/+build/7240, but either way | 09:07 |
| cprov | cjwatson: yeah, same error | 09:08 |
| ogra_ | yeah, i got a whole set of ten snaps that exposed it | 09:09 |
| cprov | cjwatson: the error is indeed coming from the store, src/devportal/clickapp_forms.py :-/ | 09:11 |
| cjwatson | cprov: William pointed out that the __all__ bit probably means it's a django form-global error | 09:11 |
| cjwatson | was anything deployed yesterday? CUD say? | 09:12 |
| cprov | cjwatson: which seems to be accurate. | 09:12 |
| Son_Goku | zyga: it begins... https://github.com/Conan-Kudo/snapcraft/commit/c960914b97440e2dca7a66c22c07438d809590fc | 09:18 |
| cjwatson | ogra_: the failure is because /var/lib/snapd/void changed from mode 0700 to mode 0000 | 09:24 |
| cjwatson | ogra_: this appears to crash the review tools | 09:24 |
| ogra_ | woah | 09:24 |
| ogra_ | thats mvo'S fault then i guess. he changed something regarding the writable paths yesterday that could cause this | 09:24 |
| ogra_ | hmm, he says it must be the review tools | 09:26 |
| cjwatson | the same version of the review tools seem to work for me | 09:26 |
| ogra_ | with 0700 you mean ? | 09:26 |
| cjwatson | with 0000 | 09:26 |
| ogra_ | hmm, so why dont they work in the store then | 09:27 |
| cjwatson | but I don't know SCA well enough, maybe there's some confinement going on or something | 09:27 |
| ogra_ | yeah, sounds like an environmental problem then | 09:27 |
| cjwatson | cprov: do you know if this error was directly from click-review, or if it was from the SCA task? | 09:27 |
| enoch85 | kyrofa: I was, but I solved it with oparoz | 09:29 |
| qengho | Who approves new app names for Ubutu snap store? I thought it was automatic if not in a blacklist. | 09:31 |
| qengho | The FJKong tried to register something. It awaits some review or something. | 09:32 |
| ogra_ | a name that was already taken ? | 09:33 |
| ogra_ | (usually it does not block) | 09:33 |
| qengho | I can not imagine it was taken. | 09:33 |
| ogra_ | then it should just work i think ... (definitely did for me the last times i registered one, though admittedly that was a while ago) | 09:34 |
| qengho | Me too. | 09:34 |
| FJKong | ogra_: thanks I got the problem solved | 09:34 |
| FJKong | I got answer from cprov | 09:36 |
| qengho | Should all names be suffixed with a hyphen and a username? FJ wanted to register 'qrq'. There is no chance that there will be a conflict in names. | 09:38 |
| cprov | qengho: only in the case the requester is not the upstream or doesn't have a clear relation with it. | 09:39 |
| mup | PR snapd#2169 opened: interfaces/builtin: finish decl based checks <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2169> | 09:39 |
| FJKong | cprov: I think this package is no longer maintained any more by upstream | 09:40 |
| qengho | FJKong: I guess you need to become upstream! | 09:40 |
| FJKong | ye, glad to do that | 09:41 |
| qengho | Okay, not a snappy problem then. | 09:41 |
| cjwatson | ogra_: narrowed down. can you please file a bug against software-center-agent for this? | 09:44 |
| cjwatson | ogra_: working on a fix | 09:44 |
| ogra_ | doing ... | 09:44 |
| ogra_ | cjwatson, bug 1634443 (feel free to adjust summary/description to be more accurate) | 09:48 |
| mup | Bug #1634443: changing directories like /var/lib/snapd to 0000 mode causes review-tools to misbehave <Software Center Agent:New> <https://launchpad.net/bugs/1634443> | 09:48 |
| kyrofa | enoch85, good deal | 09:53 |
| ogra_ | lool, https://bugs.launchpad.net/bugs/1621380 | 09:53 |
| mup | Bug #1621380: console-conf should allow to configure a hostname <Snappy:New> <subiquity (Ubuntu):In Progress> <https://launchpad.net/bugs/1621380> | 09:53 |
| lool | ogra_: added to notes, thakns | 10:23 |
| === chihchun is now known as chihchun_afk | ||
| bencc | do I need to install something to run snap packages on ubuntu 16.04 server? | 10:54 |
| Chipaca | bencc, "apt install snapd" should be enough | 11:22 |
| bencc | Chipaca: thanks | 11:26 |
| bencc | I'm considering packaging minio | 11:26 |
| bencc | https://github.com/minio/minio | 11:27 |
| Chipaca | bencc, nice! | 11:47 |
| mup | PR snapd#2170 opened: tests: use the snapd-control-consumer snap from the store <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2170> | 11:51 |
| mup | PR snapd#2164 closed: many: add supports for keeping and finding assertions with different format iterations <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2164> | 11:57 |
| === chihchun_afk is now known as chihchun | ||
| pstolowski | matiasb, ping | 12:23 |
| matiasb | pstolowski, o/ | 12:24 |
| pstolowski | matiasb, hey, are you going to join store filtering session? | 12:24 |
| matiasb | pstolowski, I guess I can be there if it helps | 12:25 |
| pstolowski | matiasb, i think there is some confusion about what this session is about.. looks like client-side filtering and we may need to know what store is capable of et | 12:26 |
| pstolowski | etc | 12:26 |
| pstolowski | matiasb, it's in rembrandt | 12:26 |
| matiasb | pstolowski, ack | 12:26 |
| pstolowski | in 4 minutes | 12:26 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#2171 opened: tests: reenable ubuntu-core tests on qemu <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2171> | 12:44 |
| fgimenez | hey om26er, i'm in potter, well now i'm heading to the coffee machine :) | 12:49 |
| om26er | fgimenez: was just going to ask if you have the TTL cable, now borrowed HDMI from IS. | 12:49 |
| desrt | Chipaca: hihi | 13:00 |
| Chipaca | desrt, o/ | 13:00 |
| desrt | Chipaca: got a chance to chat about XDG_RUNTIME_DIR inside of snaps? | 13:00 |
| desrt | am happy to meet in a hallway somewhere if you have some minutes | 13:01 |
| Chipaca | desrt, in half an hour? | 13:01 |
| desrt | sure | 13:01 |
| desrt | i'm in the desktop room if you want to come get me | 13:01 |
| om26er | fgimenez: Hey! if you have a wifi dongle, please bring that as well | 13:03 |
| fgimenez | om26er: ok, are you on the unity8 room? | 13:08 |
| om26er | yes | 13:09 |
| om26er | fgimenez: yes | 13:09 |
| mup | PR snapd#2156 closed: many: move from flags as ints to flags as structs-of-bools <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2156> | 13:33 |
| desrt | Chipaca: around? | 13:36 |
| mup | PR snapcraft#870 opened: sources: Add RPM source <Created by Conan-Kudo> <https://github.com/snapcore/snapcraft/pull/870> | 13:46 |
| === mbriza is now known as mbriza|gone | ||
| === mbriza|gone is now known as mbriza | ||
| mup | PR snapd#2151 closed: asserts,interfaces/policy: allow OR-ing of subrule constraints in plug/slot rules <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2151> | 14:06 |
| Chipaca | desrt, was around for a bit, missed your message here when i was out | 14:08 |
| Chipaca | desrt, want to come by Potter? | 14:09 |
| desrt | sure | 14:09 |
| lazyPower | lool you're my new best friend :) *much fanfare* | 14:15 |
| lool | lazyPower: Hmmm? | 14:16 |
| lazyPower | that mail to the snap list about the docker snap being available for testing | 14:16 |
| lool | :-) | 14:17 |
| lazyPower | lool - its suspiciously well timed as well - http://imgur.com/a/7nKwM | 14:17 |
| lool | wow! | 14:18 |
| lazyPower | armhf lab, 6 ssd backed rpi2/3's | 14:18 |
| lazyPower | its not as fast as a proper ssd, but at least the storage is reliable ;) | 14:18 |
| lool | lazyPower: BTW do you know you can network boot rpi3? | 14:18 |
| lazyPower | i do but its a one way change, adn i wasn't ready to commit | 14:18 |
| lool | yeah, same here :-) | 14:19 |
| lazyPower | i have been following the discussion on those addon wifi cards | 14:19 |
| lazyPower | sounds interesting enough | 14:19 |
| lazyPower | when we can maas enlist these boards, i'll be in nirvana | 14:19 |
| lool | lazyPower: is there a maas driver for devices without bmc? | 14:19 |
| lazyPower | i dont think so, but i'm not positive. I'd have to poke the #maas group | 14:20 |
| lool | lazyPower: how do you intend to drive power from maas for the rpis? | 14:21 |
| lazyPower | lool - well, the idea is that any time the board boots, it should read and attempt a pxe boot. maas will not re-pxe boot a provisioned machine so it should hten default to booting off the curtained disk | 14:23 |
| lazyPower | so i could in theory build a usb power brick with some additional love from a pi that can change power states on the ports | 14:23 |
| lazyPower | but thats WIP that has yet to be done, and that would be my first hardware hack in a heck of a long time | 14:24 |
| lazyPower | but i'm game to spend some weekends cycling on it | 14:24 |
| niemeyer | rharper: ping | 14:24 |
| rharper | niemeyer: here | 14:24 |
| niemeyer | rharper: Heya | 14:24 |
| rharper | hey | 14:24 |
| niemeyer | rharper: Looking into that cloud-init detail from PR snapd#2160 | 14:25 |
| mup | PR snapd#2160: image: tweak the cloud-init configuration <Created by mvo5> <https://github.com/snapcore/snapd/pull/2160> | 14:25 |
| mup | Bug #1620442 changed: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442> | 14:25 |
| lazyPower | lool - i was actually looking for a programmable usb hub/power-brick, and the only one i found was intended for telescope equipment, and its to the tune of 250 USD which is quite expensive for what its doing. | 14:25 |
| mup | PR snapd#2172 opened: asserts,interfaces/policy: implement on-classic plug/slot constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/2172> | 14:25 |
| lazyPower | lool - so seems like we're also hitting an edge of a product market that doesn't exist yet | 14:25 |
| niemeyer | rharper: How does the logic take place when there is both a default cloud.cfg and something else on .d? | 14:25 |
| rharper | niemeyer: cloud-init does a dictionary based merging of all of the yaml cfg files present | 14:26 |
| rharper | so loading /etc/cloud/cloud.cfg and any *.cfg that's yaml in /etc/cloud/cloud.cfg.d | 14:26 |
| niemeyer | rharper: How do we take an option off if they're mergeD? | 14:27 |
| rharper | I believe setting the value to None, or empty should suffice | 14:28 |
| niemeyer | rharper: Ok, so in theory if we use the full cloud.conf, will it work the same way? | 14:33 |
| niemeyer | rharper: Well, in practice actually? :) | 14:33 |
| iliv_ | is there a way to specify a target for make in the snapcraft.yaml file? | 14:34 |
| rharper | niemeyer: I can test that quickly by duplicating /etc/cloud/cloud.cfg and putting that in /etc/cloud/cloud.cfg.d/cloud.cfg | 14:35 |
| rharper | niemeyer: I expect it to work the same; yes | 14:35 |
| niemeyer | rharper: Thanks, it'd be nice to have some certainty about how this work as we'll be baking it into snapd proper.. if it's just a sum, then that's nicer indeed | 14:35 |
| lool | lazyPower: one of the old ones we used was http://www.digital-loggers.com/lpc.html | 14:36 |
| lool | lazyPower: but it's still fairly expensive and in my case the US power sockets are annoying | 14:36 |
| lazyPower | ah yeah i was hoping to avoid the AC power plug all together and get power-controlled USB ports instead | 14:37 |
| lazyPower | but this is a good lead, i should look into getting a managed power-switch | 14:37 |
| rharper | niemeyer: in general though, we'd like to avoid duplicating the default cloud.cfg in the gadget; | 14:38 |
| niemeyer | rharper: I'm still not entirely sure that's a good idea, but as long as the results of including a full cloud.cfg are the same, that should be okay | 14:38 |
| rharper | niemeyer: to be fair, the current cloud.conf file was never the full config; for example, it left off the 05_logging.cfg which is in /etc/cloud/cloud.cfg.d/ ... so current users of that miss configuring that and cloud-init.log remains empty | 14:40 |
| rharper | niemeyer: I'm interested in any scenario you think might not work ... ; | 14:41 |
| lazyPower | lool but to be fair, i think i'll wait for that maas work first :) then i'll invest in a managed power switch | 14:41 |
| lazyPower | until then, the plugin will be "manual" - as in, i get off my bum and to plug/unplug the board. | 14:41 |
| lazyPower | s/to/go/ | 14:41 |
| niemeyer | rharper: The problem is cloud.cfg changing behind the gadget's back, which is exactly the motivation for doing this | 14:42 |
| niemeyer | rharper: Somebody cooking an image for a particular environment will not expect these settings to magically change after an update | 14:42 |
| rharper | niemeyer: right, if the core snap (or cloud-init snap) updated; | 14:42 |
| niemeyer | rharper: Which it does all the time, right? :) | 14:43 |
| rharper | the cloud.cfg is pretty static actually | 14:43 |
| rharper | but the concern you raise is real | 14:43 |
| niemeyer | rharper: Right, but if the point is that it's okay because it doesn't change, then why are we doing this? :) | 14:43 |
| rharper | because almost zero folks copying in the correct cloud.cfg and it clobbered the default configureation | 14:44 |
| rharper | this meant that cloud-init ran but didn't do anything as the list of datasources and config modules to run was empty | 14:44 |
| niemeyer | rharper: Can you rephrase this? I didn | 14:44 |
| niemeyer | 't get the real point behind the comment | 14:45 |
| rharper | sure: previous behavior was: gadget needs 'cloud.conf' or cloud-init is disabled; if cloud.conf exists, copy cloud.conf to /etc/cloud/cloud.cfg; the overlay of cloud.cfg requires extracting the default cloud.cfg and the contents of /etc/cloud/cloud.cfg.d/*.cfg to bundle the correct default configuration | 14:46 |
| rharper | ideally we'd not punish cloud-init users by requiring that assembly of configuration into a single file | 14:47 |
| niemeyer | rharper: In the previous phrasing you mentioned a bug (didn't do anything because ...).. what was the cause/consequence? | 14:51 |
| rharper | niemeyer: the bug was that the conf clobbers the default cloud-init config; | 14:54 |
| niemeyer | rharper: Okay.. I thought they were actually trying to clobber it | 14:56 |
| rharper | niemeyer: hrm; ok | 14:57 |
| rharper | niemeyer: I do think that puts almost too much burden on gadget creator to understand all of cloud-init's defaults (or at least to learn how to extract it all from cloud-init deb) | 15:00 |
| rharper | niemeyer: I agree that if a gadget wanted to disable the default config then overwriting the cloud.cfg in the core snap is the right way to do that; | 15:01 |
| rharper | niemeyer: I don't think folks would realize that they might also need the 05_logging.cfg and other defaults to get the same behavior one would get on a cloud-image | 15:03 |
| niemeyer | rharper: There's a grub.conf right next to it, and a gadget.yaml with a detailed specification of partitions.. | 15:05 |
| niemeyer | rharper: I'm more concerned about behavior changing behind people's back than about them having to cargo cult a nice example | 15:05 |
| rharper | niemeyer: isn't that a general concern w.r.t conf files versus code in the core snap ? | 15:07 |
| niemeyer | rharper: Hmm.. in which sense? | 15:09 |
| rharper | we could include a configuration file for some other package in the core snap and an update could change behavior despite the config in the gadget | 15:11 |
| iliv_ | is there a way to make snapcraft cd into a specific directory before calling the make plugin? in this case, a Makefile includes another Makefile and the path to the second file is relative.. so it never gets included as apparently snapcrafts cwd is not where the first Makefile resides. | 15:24 |
| * iliv_ wondering if ogra_ might be able to help. He usually does :P | 15:25 | |
| === chihchun_afk is now known as chihchun | ||
| nacc | iliv_: i believe you might need to write a custom plugin then (pretty easy to do) | 15:34 |
| nacc | iliv_: it can probably inherit almost everything from the make plugin, except for the actual building step which knows about the details of your setup | 15:34 |
| iliv_ | hmm | 15:39 |
| iliv_ | alright | 15:39 |
| iliv_ | thanks nacc | 15:39 |
| iliv_ | where do I find make plugin's source code btw? | 15:39 |
| nacc | iliv_: that's what i've done in the past, at least | 15:39 |
| nacc | iliv_: it should all be in github (snapcraft iirc) | 15:39 |
| zyga | jdstrand: hey | 16:16 |
| zyga | jdstrand: I got notified about this bug earlier https://bugs.launchpad.net/snap-confine/+bug/1620442 | 16:16 |
| mup | Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442> | 16:16 |
| === chihchun is now known as chihchun_afk | ||
| zyga | jdstrand: it looks easy technically but I wanted to ask you about your opinion first | 16:17 |
| mup | PR snapd#2171 closed: tests: reenable ubuntu-core tests on qemu <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2171> | 16:32 |
| mup | PR snapd#2173 opened: overlord/snapstate: move trash cleanup to a cleanup handler <Created by chipaca> <https://github.com/snapcore/snapd/pull/2173> | 16:55 |
| mup | PR snapd#2174 opened: store: send supported max-format when retrieving assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/2174> | 17:03 |
| Chipaca | jdstrand, whereabouts are you? | 17:19 |
| mup | PR snapd#2132 closed: interfaces/builtin: enable out of process providers for locationd <Created by vosst> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2132> | 17:30 |
| Chipaca | jdstrand, dude we can tell you're not at the museum :-p | 17:31 |
| === tasdomas` is now known as tasdomas | ||
| === Beret- is now known as Beret | ||
| === devil is now known as Guest17894 | ||
| === Guest17894 is now known as devil_ | ||
| mup | PR snapd#2157 closed: boot,image,overlord,partition: read/write boot variables in single operation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2157> | 17:38 |
| mup | PR snapd#2167 closed: snapstate, devicestate: do not remove seed <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2167> | 18:03 |
| mup | PR snapd#2174 closed: store: send supported max-format when retrieving assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2174> | 18:10 |
| mup | PR snapd#2160 closed: image: tweak the cloud-init configuration <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2160> | 18:30 |
| mup | PR snapd#2168 closed: snap/squashfs: try to hard link instead of copying. Also, switch to osutil.CopyFile for cp invocation <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2168> | 18:31 |
| mup | PR snapd#2154 closed: cmd/snap: make snap run not talk to snapd for finding the revision <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2154> | 18:32 |
| mup | PR snapd#2170 closed: tests: use the snapd-control-consumer snap from the store <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2170> | 18:39 |
| jdstrand | Chipaca: yeah, not there | 19:11 |
| jdstrand | Chipaca: in my hotel room | 19:12 |
| Chipaca | jdstrand, we're in Potter, if you're feeling lonely | 19:12 |
| jdstrand | I'm feeling quite sleepy after last night tbh :) | 19:12 |
| Chipaca | jdstrand, but only if you have pants on | 19:12 |
| jdstrand | ya, you caught me there. ;) I think I am going to call it a night in a few | 19:13 |
| jdstrand | zyga: I saw bug #1620442. on touch we set that to somewhere in /run and in snapd we currently allow: /{dev,run}/shm/snap.@{SNAP_NAME}.** | 19:16 |
| mup | Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442> | 19:16 |
| jdstrand | zyga: actually that rule is irrelevant | 19:17 |
| jdstrand | zyga: but I don't think the bind mount is particularly necessary, we could just add an apparmor rule for /run/user/*/snap.$SNAP/**, set XDG_RUNTIME_DIR to point to that and mkdir | 19:19 |
| jdstrand | zyga: can you think of why it should be a bind mount? I mean, it is already honoring the envvar | 19:19 |
| jdstrand | zyga: (and this is something ubuntu-app-launch on Touch would set) | 19:19 |
| mup | PR snapd#2143 closed: overlord: check that the first installed gadget matches the model assertion <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2143> | 19:44 |
| mup | PR snapd#2172 closed: asserts,interfaces/policy: implement on-classic plug/slot constraints <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2172> | 20:24 |
| mup | PR snapd#2175 opened: overlord: checks for kernel installation/refresh based on model assertion and previous kernel <Created by pedronis> <https://github.com/snapcore/snapd/pull/2175> | 20:32 |
| mup | PR snapd#2123 closed: daemon: ensure `snap create-user --known` errors on classic (unless --force-managed is added) <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2123> | 20:36 |
| mup | PR snapd#2173 closed: overlord/snapstate: move trash cleanup to a cleanup handler <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2173> | 20:43 |
| k_ | Hi, is there a way to test snap on centos 7? | 20:44 |
| mup | PR snapd#2122 closed: snappy: disable auto-import of assertions on classic <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2122> | 20:52 |
| mup | PR snapd#2176 opened: store,daemon,overlord: download things to a partials dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/2176> | 21:07 |
| ypwong | slangasek, you may want to look at https://bugs.launchpad.net/ubuntu-image/+bug/1634557 | 21:19 |
| mup | Bug #1634557: The writable partition is corrupted using the latest ubuntu-image(0.8 ) <Ubuntu Image:New> <https://launchpad.net/bugs/1634557> | 21:19 |
| mup | PR snapd#2177 opened: many: use the new systemd backend for configuring GPIOs <Created by zyga> <https://github.com/snapcore/snapd/pull/2177> | 21:52 |
| mup | PR snapd#2178 opened: snap: spool assertion candidates if snapd is not up yet <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/2178> | 21:53 |
| slangasek | ypwong: hi - I had seen the bug and was going to raise this with barry today. This is listed as a regression vs. 0.7? where does this version of the package (0.8+17.04ubuntu1) come from? that's not a version that's in the archive | 21:59 |
| mup | PR snapd#2179 opened: remove silly stuff <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/2179> | 22:17 |
| slangasek | ypwong: ok, reproduced and it seems to not be a regression - we were just being spared this being an issue on the pi3 because of the firstboot autoresizing from the initramfs fixes it before we ever mount the rootfs | 22:23 |
| adam__ | hello, I am looking at using ubuntu core snappy as the OS of choice for a raspberry pi solution to communicate with a webserver and some connected hardware via a serial port. I already have a node app that I want to repackage as a snap, but I am struggling to find the information that I need online: 1) Can I publish snaps privately, e.g. with proprietary closed source code and still make use of the auto-update functionality? 2) Can I | 22:47 |
| rhollan | Is there a snappy package that has networking utils, specifically bridge-utils? I want to bridge two docker containers to the hosts interface and have them get internal IP addresses and gateways and dns servers therefrom | 23:30 |
| rhollan | I don't have any bridge utils on the host side in snappy | 23:31 |
| mup | PR snapd#2180 opened: overlord/snapstate: two bugs for one <Created by chipaca> <https://github.com/snapcore/snapd/pull/2180> | 23:32 |
| Chipaca | ^ fix for #1628914 :-D | 23:33 |
| mup | Bug #1628914: ubuntu-core edge image switched to stable channel unpredictably and became unusable <Snappy:In Progress by chipaca> <https://launchpad.net/bugs/1628914> | 23:33 |
| * Chipaca ~> bed | 23:33 | |
| mup | PR snapd#2179 closed: remove silly stuff <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2179> | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!