| Chipaca | niemeyer: http://imgur.com/RmoleVs | 00:07 |
|---|---|---|
| Chipaca | not ready yet, but, shellcheck for prepare/execute/etc \o/ :-) | 00:08 |
| niemeyer | Chipaca: Sweet! | 00:09 |
| Son_Goku | meep | 00:21 |
| === elfgoh_ is now known as elfgoh | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR core#45 closed: allow rsyslog disabling <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core/pull/45> | 05:38 |
| abeato | ogra_, hey. I'm following the discussion on androidboot here: https://forum.snapcraft.io/t/android-support-in-snapd/327/34 | 06:08 |
| zyga | good morning :) | 06:09 |
| morphis | Pharaoh_Atem: ping | 06:28 |
| morphis | zyga: morning! | 06:28 |
| morphis | zyga: I've found a "fix" for our ld problem for snap-confine on fedora as it seems: http://pkgs.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/commit/redhat-hardened-ld?id=b1a45b244ea644b78b0f626643758a05c0f049b5 | 06:28 |
| morphis | zyga: sadly that is only in >= F26 | 06:29 |
| morphis | Pharaoh_Atem: ^^ | 06:31 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| morphis | mvo: morning! | 07:30 |
| morphis | mvo: can you merge https://github.com/snapcore/snapd/pull/3360 ? | 07:30 |
| mup | PR snapd#3360: tests/libs: add distro_auto_remove_packages function <Created by morphis> <https://github.com/snapcore/snapd/pull/3360> | 07:30 |
| mvo | morphis: sure | 07:30 |
| mup | PR snapd#3356 closed: tests/lib: allow SRU validation only on ubuntu type systems <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3356> | 07:30 |
| morphis | mvo: thanks! | 07:30 |
| mvo | morphis: was mostly waiting for something that uses it, but its fine | 07:30 |
| morphis | mvo: yeah that will come next | 07:31 |
| morphis | mvo: any comments from your side on https://github.com/snapcore/snapd/pull/3274 ? | 07:31 |
| mup | PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274> | 07:31 |
| mvo | morphis: I have a look in a tiny bit | 07:31 |
| morphis | mvo: thanks! | 07:31 |
| mup | PR snapd#3360 closed: tests/libs: add distro_auto_remove_packages function <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3360> | 07:31 |
| zyga | morphis: good morning | 07:48 |
| zyga | morphis: can you document what that does? | 07:48 |
| zyga | morphis: what is 'r' there? | 07:48 |
| morphis | zyga: morning! | 07:48 |
| morphis | zyga: what do you mean? | 07:48 |
| zyga | morphis: that macro, what does it technically do? | 07:50 |
| zyga | morphis: e.g. I can imagine what static and shared are | 07:50 |
| zyga | morphis: but a good comment block there would help | 07:50 |
| morphis | zyga: not sure what the 'r' does but it prevents -pie from being added to LDFLAGS when -static is used | 07:50 |
| morphis | a comment block where? | 07:50 |
| morphis | http://pkgs.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/commit/redhat-hardened-ld?id=b1a45b244ea644b78b0f626643758a05c0f049b5 is nothing I can change | 07:51 |
| zyga | morphis: just above that macro, to explain what is going on | 07:54 |
| zyga | ahh | 07:54 |
| zyga | I thought that was something we have to add to our spec | 07:54 |
| morphis | no | 07:54 |
| zyga | sorry, it makes sense now :) | 07:54 |
| morphis | that is one of the scripts automatically pulled in for all builds via LDFLAGS | 07:54 |
| morphis | but I agree, pretty hard to understand if you don't know anything about these macros :-) | 07:55 |
| morphis | zyga: but https://github.com/snapcore/snapd/pull/3365/commits/67673a2c86263a401d078d7c82d2e1a43abfa389 should fix this problem for us | 07:55 |
| mup | PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365> | 07:55 |
| zyga | nice! :) | 07:56 |
| morphis | zyga: waiting for what Neal says :-) | 07:58 |
| morphis | zyga: when you have time today, a review on https://github.com/snapcore/snapd/pull/3365 would be great (but ignore the packaging bits, Neal is landing them separately) | 07:59 |
| mup | PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365> | 07:59 |
| elfgoh | Just checking, is delta snap upgrades a current feature? | 08:07 |
| Chipaca | elfgoh: yep | 08:11 |
| ogra_ | abeato, thats a beautiful idea! | 08:11 |
| * ogra_ will answer in the tread .. | 08:12 | |
| abeato | ogra_, I knew you would like it ;) | 08:12 |
| ogra_ | :D | 08:12 |
| morphis | zyga: thanks! | 08:25 |
| zyga | morphis: thank you :-) | 08:26 |
| morphis | zyga: hopefully have a PR for suse build support in spread tomorrow too | 08:26 |
| zyga | I need to mute some of the commit message email notification from fedora, my inbox is full of htem | 08:26 |
| zyga | morphis: fanstatic! | 08:26 |
| zyga | morphis: I'm going in four days, that will be some nice news I can share | 08:26 |
| elfgoh | @Chipaca | 08:26 |
| nothal | elfgoh: No such command! | 08:26 |
| morphis | at least able to run tests/main/null :-) | 08:26 |
| elfgoh | Chipaca: I did remember reading it but didnt seem to find it mentioned at https://snapcraft.io/docs/ any idea which page mentions it? | 08:28 |
| davidcalle | elfgoh: not mentioned in docs yes AFAICT, if it has landed in stable, it should be, otherwise, you should search in forum.snapcraft.io, there was an env var to set to test it iirc | 08:32 |
| davidcalle | elfgoh: just checked, it's enabled by default | 08:33 |
| davidcalle | snapcraft 2.28 | 08:34 |
| Chipaca | elfgoh: no, sorry | 08:36 |
| elfgoh | davidcalle: are you referring to "Delta uploads are now enabled for every snapcraft push done, a welcome bandwith saving addition."? | 08:36 |
| davidcalle | Indeed | 08:37 |
| Chipaca | that's uploads, that came after downloads | 08:37 |
| davidcalle | Oh, I misread upgrades in your question, so yes, it's enabled | 08:38 |
| elfgoh | davidcalle: Chipaca : seems like delta downloads are currently disabled by default. Guess it is not stable yet? https://github.com/snapcore/snapd/blob/0e53b0aac99d112b3e2669701b5540f286e5a713/tests/main/refresh-delta-from-core/task.yaml#L3 | 08:41 |
| zyga | elfgoh: odd, I saw delta updates for core all the time and I didn't enable anything | 08:42 |
| Chipaca | zyga: disabled by default _on core_ | 08:42 |
| Chipaca | is what that comment says | 08:42 |
| zyga | ah, on all-snap | 08:42 |
| zyga | sorry | 08:42 |
| Chipaca | I'm not sure that comment is current, though | 08:43 |
| elfgoh | So it is enabled on all snaps but disabled on core? | 08:43 |
| * ogra_ is pretty sure you guys held that back | 08:43 | |
| ogra_ | (for ubuntu-core images that is) | 08:43 |
| Chipaca | deltasDefault := release.OnClassic | 08:44 |
| Chipaca | return osutil.GetenvBool("SNAPD_USE_DELTAS_EXPERIMENTAL", deltasDefault) | 08:44 |
| ogra_ | yeah | 08:44 |
| Chipaca | so, it defaults to false on core | 08:44 |
| elfgoh | So false on core snap, but is it true on other snaps? | 08:45 |
| Chipaca | no, false on core systems, true everywhere else | 08:45 |
| ogra_ | no, false on core images | 08:45 |
| ogra_ | (for all snaps there) | 08:45 |
| Chipaca | core as in non-classic | 08:45 |
| Chipaca | i.e. devices | 08:45 |
| Chipaca | i.e. probably memory and/or cpu constrained | 08:45 |
| elfgoh | Ah i see | 08:46 |
| pedronis | Chipaca: we should revisit this, I suppose nobody did yet the benchmarks though ? | 08:46 |
| ogra_ | +1 | 08:46 |
| Chipaca | pedronis: i nominate ogra_ for the benchmarkingening | 08:46 |
| ogra_ | should just setting the env var in /etc/environment be enough ? | 08:46 |
| ogra_ | or will anything unset it internally if it finds i'm on core | 08:47 |
| Chipaca | nothing will unset it, no | 08:47 |
| ogra_ | good | 08:47 |
| Chipaca | it just defaults to false on core | 08:47 |
| ogra_ | i'll do some testing during the day (though am a little swamped by the humminboard gadget currently) | 08:47 |
| Chipaca | ogra_: maybe we can write something simple that does the heavy lifting of a delta refresh, so we can get some numbers | 08:48 |
| Chipaca | not that i'm volunteering for that :-) | 08:48 |
| elfgoh | Got it with regards to delta upgrades. Is there a roadmap for that? | 08:48 |
| elfgoh | A rough one that I wont be holding anyone to :) | 08:49 |
| pedronis | ? | 08:49 |
| ogra_ | elfgoh, well, see above, they should just work ... we just havent tried what the impact on the system is | 08:49 |
| ogra_ | which is why the variable is currently unset | 08:49 |
| ogra_ | you can just edit /etc/environment if you want to try it out on a test system | 08:50 |
| elfgoh | Ok fair enough. Would it be helpful if I file an issue somewhere, or post on the forum? | 08:50 |
| pedronis | mvo: so 2.25 is blocked ? | 08:50 |
| ogra_ | SNAPD_USE_DELTAS_EXPERIMENTAL=true | 08:50 |
| elfgoh | Just so that it wont be forgotten in the long run :) | 08:50 |
| mvo | pedronis: yeah, currently due to the potential regression on revert | 08:50 |
| mvo | pedronis: CE QA is not passing | 08:50 |
| pedronis | mvo: revert of core ? | 08:50 |
| pedronis | 2.25 -> 2.24 ? | 08:51 |
| mvo | pedronis: correct, | 08:51 |
| mvo | pedronis: yes, the fact that seccomp profiles are now richer than in 2.24 and when 2.24 sees them it will explode | 08:51 |
| pedronis | mvo: there's a small issue also related to aliases like that, but we can fix it only with 2.24.1 if we care | 08:51 |
| pedronis | (I mean it's not something we can fix with 2.25) | 08:51 |
| mvo | pedronis: is my forum post understandable on what the issue is? if not I will redo it to make it clearer | 08:51 |
| pedronis | mvo: now I understand it, it also seams something that would need a 2.24.1 though | 08:52 |
| mvo | pedronis: how bad is the effect when the aliases are reverted? | 08:52 |
| mvo | pedronis: if its mostly small glitches I think that is not too terrible, however the seccomp thing prevents daemons from starting which is pretty major | 08:53 |
| zyga | hey guys | 08:53 |
| zyga | how can I help | 08:53 |
| zyga | mvo: I didn't want to mention this before cause it's not helping much | 08:53 |
| pedronis | mvo: you get a error on each refresh (but given that refreshes use lanes it doesn't affect any real update afaik), it gets unstuck when the affected snap gets a real refresh | 08:53 |
| mvo | pedronis: doing a 2.24.1 is doable but the problem is that some devices may have a factory image of e.g. 2.21 or similar, so retro fitting a fix is troublesome | 08:53 |
| zyga | mvo: but I wrote a patch that lets snapd resolve the constants in appamror profiles (think AF_UNIX) | 08:53 |
| zyga | mvo: so we could eliminate the issue when starting up | 08:54 |
| mvo | pedronis: ok, thank yo. that sounds annoying but not catastrophic | 08:54 |
| zyga | mvo: i didn't want to mention it because I wasn't sure we'd want to merge that (I did it for a totally different reason) | 08:54 |
| zyga | mvo: but in light of the issue perhaps we might | 08:55 |
| zyga | mvo: it is in this branch: https://github.com/zyga/snapd/tree/feature/typed-syscalls | 08:55 |
| mvo | zyga: hm, interessting. sounds good, unfortunately will not help with this particular issue | 08:55 |
| zyga | mvo: no? | 08:55 |
| zyga | mvo: I think it does | 08:55 |
| zyga | mvo: because old snap-confine can read seccomp filters with numeric constants just fine | 08:56 |
| mvo | zyga: oh, that is nice | 08:56 |
| zyga | mvo: it chokes on new symbols and new syntax | 08:56 |
| pedronis | mvo: 2.25 drops the 2.24 state about aliases, so 2.24 on refresh tries to create them but they are already there, if you do a full real refresh of a snap , all its aliases are deleted so this gets unstuck | 08:56 |
| zyga | mvo: this eliminates new symbols | 08:56 |
| mvo | zyga: sorry, I misunderstood what it is doing then, that is nice | 08:56 |
| zyga | mvo: does not eliminate new syntax, I believe we have added one but I'd have to check when (the |foo syntax for bitwise masking) | 08:56 |
| zyga | mvo: as I said, it started as something else entirely | 08:56 |
| mvo | zyga: could you check that? | 08:57 |
| pedronis | mvo: anyway a bit unclear how to fix these kind of problems, we would need anti-patches to applay when we know we are about to revert core | 08:57 |
| mvo | zyga: if we relly only added new constants it may get us out of this for now | 08:57 |
| zyga | mvo: yes, checking | 08:57 |
| zyga | mvo: the "meat" is this feature: https://github.com/zyga/snapd/commit/4c2d556335401a73fb536f17a9f7568ae59656d2#diff-3b6970e27a8fba15de5e737fa725d7f5R87 | 08:57 |
| mvo | pedronis: yeah, the general case for this is hard | 08:58 |
| mvo | zyga: did jamie had a chance to look at this yet? | 08:58 |
| mvo | zyga: this being your new code? | 08:59 |
| zyga | mvo: last new syntax was added on the 30th january | 08:59 |
| zyga | mvo: yes | 08:59 |
| zyga | mvo: it's not new, I wrote it over two weeks ago | 08:59 |
| zyga | mvo: we talked about the way the seccomp profiles look like, I wanted to make them more readable | 09:00 |
| zyga | afk, package | 09:00 |
| zyga | ... | 09:00 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR core#46 opened: cut the trailing ~ubuntu16.04 from the version that the PPA auto-generates <Created by mvo5> <https://github.com/snapcore/core/pull/46> | 09:03 |
| mvo | morphis: 3357 has a conflict now, otherwise ready to go in | 09:06 |
| morphis | mvo: let me check | 09:06 |
| morphis | mvo: fixed | 09:08 |
| zyga | re | 09:08 |
| zyga | mvo: though thinking about it more, this can land and it will still not fix the issue because it will only take effect next time | 09:08 |
| zyga | mvo: so it will fix the issue but only with the future update | 09:08 |
| zyga | mvo: here we're really at a place where revert is impossible | 09:09 |
| zyga | mvo: as any new mechanism we add won't take effect until we reboot | 09:09 |
| zyga | mvo: hmm | 09:09 |
| zyga | mvo: maybe I'm too pesimistic | 09:09 |
| zyga | mvo: if you update to edge with this patch you could go back actually | 09:09 |
| zyga | mvo: if you want me to explore this I can clean that up, remove the parts that don't matter | 09:10 |
| zyga | mvo: and just focus on resolving the constants | 09:10 |
| fgimenez | hi mvo, not sure if this is known but tests/main/listing is failing with the latest core in edge (amd64 1999) https://travis-ci.org/snapcore/spread-cron/builds/234734542#L1022 | 09:10 |
| === chihchun_afk is now known as chihchun | ||
| mvo | fgimenez: yeah, I noticed, the version number is now in line with mkvresions.sh (almost) and that breaks the regexp | 09:12 |
| mvo | ogra_, zyga: if someone could check https://github.com/snapcore/core/pull/46 that would be great, then I will update hte listing test next | 09:12 |
| mup | PR core#46: cut the trailing ~ubuntu16.04 from the version that the PPA auto-generates <Created by mvo5> <https://github.com/snapcore/core/pull/46> | 09:12 |
| zyga | ok | 09:13 |
| ogra_ | heh, so much "cut" ... | 09:13 |
| mvo | zyga: \o/ | 09:13 |
| zyga | paper-cut | 09:13 |
| ogra_ | looks ok, though i would have gone with a single sed command for all three cuts | 09:14 |
| mup | PR core#46 closed: cut the trailing ~ubuntu16.04 from the version that the PPA auto-generates <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/46> | 09:14 |
| elfgoh | Quick check: is there some kind of cgroups functionality for snaps? | 09:19 |
| zyga | yes | 09:20 |
| mup | PR snapd#3368 opened: tests: update listing test to the core version number schema <Created by mvo5> <https://github.com/snapcore/snapd/pull/3368> | 09:20 |
| ogra_ | mvo, what does git202 mean in the new version number ? (why not just git) | 09:26 |
| mvo | ogra_: it will increase and give us correctly sorted versions, its the commit count since the last taged version (since 2.26.3 in this case) | 09:27 |
| ogra_ | ah, k | 09:28 |
| zyga | mvo: niiiice | 09:29 |
| zyga | mvo: how did you come up with that? | 09:29 |
| zyga | mvo: do we comit that per build? | 09:29 |
| ogra_ | mvo, you forgot the manifest | 09:29 |
| zyga | mvo: or does it come from launchpad? | 09:29 |
| elfgoh | zyga: where is it documented, or rather, what is the name of the functionality I should search? | 09:29 |
| zyga | elfgoh: re | 09:29 |
| mvo | ogra_: aha, indeed | 09:29 |
| zyga | elfgoh: sorry, it's not documented much | 09:29 |
| mvo | zyga: comes from LP | 09:29 |
| zyga | elfgoh: but I can tell you about it quickly | 09:29 |
| mvo | zyga: have you seen https://errors.ubuntu.com/problem/19272ebc18709d4407dba0438a536d56bb143069 ? | 09:29 |
| zyga | elfgoh: each process may optionally get a device cgroup that has just a subset of system devices available | 09:30 |
| zyga | elfgoh: that's it | 09:30 |
| mvo | zyga: looks like we get quite a lot of those: "Error ERROR run hook "configure" → cannot create lock directory /run/snapd/lock → Permission denied" | 09:30 |
| zyga | elfgoh: the optional part depends on how interfaces are implemented | 09:30 |
| zyga | mvo: where? | 09:30 |
| mvo | zyga: on the error tracker | 09:30 |
| mvo | zyga: ERROR run hook "configure": cannot create lock directory /run/snapd/lock: Permission denied | 09:30 |
| zyga | mvo: I helped someone on IRC yesterday, this happens before dpkg --configure -a is done | 09:30 |
| zyga | mvo: because we get an apparmor profile with .dpkg-new | 09:31 |
| ogra_ | mvo, we had someone here last week with the very same error | 09:31 |
| zyga | mvo: and the update is otherwise paritally applied | 09:31 |
| mvo | zyga: aha, that explains why this is only happening for some snaps then | 09:31 |
| zyga | mvo: not sure if that's the same reason as what the errors you saw are but this is a very likely explanation | 09:31 |
| zyga | mvo: s/snaps/people/ | 09:31 |
| elfgoh | zyga: thanks for the nutshell. Which repo and what search string should I be using to search to take a deeper look? | 09:31 |
| zyga | elfgoh: snapd itself, in cmd/snap-confine/udev-support.c | 09:32 |
| zyga | elfgoh: and in snapd itself in interfaces/builtin/*.go | 09:32 |
| zyga | elfgoh: an interface can tag devices in udev | 09:32 |
| zyga | elfgoh: and if any tagged devices are found a cgroup is made | 09:32 |
| mvo | zyga: was this in this channel? then I will read the logs for the details | 09:32 |
| ogra_ | yep | 09:32 |
| zyga | mvo: yes it was | 09:32 |
| zyga | mvo: let me find it | 09:33 |
| zyga | ah | 09:33 |
| zyga | where are the public logs again? | 09:33 |
| elfgoh | zyga: thanks for the info! | 09:33 |
| mvo | zyga: https://irclogs.ubuntu.com/2017/05/21/%23snappy.html | 09:33 |
| ogra_ | mvo, https://paste.ubuntu.com/24605885/ it was davhou around the 19th 18:0 UTC | 09:33 |
| zyga | ah, thanks ogra_ :) | 09:33 |
| ogra_ | *18:30 | 09:34 |
| mvo | zyga: well, https://irclogs.ubuntu.com/2017/05/19/%23snappy.html#t17:43 | 09:34 |
| mvo | ogra_: thank you | 09:34 |
| elfgoh | zyga: is there a repo for https://snapcraft.io/docs/? I am happy to send PRs for whatever little nuggets of gold I find in here | 09:36 |
| zyga | elfgoh: yes, let me find it | 09:37 |
| davidcalle | @elfgoh, zyga: https://github.com/CanonicalLtd/snappy-docs | 09:37 |
| nothal | davidcalle: No such command! | 09:37 |
| davidcalle | Heh | 09:37 |
| zyga | elfgoh: https://github.com/CanonicalLtd/snappy-docs | 09:38 |
| elfgoh | heh slack user? | 09:38 |
| ogra_ | zyga, or Chipaca ... a second ack at https://github.com/snapcore/core/pull/43 would be nice | 09:38 |
| mup | PR core#43: remove generated logs, cleaner lsb-release removal <Created by ogra1> <https://github.com/snapcore/core/pull/43> | 09:38 |
| elfgoh | Ok another question, is the GPIO interface supposed to be working on pi3? | 09:39 |
| ogra_ | elfgoh, it surely is | 09:39 |
| zyga | ogra_: done, though you will not like it | 09:39 |
| ogra_ | zyga, lsb_release is gone since about a year and i wont add it back | 09:40 |
| elfgoh | ogra_: good to know. I will make a post on the forum for my use case then | 09:40 |
| ogra_ | zyga, this just removes it in a clenaer way, check the code ;) | 09:40 |
| ogra_ | zyga, (also you commented on the code that adds it to the classic snap :) not teh code that removes the left over dpkg fragments) | 09:41 |
| * elfgoh discovers the new channel topic https://forum.snapcraft.io/t/when-to-use-forum-vs-irc/38 | 09:42 | |
| mup | PR core#47 opened: keep version Makefile in sync with version-script <Created by mvo5> <https://github.com/snapcore/core/pull/47> | 09:45 |
| mup | PR core#43 closed: remove generated logs, cleaner lsb-release removal <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/43> | 09:46 |
| Chipaca | huh | 09:50 |
| ogra_ | elfgoh, the interfaces follow the naming scheme from https://pinout.xyz/# | 09:50 |
| ogra_ | Chipaca, ? | 09:50 |
| Chipaca | I always forget how export FOO="$(yadda)" is very different from FOO="$(yadda)"; export FOO | 09:50 |
| morphis | fgimenez, zyga: can you check https://github.com/snapcore/spread-images/pull/2 again? | 09:51 |
| mup | PR spread-images#2: Add fedora-25-64 image <Created by morphis> <https://github.com/snapcore/spread-images/pull/2> | 09:51 |
| zyga | morphis: done | 09:53 |
| morphis | thanks | 09:53 |
| elfgoh | ogra_: for starters I believe BCM 27 may be missing https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml | 09:54 |
| elfgoh | But seems like an easy fix | 09:55 |
| ogra_ | elfgoh, hmm, indeed it does | 09:55 |
| ogra_ | yeah | 09:55 |
| elfgoh | I can send the PR if you are too busy lol | 09:55 |
| fgimenez | morphis: done, LGTM | 09:56 |
| morphis | thanks! | 09:56 |
| ogra_ | elfgoh, https://github.com/snapcore/pi3-gadget/pull/8 | 09:57 |
| mup | PR pi3-gadget#8: add gpio 27 <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/8> | 09:57 |
| ogra_ | :) | 09:57 |
| Chipaca | ok, going to wrap this shellcheck branch here before it gets out of hand | 09:57 |
| * Chipaca is so tempted to take it to the next level | 09:57 | |
| pedronis | Chipaca: spellcheck can be annoying, is the next level even more annoyance ? | 09:58 |
| pedronis | heh, shellcheck | 09:58 |
| Chipaca | pedronis: http://i.imgur.com/RmoleVs.png | 09:59 |
| Chipaca | that's what kept me up to 1am last night :-) | 09:59 |
| Chipaca | but i'm not running that yet; that would be the next level i alluded to | 09:59 |
| ogra_ | Chipaca, PATH=$PATH sudo -E ... | 10:01 |
| ogra_ | (and add quoting indeed) | 10:01 |
| Chipaca | that one is the other way around I think? | 10:01 |
| Chipaca | ie sudo PATH=$PATH … | 10:01 |
| ogra_ | -E will preserve the PATH you set before the sudo command ... | 10:01 |
| Chipaca | no | 10:01 |
| ogra_ | it should | 10:01 |
| Chipaca | -E preserves everything except the path | 10:02 |
| pedronis | Chipaca: so you have a massive branch of tests/ fixes ? (I expect them to be very shellcheck unagreeable atm) | 10:02 |
| ogra_ | Chipaca, wow ... why does the manpage not tell that! | 10:03 |
| mup | PR snapd#3369 opened: many: make shell scripts shellcheck-clean <Created by chipaca> <https://github.com/snapcore/snapd/pull/3369> | 10:04 |
| Chipaca | pedronis: ^ not that massive | 10:04 |
| Chipaca | ogra_: ¯\_(ツ)_/¯ | 10:04 |
| Chipaca | ogra_: actually, it does | 10:05 |
| Chipaca | ogra_: under "SECURITY NOTES" | 10:05 |
| pedronis | Chipaca: those are the .sh though ? not the .yaml fragments, no? | 10:05 |
| ogra_ | yeah, but not under the explanation of -E ... there is no hint at all to even look at SECURITY_NOTES | 10:05 |
| Chipaca | ogra_: … although I'll admit that reading that section would make me think it does the opposite | 10:06 |
| Chipaca | pedronis: correct, that's what i meant by _not_ doing the .yaml fragments yet | 10:06 |
| Chipaca | um | 10:06 |
| Chipaca | pedronis: I mean, this is what I meant about not taking it to the next level | 10:06 |
| Chipaca | the output of shellcheck from the yaml fragments is long :-) | 10:06 |
| pedronis | Chipaca: I have complicated feelings about this | 10:07 |
| Chipaca | pedronis: you can share your feelings with us | 10:07 |
| Chipaca | pedronis: we're only writing it down all for posterity | 10:07 |
| ogra_ | Chipaca, btw, see the find in line 24 at https://github.com/snapcore/core-build/blob/master/.travis.yml ... | 10:08 |
| pedronis | Chipaca: do you think the confusion avoidance down the line is worth this? | 10:08 |
| elfgoh | ogra_: https://forum.snapcraft.io/t/gpio-on-raspberry-pi-3-not-working-for-blink-program/723 | 10:08 |
| pedronis | (these are not the prod script if I understand) | 10:08 |
| elfgoh | That's the details of the Pi 3 GPIO issue | 10:08 |
| ogra_ | Chipaca, to find all shell scripts ... easier than hardcoding all .sh names | 10:08 |
| Chipaca | ogra_: thing is, different rules | 10:09 |
| Chipaca | OTOH by not doing it that way I am missing some things | 10:09 |
| ogra_ | elfgoh, and you did use https://pinout.xyz/# as translation table for pin to gpio ? | 10:12 |
| pedronis | mvo: listing tests seems to be still failing: https://travis-ci.org/snapcore/snapd/builds/234747297 snapd#3368 | 10:12 |
| mup | PR snapd#3368: tests: update listing test to the core version number schema <Created by mvo5> <https://github.com/snapcore/snapd/pull/3368> | 10:12 |
| elfgoh | Yup. The same source , when compiled using gcc. Runs fine | 10:13 |
| elfgoh | ie outside of a snap | 10:13 |
| elfgoh | So presumably, that means the source and the hardware connections are finwe | 10:13 |
| elfgoh | *fine | 10:13 |
| ogra_ | just wanting to make sure ... since pin 22 isnt gpio 22 etc | 10:14 |
| ogra_ | elfgoh, also checking for DENIED in journalctl output and actual error output for your program call might be helpful in the tread | 10:15 |
| mvo | pedronis: yeah, just noticed, regexps are hard (except for Chipaca who eats them for breakfast) | 10:18 |
| Chipaca | mvo: let me know if you need help (i haven't looked) | 10:19 |
| mvo | Chipaca: its fine I think | 10:19 |
| mvo | Chipaca: just a silly typo (hopefully) | 10:19 |
| * pedronis has lunch (no eating of regexpes involved though) | 10:20 | |
| mvo | lol@pedronis | 10:20 |
| fgimenez | mvo: superlow priority, we have an issue with a test snap in staging, its name is too long and there's a restriction that prevents us from updating it, after catching up with nessita the better solution is to use a different snap with a shorter name and update the test to use it, we need it too in prod https://code.launchpad.net/~snappy-dev/snappy-hub/test-snapd-kernel-module-consumer if you could register when you have a minute it that would be | 10:21 |
| fgimenez | great | 10:21 |
| fgimenez | mvo: wrong link sorry https://code.launchpad.net/~snappy-dev/+snap/test-snapd-kernel-module-consumer | 10:21 |
| fgimenez | mvo: it seems also that the hello-world test snap used by tests/main/xauth-migration is not available in staging, i can't get the error now because staging seems to have problems http://paste.ubuntu.com/24623008/ | 10:24 |
| Chipaca | zyga: ping | 10:24 |
| mvo | fgimenez: I uploaded the new snap and shared it with you | 10:25 |
| fgimenez | mvo: thank you!! | 10:25 |
| zyga | Chipaca: yes? | 10:25 |
| Chipaca | zyga: ok with you if i drop shellcheck from the cmd checks? | 10:26 |
| Chipaca | zyga: (moving it up into run-checks) | 10:26 |
| zyga | Chipaca: yes | 10:26 |
| Chipaca | k | 10:26 |
| zyga | Chipaca: feel free :) | 10:26 |
| * zyga churns through some interface changes | 10:26 | |
| mvo | Chipaca: your branch about the shellcheck explodes in quite spectacular ways in travis, I have not looked into the details yet | 10:27 |
| Chipaca | mbuahaha | 10:27 |
| Chipaca | mvo: thanks for the heads up; i'll take a look | 10:27 |
| ogra_ | elfgoh, that looks like an actual bug in snapd's gpio interface ... i dont see any write permission to /sys/class/gpio/export in tteh interface | 10:27 |
| elfgoh | ogra_: Output from journalctl https://forum.snapcraft.io/t/gpio-on-raspberry-pi-3-not-working-for-blink-program/723/2?u=elfgoh | 10:29 |
| elfgoh | ogra_: indeed | 10:30 |
| elfgoh | So another easy fix? :D | 10:30 |
| ogra_ | elfgoh, not sure, we'll need a security person for that ... | 10:30 |
| elfgoh | Ok | 10:31 |
| ogra_ | i pinged in the thread ... | 10:33 |
| Chipaca | ++ go get -u github.com/kardianos/govendor | 10:34 |
| elfgoh | Thanks! | 10:34 |
| Chipaca | opath/src/github.com/snapcore/snapd/tests/lib/prepare-project.sh: line 141: go: command not found | 10:34 |
| ogra_ | it wants you to stay, not go :) | 10:35 |
| Chipaca | hrmph | 10:43 |
| Chipaca | morphis: about pkgdb.sh | 10:48 |
| morphis | Chipaca: yes | 10:48 |
| Chipaca | morphis: seems to be a step back in speed and over-verbose output | 10:48 |
| Chipaca | including progress bars in the build log | 10:49 |
| Chipaca | morphis: is that something you'll be looking at, or should i meddle? | 10:49 |
| morphis | Chipaca: I have a few quiet's coming | 10:49 |
| Chipaca | morphis: wrt speed, a single apt-get of a bunch of packages is a lot faster than multiple apt-gets | 10:49 |
| morphis | Chipaca: if you have any improvements for the pkgdb, I am all ears | 10:50 |
| Chipaca | OTOH i assume it's a WIP, given one distro_install_package is followed by an apt-get :-) | 10:51 |
| === JanC_ is now known as JanC | ||
| morphis | Chipaca: we could do some fancy concatenation by determining all correct package names first and then supplying that to a single distro install command | 10:53 |
| morphis | let me tune that | 10:53 |
| Chipaca | morphis: or use an array instead of concatenation | 10:53 |
| Chipaca | the iteration will be a little gnarly, but otherwise cleaner in general | 10:53 |
| morphis | is that easy enough to fold back into a string I can pass to apt-get? | 10:54 |
| zyga | morphis: hey | 11:03 |
| zyga | morphis: shall we land https://github.com/snapcore/snapd/pull/3366 and iterate? | 11:03 |
| mup | PR snapd#3366: packaging: Add Fedora packaging files <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3366> | 11:03 |
| morphis | I am fine with that | 11:04 |
| mup | PR snapd#3366 closed: packaging: Add Fedora packaging files <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3366> | 11:06 |
| pedronis | mvo: should we close snapd#3226 , I think we should start more from a minimal skeleton and then maybe work separately on download, verification and execution (though we might need some kind of state on disk shared between download and execution) | 11:07 |
| mup | PR snapd#3226: snap-repair: add `snap-repair run` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3226> | 11:07 |
| mup | PR snapd#3364 closed: interfaces: allow snaps to use the timedatectl utility <Created by tyhicks> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3364> | 11:08 |
| * ogra_ hugs zyga | 11:08 | |
| * zyga hugs ogra back! | 11:09 | |
| ogra_ | :) | 11:09 |
| pedronis | fgimenez: didn't we increase workers and cut down execution time, are we still getting global timeouts, sometimes? https://travis-ci.org/snapcore/snapd/builds/234764184 | 11:10 |
| mup | PR snapd#3370 opened: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370> | 11:10 |
| zyga | Chipaca: another monster, smaller though https://github.com/snapcore/snapd/pull/3370/files | 11:10 |
| mup | PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370> | 11:10 |
| zyga | Chipaca: and 2nd-to-last of this kind | 11:10 |
| zyga | Chipaca: the only centralized part of interface that remains is the base declaration | 11:11 |
| * zyga looks at all the PRs next | 11:13 | |
| fgimenez | pedronis: yes, looks like it, that execution had allocation problems and spent about 8min before starting actual tests, also we have moved unit tests from a spread task to a regular travis script step, this impose an upfront penalty to all jobs of about 5min (in that build 286s) | 11:23 |
| fgimenez | pedronis: it also got stuck oon an apt-get update https://travis-ci.org/snapcore/snapd/builds/234764184#L1660 | 11:23 |
| fgimenez | we are close to 30min now on average https://travis-ci.org/snapcore/snapd/builds | 11:25 |
| pedronis | thx | 11:25 |
| morphis | zyga: thanks for merging! | 11:29 |
| morphis | zyga: let me send a similar one for suse | 11:29 |
| * zyga breaks for lunc | 11:31 | |
| zyga | pstolowski: some feedback on your snapctl-outside-of-hooks-PR | 11:31 |
| pstolowski | zyga, great, looking! nb, any idea about 'listing' test failures? got this in my branch but also in master | 11:33 |
| mup | PR snapd#3371 opened: packaging: import packaging bits for opensuse <Created by morphis> <https://github.com/snapcore/snapd/pull/3371> | 11:36 |
| morphis | zyga: ^^ | 11:36 |
| pedronis | pstolowski: there's a PR from mvo fixing that, taking a bit of time to get it landed | 11:36 |
| pstolowski | pedronis, great, thanks | 11:37 |
| === JamieBen_ is now known as JamieBennett | ||
| fgimenez | mvo: this is the error we are getting in staging for tests/main/xauth-migration http://paste.ubuntu.com/24623205/ could make staging's hello-world be the same as prod's? let me know if i can help with that | 12:03 |
| mvo | fgimenez: hm, this feels like we should use tes-tsnapd-tools there anyway | 12:05 |
| ogra_ | echo 'foo bar' ? | 12:05 |
| ogra_ | whats that for | 12:05 |
| Chipaca | mvo: does snapd#3368 mean the listing test is broken in master right now? | 12:07 |
| mup | PR snapd#3368: tests: update listing test to the core version number schema <Created by mvo5> <https://github.com/snapcore/snapd/pull/3368> | 12:07 |
| mvo | Chipaca: correct | 12:09 |
| pedronis | it failed again :/ | 12:12 |
| pedronis | flaky++ | 12:12 |
| mvo | pedronis: yeah, for silly reasons | 12:12 |
| mvo | pedronis: that it cannot connect to ubuntu-core | 12:12 |
| niemeyer | o/ | 12:15 |
| fgimenez | mvo: ok thanks, i'm preparing a branch for fixing all the issues in staging, i'll include updating xauth-migration to use test-snapd-tools | 12:16 |
| fgimenez | hey niemeyer | 12:16 |
| mvo | fgimenez: thanks, sounds good | 12:20 |
| zyga | re | 12:28 |
| * zyga looks at spread | 12:28 | |
| zyga | we got a 504 from the store on delta test | 12:30 |
| zyga | for updates: got unexpected HTTP status code 504 via POST to | 12:30 |
| zyga | "https://search.apps.ubuntu.com/api/v1/snaps/metadata" | 12:30 |
| pedronis | zyga: we don't retry on those it seems | 12:42 |
| pedronis | also interesting | 12:42 |
| zyga | pstolowski: ^ the gift that keeps on giving | 12:42 |
| zyga | travis for the ciritcal PR (fix master) is running bug log is gone, I wonder if that will wokr | 12:42 |
| zyga | *work | 12:42 |
| pstolowski | zyga, indeed we don't... | 12:44 |
| cprov | zyga, let me trace it on the (new) store | 12:44 |
| mpt | Hi, where should I report a bug about forum.snapcraft.io itself? | 12:48 |
| zyga | mpt: hey, I think the best way is to start a forum topic first | 12:49 |
| zyga | mpt: we can then report a bug (though I don't know if the forum has a bug tracker yet) | 12:49 |
| mup | PR snapd#3372 opened: tests: add basic lxd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3372> | 12:54 |
| mpt | zyga, thanks, will do | 13:12 |
| mup | PR snapd#3368 closed: tests: update listing test to the core version number schema <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3368> | 13:45 |
| Son_Goku | mvo: we're going to need something like series for base snaps | 13:48 |
| Chipaca | Son_Goku: like, tracks? | 13:48 |
| Son_Goku | well, tracks don't work in this sense | 13:49 |
| Son_Goku | because tracks are essentially channels | 13:49 |
| Son_Goku | whereas a fedora 25 base, a fedora 26 base, and so on would be available in parallel in the same channel | 13:49 |
| Son_Goku | with the ubuntu-core/core snap, you have the series property to give you guardrails | 13:50 |
| Son_Goku | snaps can be bound to a particular series | 13:50 |
| ogra_ | mvo, hmm ... i got this worn out SD card wheer every n'th core update results in a corrupt uboot.env ... i noticed that if i do a manual refresh and call sudo sync before reboot, i never get the corruption ... looking at https://github.com/mvo5/uboot-go/blob/master/uenv/env.go#L234 i see we are actually calling f.Sync(), should that actually be the same as me calling sync manually ? | 13:51 |
| ogra_ | (i have the feeling it isnt) | 13:51 |
| ogra_ | (also ... shouldnt that eventually move into the snapd tree ?) | 13:52 |
| ogra_ | hmm, actually f.Sync() might only apply to the file, not acrtually flush the os buffers ... | 13:53 |
| Son_Goku | Chipaca, basically, since it's not possible to version snaps, there's no easy way to constrain things properly | 13:53 |
| Chipaca | ogra_: sync manually would also call sync on the directory, which we should be doing as well | 13:54 |
| Chipaca | Son_Goku: how is this series different from having a snap called 'fedora-25', say? | 13:55 |
| ogra_ | Chipaca, well, sudo sync should actually flush all buffers to disk ... i think f.Sync() in that code above only cares that the file content gets written to the buffer | 13:55 |
| ogra_ | (but not necessarily that the kernel writes to disk) | 13:56 |
| Chipaca | ogra_: no, f.Sync calls fsync on the file descriptor | 13:56 |
| Chipaca | it's not python's flush | 13:56 |
| Chipaca | but | 13:56 |
| ogra_ | right | 13:56 |
| Chipaca | that code as it stands would lead to corruption | 13:57 |
| Chipaca | because it changes the size of the file | 13:57 |
| Chipaca | and doesn't sync the directory | 13:57 |
| ogra_ | the size of the file is fixed | 13:57 |
| Son_Goku | Chipaca: *shrugs* | 13:57 |
| ogra_ | cant change | 13:57 |
| ogra_ | it shoudl only switch bytes | 13:57 |
| Chipaca | oh? | 13:57 |
| Son_Goku | Chipaca: why is there a "series" attribute if that would have worked before? | 13:58 |
| ogra_ | its a binary blob file ... uboot would fall over if the size changed | 13:58 |
| Chipaca | Son_Goku: snappy with a series != 16 was a completely different beast to what it is today | 13:58 |
| Chipaca | Son_Goku: "series" as it stands is a property of the system, not of a particular snap | 13:59 |
| Son_Goku | so it's an assumption for an ubuntu core system | 14:00 |
| Chipaca | Son_Goku: i'm not saying you're wrong, mind you! I don't know if you are. I'm saying it's not what series is today. | 14:00 |
| Son_Goku | hm | 14:00 |
| Son_Goku | Chipaca: one of my goals is to figure out a path to a Snappy Fedora system | 14:00 |
| Son_Goku | otherwise, what's the point? :P | 14:00 |
| Chipaca | :-) | 14:00 |
| Chipaca | Son_Goku: I understand. My question about smashing it into the name is because it often unblocks us to do the simplest thing possible, even if it's slightly ugly, and especially when otherwise we'd need a BDUF | 14:01 |
| Son_Goku | there was some interest from Matthew Miller (the Fedora Project Leader) on officially providing Fedora runtimes for Snappy among other things | 14:02 |
| Son_Goku | especially as part of the Modularity initiative going on right now: https://docs.pagure.org/modularity/ | 14:03 |
| Son_Goku | so runtimes, application snaps, etc. | 14:03 |
| Son_Goku | there's several blockers in the way of that, but hopefully we can chip away at them | 14:03 |
| ogra_ | Chipaca, aha ... unix.Syscall(unix.SYS_SYNCFS, ... ) from https://godoc.org/golang.org/x/sys/unix seems to implement syncfs, i guess thats what we are missing there | 14:13 |
| cachio | niemeyer, I have 3 real machines to use to run spread tests if you want | 14:17 |
| cachio | niemeyer, I mean, instead of using linode | 14:17 |
| ogra_ | adfad666, zyga, in case you didnt find that yet, u-boot build instructions for the pi u-boots are in the REAME.md of the gadget tree | 14:21 |
| * ogra_ just noticed that missed friday night ping ... | 14:22 | |
| mup | PR snapd#3373 opened: snapstate: consider connect/disconnect tasks in CheckChangeConflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/3373> | 14:22 |
| zyga | ogra_: thanks! | 14:24 |
| zyga | Son_Goku: woot :)" | 14:24 |
| zyga | Son_Goku: I think that's well on our path and already started by mvo (and soon followed by myself) | 14:24 |
| zyga | Son_Goku: I think by the time we hit the sprint we may have a good chunk of the basics in place to try a !default runtime | 14:24 |
| zyga | Son_Goku: as we can make runtimes by hand really | 14:25 |
| zyga | speaking of which | 14:25 |
| zyga | I need to pick up kids from school | 14:25 |
| niemeyer | cachio: These will certainly be useful when working through issues, but using Linode means you get the exact same environment that runs every other test in our automated CI, so we should use that as our litmus test | 14:29 |
| niemeyer | cachio: Let me get you a key | 14:29 |
| mvo | ogra_: just reading backlog | 14:30 |
| fgimenez | hi morphis, do you know how to use the network-manager snap to control eth0 on an amd64 ubuntu-core system? "network-manager.nmcli d status" says eth0 is unmanaged | 14:31 |
| ogra_ | niemeyer, regarding your comment on https://github.com/snapcore/snapd/pull/3316 ... where do i find anything about the convention regarding summaries of PRs ? neither HACKING.md nor CONTRIBUTING.md speak about the format of a summary anywhere | 14:39 |
| mup | PR snapd#3316: make /etc/localtime writable in timezone_control <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3316> | 14:39 |
| niemeyer | ogra_: The full detailing is in the mailing list history.. need to bring that into the forum. Just looking through the PR list should give a hint, though. | 14:41 |
| ogra_ | ok | 14:42 |
| Chipaca | ogra_: https://chris.beams.io/posts/git-commit/ | 14:46 |
| mvo | ogra_: I have a branch ready that adds dirsync, if you can reliable reproduce the issue I would love to get feedback if the dirsync one fixes it, let me know if a branch is enough | 14:47 |
| ogra_ | Chipaca, you mean i should just write "haaands" ? | 14:47 |
| Chipaca | ogra_: of course, what else | 14:47 |
| mup | PR snapd#3374 opened: partition: add directory sync to the save uboot.env file code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3374> | 14:47 |
| * ogra_ grins | 14:47 | |
| ogra_ | mvo, well, as i understand it, go apps should always call syncfs on exit automatically ... but the upgrade always ends with an endless "[\] Setup snap "core" (2008) security profiles (phase 2)" ... for the manual sync i need to ctrl-c that first ... i wonder if the non-exiting state of the process simply prevents the syncing | 14:50 |
| pstolowski | zyga, re your comment about sc_context_cookie - are you suggesting to pass this around as a return value from the function etc. instead of char*? (makse sense if that's what you mean) | 14:51 |
| ogra_ | i.e. when there is an auto-reboot, the process will go on until the os reboots | 14:51 |
| === chihchun is now known as chihchun_afk | ||
| mvo | ogra_: interessting, even then it should be gracefully shut down, but if the above branch (3374) could be tested, that would be great. let me know if you need anything from me, i.e. if I should build you a snapd binary or anything | 14:53 |
| mup | PR snapd#3375 opened: snapstate,many: implement snap install --unaliased <Created by pedronis> <https://github.com/snapcore/snapd/pull/3375> | 14:56 |
| ogra_ | mvo, hmm, that might be a bit tricky ... i could indeed re-pack the core snap with a new snapd but then i cant easily test auto-upgrades, perhaps we could try to just land the PR tomorrow morning with the option to roll back immediately | 14:57 |
| ogra_ | (snap refresh manually or a sideload will likely not expose the issue, i usually only see it with auto-upgrade) | 14:58 |
| adfad666 | ogra_: I found the instructions in pi3-gadget, but they're _not_ in the pi2-gadget readme :) | 15:00 |
| ogra_ | adfad666, ahm, thanks for the hint, i'll add them there too (the u-boot binaries are actually identical in booth) | 15:00 |
| ogra_ | *both | 15:01 |
| mvo | ogra_: sounds good, it should definitely not hurt (the extra code) | 15:02 |
| ogra_ | mvo, yeah | 15:03 |
| ogra_ | i'll ping you tomorrow and we can coordinate some testing (nothing for this evening IMHO) | 15:03 |
| mup | PR snapd#3376 opened: store: retry on 504 too <Created by pedronis> <https://github.com/snapcore/snapd/pull/3376> | 15:03 |
| pedronis | pstolowski: does snapd#3376 look right ? (doesn't seem we test the single codes) | 15:03 |
| mup | PR snapd#3376: store: retry on 504 too <Created by pedronis> <https://github.com/snapcore/snapd/pull/3376> | 15:03 |
| mvo | ogra_: thanks, sounds good | 15:05 |
| pstolowski | pedronis, yes, looks fine, that's the central place that drives all retry loops | 15:05 |
| pedronis | mvo: all my main 2.27 PRs are up | 15:08 |
| * Chipaca leaves spread running and goes to scrounge up some tea | 15:10 | |
| * Chipaca fails, tries again | 15:12 | |
| niemeyer | Lunches | 15:12 |
| pedronis | fgimenez: linode:ubuntu-16.04-32:tests/main/create-key timeout : https://travis-ci.org/snapcore/snapd/builds/234847301 | 15:36 |
| fgimenez | pedronis: thanks! looking | 15:36 |
| Chipaca | just got another 504 | 15:37 |
| pedronis | Chipaca: there's a PR now | 15:37 |
| Chipaca | :-( | 15:37 |
| pedronis | Chipaca: if it helps: snapd#3376 | 15:37 |
| mup | PR snapd#3376: store: retry on 504 too <Created by pedronis> <https://github.com/snapcore/snapd/pull/3376> | 15:37 |
| Chipaca | each of these retries hurts responsiveness | 15:38 |
| Chipaca | a retry on a 504, more so | 15:38 |
| Chipaca | :-( | 15:38 |
| Pharaoh_Atem | morphis: in re http://pkgs.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/commit/redhat-hardened-ld?id=b1a45b244ea644b78b0f626643758a05c0f049b5 | 15:42 |
| Pharaoh_Atem | keep in mind that you're going to have a hard time static linking pre-F26 anyway | 15:43 |
| Pharaoh_Atem | and even in F26 itself, since we don't have a lot of static link libraries to begin with | 15:43 |
| fgimenez | pedronis: i've already copied the build log, feel free to retrigger if needed | 15:43 |
| pedronis | thx | 15:44 |
| zyga | re | 15:46 |
| zyga | pstolowski: the outside part can be anything, I just meant the 45/44 hardcoded things vs a struct with that hardcoded thing | 15:47 |
| pstolowski | zyga, hmm i see. why struct? | 15:48 |
| zyga | pstolowski: just a type, could be a typedef as well | 15:49 |
| cachio | niemeyer, I am running on this linode:ubuntu-14.04-64:tests/ , is that ok? | 15:54 |
| niemeyer | cachio: Yeah, it's okay | 15:54 |
| niemeyer | cachio: Only thing to watch out for is that once the process started, you'll have machines allocated | 15:55 |
| niemeyer | cachio: Make sure to discard them once the test is over | 15:55 |
| niemeyer | cachio: Otherwise spread elsewhere will need to collect them, and it'll only do that after 2h | 15:55 |
| niemeyer | cachio: spread -reuse allows you to keep the same machines for longer, useful if you're running one or a few tests over and over | 15:56 |
| cachio | niemeyer, should I discard them manually? | 15:56 |
| niemeyer | cachio: Yes, if you've allocated them and don't need them anymore, please do discard them | 15:57 |
| cachio | niemeyer, ok | 15:57 |
| niemeyer | cachio: If you haven't used -reuse, spread will keep a list of the used machines even then, and print out the command you need to run for discarding them | 15:57 |
| cachio | niemeyer, ok, thanks for the heads up | 15:58 |
| niemeyer | cachio: np | 15:59 |
| niemeyer | cachio: The spread docs in the GH project is also pretty comprehensive if you need more insight into a particular feature | 15:59 |
| niemeyer | s/is/are/ | 15:59 |
| zyga | cachio: also feel free to ask any one of us for help :) | 16:00 |
| cachio | niemeyer, zyga great, thanks | 16:00 |
| niemeyer | Yeah, sorry, that wasn't a tentative to drop further questions :P | 16:01 |
| mup | PR snapd#3377 opened: asserts: simplify and adjust repair assertion definition <Created by pedronis> <https://github.com/snapcore/snapd/pull/3377> | 16:13 |
| mup | PR snapd#3378 opened: tests: fixes for executions using the staging store <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3378> | 16:19 |
| === cachio is now known as cachio_lunch | ||
| mup | PR snapd#3367 closed: many: cleanup MockCommands and don't leave a process around after hookstate tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3367> | 16:35 |
| morphis | Pharaoh_Atem: true, but we can't change our snap-confine build setup easily right now so best is the keep it this way if there are no objections from your side | 16:38 |
| Pharaoh_Atem | I'm probably not going to drop the patch we use in Fedora, as I'd rather not maintain the flags locally | 16:39 |
| Chipaca | ogra_: https://github.com/snapcore/snapd/pull/3369/files#diff-1c49786329169770afff179a078fd8f1L114 | 16:42 |
| mup | PR snapd#3369: many: make shell scripts shellcheck-clean <Created by chipaca> <https://github.com/snapcore/snapd/pull/3369> | 16:42 |
| Chipaca | and now i need an aspirin | 16:42 |
| morphis | Pharaoh_Atem: we can't ship it upstream either as it breaks the static build we have for other platforms | 16:46 |
| morphis | Pharaoh_Atem: however this is a bug in the linker script provided by Fedora as it break static builds (even if there are not many static libs we can link with) | 16:47 |
| Pharaoh_Atem | well, the build fails even if we attempted static link | 16:50 |
| ralsina | Hi! Question: I am snapping a largish python app, and it brings a ton of uneeded files, which make the snap almost 80MB. I know I can delete a bunch of them and bring it down to half size. Is there any support in snapcraft for removing files before snapping? | 16:50 |
| Pharaoh_Atem | since libcap-static doesn't exist | 16:50 |
| morphis | Pharaoh_Atem: the build succeeds but it links libcap dynamically with the change I did above | 16:51 |
| ralsina | Specifically, just removing useless .a files from static libraries cuts down 35MB in the final snap | 16:51 |
| ogra_ | Chipaca, elegant! | 16:52 |
| morphis | Pharaoh_Atem: https://paste.fedoraproject.org/paste/5v-vkBtY0mnerN~IgVOphF5M1UNdIGYhyRLivL9gydE= -> that is with snapd master from minutes ago | 16:53 |
| zyga | Chipaca: do you know why the latest core snap is from 18th? | 16:54 |
| niemeyer | zyga: Do you have a moment for a quick call? | 16:54 |
| zyga | niemeyer: yes | 16:54 |
| Chipaca | zyga: npi | 16:54 |
| niemeyer | Cool, let's go to the standup please | 16:54 |
| Chipaca | niemeyer: wrote something for the report, but nothing is particularly newsworthy imho | 17:03 |
| Chipaca | (so if you decide to ignore my contribution I'd be relieved :-) ) | 17:03 |
| niemeyer | Chipaca: :D | 17:04 |
| niemeyer | Chipaca: Thanks! | 17:04 |
| mup | PR snapd#3355 closed: tests/main/snap-info: don't use named parameter for print statement <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3355> | 17:07 |
| morphis | zyga: ok to merge https://github.com/snapcore/snapd/pull/3274 ? | 17:24 |
| mup | PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274> | 17:24 |
| === cachio_lunch is now known as cachio | ||
| lutostag | launchpad builders failing for others with 'cannot run ssh: No such file or directory'? http://pastebin.ubuntu.com/24625153/ full build log @ https://launchpadlibrarian.net/320734938/buildlog_snap_ubuntu_xenial_amd64_weebl-tools_BUILDING.txt.gz | 17:29 |
| lutostag | (from a launchpad hosted git repo) | 17:30 |
| mup | PR snapd#3376 closed: store: retry on 504 too <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3376> | 17:30 |
| cjwatson | lutostag: You can't use git+ssh - the builders don't have SSH keys | 17:30 |
| cjwatson | lutostag: I'm afraid snap builds from private repositories aren't currently supported | 17:31 |
| lutostag | cjwatson: https://code.launchpad.net/~lutostag/+snap/weebl-tools/+edit (how do I create a snap package for an already existing git repo from lp then)? should the protocol default to https rather than git+ssh for them? | 17:31 |
| lutostag | https://code.launchpad.net/~weebl-maintainers/weebl-tools/+git/weebl-tools/+ref/master I don't think is private... | 17:32 |
| cjwatson | It would if https were supported for private repositories yet | 17:32 |
| cjwatson | lutostag: But that's not the repository you're trying to build from here | 17:32 |
| Chipaca | and *another* 504 | 17:32 |
| Chipaca | grr grr grr | 17:32 |
| cjwatson | Or at least, the part in question | 17:32 |
| cjwatson | The problem is https://git.launchpad.net/weebl-tools/tree/snap/snapcraft.yaml#n19 | 17:33 |
| pedronis | Chipaca: I merged the retry branch now (if it helps) | 17:33 |
| lutostag | cjwatson: indeed, that would be it. Thanks! (also congrats on the spotlight) | 17:34 |
| cjwatson | lutostag: thanks :) sorry this isn't supported yet; it's possible but would probably be a month or so of work. | 17:34 |
| cjwatson | maybe a bit less given some of the work on git-to-git imports which picked off some of the infrastructure dependencies. | 17:35 |
| lutostag | cjwatson: yeah, private ppas never had building either, so at least its not missing functionality compared to ppas, just the error message threw me off | 17:35 |
| cjwatson | lutostag: Private PPAs have builds, but maybe you mean recipes | 17:35 |
| lutostag | yeah that one :) | 17:35 |
| cjwatson | lutostag: In which case that's indeed true, and for similar reasons | 17:36 |
| cjwatson | Basically need a way to dispatch scoped auth tokens to builders; in the snap case we also need to sort out a privacy model for snaps | 17:36 |
| lutostag | cjwatson: no worries, easy enough to snapcraft locally. Forgot about our 'private' dep. appreciate it | 17:37 |
| zyga | morphis: looking | 17:38 |
| zyga | morphis: if niemeyer looked at that and approved, sure, let me see | 17:38 |
| morphis | zyga: he did but before the rework but said he is fine if I do what he suggested | 17:38 |
| zyga | done :) | 17:39 |
| morphis | great! | 17:39 |
| morphis | another bit merge :-) | 17:39 |
| mup | PR snapd#3274 closed: cmd/snap,tests/main: add confinement switch instead of spread system blacklisting <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3274> | 17:39 |
| kyrofa | Chipaca, from the store | 17:39 |
| kyrofa | ? | 17:40 |
| Chipaca | kyrofa: yeap | 17:40 |
| Chipaca | have been hitting a bunch of them todya | 17:40 |
| Chipaca | hence the growling and groaning | 17:41 |
| kyrofa | I hit soo many last week | 17:41 |
| mup | PR snapd#3379 opened: cmd/snap,tests: show the snap id if available in snap info <Created by pedronis> <https://github.com/snapcore/snapd/pull/3379> | 17:42 |
| mup | PR snapd#3380 opened: cmd/snap,tests: show the sha3-384 of the snap for snap info --verbose SNAP-FILE <Created by pedronis> <https://github.com/snapcore/snapd/pull/3380> | 17:42 |
| cachio | niemeyer, do you use -reuse to run the tests in ci? | 18:03 |
| cachio | I see that $GOPATH is not being cleaned and it is making a test failed when -reuse is used | 18:04 |
| niemeyer | cachio: Depends on what I'm working on.. if I'm trying something several times, yeah, definitely as it saves quite some time | 18:04 |
| mup | PR snapd#3381 opened: logger (& many more, to accommodate): drop explicit syslog <Created by chipaca> <https://github.com/snapcore/snapd/pull/3381> | 18:12 |
| ogra_ | abeato, on what HW do you test all this androidboot stuff ? dragonboard ? | 18:16 |
| mup | PR snapd#3382 opened: daemon,overlord/auth: store from model assertion wins <Created by pedronis> <https://github.com/snapcore/snapd/pull/3382> | 18:25 |
| abeato | ogra_, it is a qualcomm device, 4 years old iirc | 18:30 |
| === JanC_ is now known as JanC | ||
| abeato | ogra_, Qualcomm SnapdragonTM 600 (APQ8064) 1.7 GHz quad KraitTM CPU | 18:31 |
| zyga | re | 18:37 |
| ryebot | I'm running into this issue on 2.25, even though it was supposed to be fixed in 2.25: https://bugs.launchpad.net/snappy/+bug/1687079 | 19:09 |
| mup | Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079> | 19:09 |
| ryebot | Here's my logs: http://paste.ubuntu.com/24625861/ | 19:10 |
| ryebot | Any suggestions for debugging/working around? | 19:10 |
| ryebot | Ah, before I forget to mention - this is in an lxc. | 19:14 |
| zyga | ryebot: looking | 19:14 |
| ryebot | ty | 19:14 |
| zyga | ryebot: can you tell me what does snap version say? | 19:15 |
| zyga | ryebot: specifically about your kernel | 19:15 |
| ryebot | yes one moment | 19:15 |
| ryebot | zyga: http://paste.ubuntu.com/24626012/ | 19:15 |
| zyga | ryebot: aha, so this is on a stock ubuntu kernel, hmm hmm | 19:16 |
| zyga | ryebot: container support requires an interplay of both lxd, snapd and kernel features | 19:16 |
| zyga | ryebot: but it seems this combination should work | 19:16 |
| ryebot | zyga: I think it works if I restart the container | 19:17 |
| ryebot | at least, that's what has been reported to me, haven't tried it myself | 19:17 |
| zyga | ryebot: are you the reporter of bug https://bugs.launchpad.net/snappy/+bug/1687079 ? | 19:17 |
| mup | Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079> | 19:17 |
| ryebot | I am not | 19:17 |
| zyga | ryebot: can you try one more thing | 19:17 |
| zyga | export SNAP_CONFINE_DEBUG=yes | 19:18 |
| zyga | and run the command you wanted to run just a moment ago | 19:18 |
| ryebot | hmm | 19:18 |
| ryebot | this is a service | 19:18 |
| zyga | aha | 19:18 |
| * ryebot thinks | 19:18 | |
| zyga | but | 19:18 |
| zyga | try hello-world snap | 19:18 |
| ryebot | okay | 19:18 |
| zyga | if the service fails this should fail the same way | 19:18 |
| ryebot | I'll try without export first? | 19:18 |
| zyga | sure | 19:19 |
| zyga | though with export you'll get more data | 19:19 |
| ryebot | hello world worked fine | 19:19 |
| zyga | hmm hmm | 19:19 |
| zyga | interesting | 19:19 |
| zyga | what was the service? | 19:19 |
| zyga | and can you look at journalctl and look for something obviously wrong? | 19:19 |
| ryebot | sure, it was the etcd snap | 19:20 |
| zyga | ah | 19:20 |
| ryebot | here's the logs: http://paste.ubuntu.com/24625861/ | 19:20 |
| zyga | is that a classic snap? | 19:20 |
| zyga | classic confinement snap | 19:20 |
| ryebot | let me double check | 19:20 |
| zyga | when you installed it, did you use --classic switch? | 19:20 |
| ryebot | it's not classically confined | 19:21 |
| ryebot | stric confinement | 19:21 |
| ryebot | strict* | 19:21 |
| zyga | ryebot: is that what snap list / snap info say as well? | 19:21 |
| zyga | stgraber: ^^ any ideas? (snapd fails in lxd) | 19:22 |
| ryebot | zyga: hmm, maybe not? http://paste.ubuntu.com/24626094/ | 19:23 |
| ryebot | ^ not sure how to interpret that | 19:23 |
| zyga | ingest/stable: ingest-0.5 (12) 4kB classic | 19:23 |
| ryebot | yeah | 19:23 |
| zyga | can you show me "snap changes" | 19:23 |
| ryebot | sure one sec | 19:23 |
| ryebot | http://paste.ubuntu.com/24626099/ | 19:24 |
| zyga | ryebot: how about "snap change 2" | 19:24 |
| ryebot | learning all kinds of tricks! http://paste.ubuntu.com/24626116/ | 19:25 |
| zyga | hmm hmm | 19:27 |
| * zyga thinks | 19:27 | |
| Chipaca | zyga: those 'cannot connect core' messages are my most favourite feature | 19:28 |
| ryebot | zyga: ah dang, it may very well be being installed as classic | 19:29 |
| zyga | Chipaca: I'm glad we removed those | 19:29 |
| ryebot | zyga: https://github.com/juju-solutions/layer-etcd/blob/master/reactive/etcd.py#L257 | 19:29 |
| Chipaca | zyga: yeah | 19:29 |
| ryebot | ^ from our charm code | 19:29 |
| Chipaca | zyga: (also: "snap tasks" :-) ) | 19:29 |
| ryebot | let me find out why :\ | 19:29 |
| zyga | aha | 19:29 |
| zyga | interesting | 19:29 |
| zyga | ryebot: can you pastebin /var/lib/snapd/seccomp/profiles/snap.etcd.etcd | 19:30 |
| zyga | that's an easy way to check if it is classic or not | 19:30 |
| ryebot | zyga: http://paste.ubuntu.com/24626160/ | 19:31 |
| zyga | yes | 19:31 |
| zyga | that is classic! | 19:31 |
| zyga | but | 19:32 |
| zyga | Chipaca: ^^ | 19:32 |
| zyga | the thing that puzzles me | 19:32 |
| zyga | is that this snap probably doesn't want classic | 19:32 |
| zyga | ryebot: at which revision are you now? | 19:32 |
| zyga | ryebot: (snap list says this) | 19:32 |
| ryebot | 55 | 19:32 |
| zyga | ok | 19:33 |
| zyga | so | 19:33 |
| zyga | to fix this | 19:33 |
| zyga | drop the classic=True | 19:33 |
| zyga | Chipaca: ^^ we install things as classic even though they don't want that! | 19:33 |
| Chipaca | zyga: pardon? | 19:34 |
| zyga | Chipaca: one sec | 19:34 |
| zyga | sudo snap install --classic hello-world | 19:34 |
| zyga | why is that even working!? | 19:34 |
| zyga | Chipaca: this then gets installed as classic | 19:35 |
| Chipaca | well, you did just tell it to | 19:35 |
| zyga | Chipaca: but snap list doesn't say this | 19:35 |
| ryebot | zyga: Okay awesome, I'll give it a shot, thanks :) | 19:35 |
| zyga | Chipaca: but the snap is not compatible with this at all (hello-world works by accident) | 19:35 |
| zyga | Chipaca: it must fail | 19:35 |
| Chipaca | zyga: I suspect you have more restrictions on the mode flags in your mind than we have in the code | 19:35 |
| Chipaca | zyga: torum fopic! | 19:36 |
| zyga | Chipaca: yes | 19:36 |
| zyga | Chipaca: that's a good idea :) | 19:36 |
| Chipaca | zyga: spoonerisms always are | 19:36 |
| pedronis | so --classic is its own --jailmode? otoh classic snaps are very special so there is some logic to zyga's worry | 19:40 |
| Chipaca | yeaup | 19:40 |
| Chipaca | anyway. Why am I on IRC and not having beer and tinkering with stuff. | 19:40 |
| cachio | zyga, do you have any flaky which I could take a look | 19:54 |
| cachio | zyga, I just found 2 after many executions | 19:54 |
| zyga | cachio: hey | 20:23 |
| zyga | cachio: yes, many | 20:23 |
| zyga | cachio: look at ... | 20:23 |
| cachio | zyga, good | 20:23 |
| zyga | well | 20:23 |
| zyga | first of all, look at https://github.com/snapcore/snapd/pulls | 20:24 |
| zyga | all the red PRs are good candidates | 20:24 |
| zyga | open first batch (say, first three) | 20:24 |
| zyga | then look at the one with failing tests there | 20:24 |
| zyga | (each PR has autopackage tests as well as travis run that uses spread to test various distributions on x86 and x86_64) | 20:25 |
| zyga | e.g. looking at https://github.com/snapcore/snapd/pull/3382 I can see that some tests failed | 20:25 |
| mup | PR snapd#3382: daemon,overlord/auth: store from model assertion wins <Created by pedronis> <https://github.com/snapcore/snapd/pull/3382> | 20:25 |
| zyga | then looking there I can see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170522_200637_17c34@/log.gz | 20:25 |
| zyga | scroll to the bottom | 20:25 |
| zyga | this tells me that autopkgtest:ubuntu-17.10-amd64:tests/main/refresh-core-with-hanging-configure-hook failed | 20:25 |
| zyga | look at the various branches and see if something fails frequently | 20:26 |
| zyga | sometimes master is broken and all the tests fail the same way | 20:26 |
| zyga | e.g. today this broke https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170522_172242_a32b2@/log.gz | 20:26 |
| zyga | the format of the version string printed by "snap --version" has changed | 20:26 |
| zyga | and it failed universally everywhere | 20:27 |
| zyga | when that happens it is good to get the fix merged ASAP (it's done for this case) | 20:27 |
| zyga | and then merge master into all the open PRs | 20:27 |
| zyga | we can push changes to PRs that are open, even if someone else made them | 20:27 |
| zyga | our spread setup does not use a queue so we must not overload the pool of available machines | 20:28 |
| zyga | you'll see when that happens, machine allocations will time out and fail | 20:28 |
| zyga | anyway | 20:28 |
| zyga | it is good to do when most of europe is away already as spread is very idle then | 20:28 |
| zyga | and we can have fresh results in the morning | 20:28 |
| zyga | let me know if you have questions about anything | 20:28 |
| zyga | I'll let you know if I see something that ought to work | 20:29 |
| zyga | but it's also good to be proactive and chase things | 20:29 |
| cachio | zyga, ok I'am taking a look to that list | 20:29 |
| zyga | cachio: I opened this forum thread a while ago https://forum.snapcraft.io/t/chasing-unreliable-tests/158 | 20:30 |
| cachio | zyga, nice | 20:31 |
| cachio | zyga, is it better either to create a thread with errors to discuss or to raise issues in lp? | 20:32 |
| cachio | zyga, how do you usually do that | 20:32 |
| cachio | ? | 20:32 |
| zyga | cachio: I think forum works better, lp lacks text formatting | 20:33 |
| zyga | cachio: I virtually stopped using bugs | 20:33 |
| cachio | zyga, good | 20:33 |
| === nacc_ is now known as nacc | ||
| mup | Bug #1676928 changed: snap shell can't reach $SNAP_USER_DATA: Permission denied <cdo-qa> <Snapcraft:Invalid> <Snappy:Confirmed> <https://launchpad.net/bugs/1676928> | 21:21 |
| mup | Bug #1607710 changed: Home directories listed in /etc/passwd should be honoured <cpc> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710> | 21:27 |
| nacc | is there any guidance on LP: #1575593 for a classic snap? I really don't want to add a configure hook for the manpage in my snap until uninstall hooks are present. And cjwatson's c#4 only sort of works in that (afaict), I don't control where in $SNAP my files get placed. Specifically, if the command is invoked as /snap/bin/git-ubuntu, I don't think I can put whatever I want in /snap/ ... my snap's file are | 21:40 |
| mup | Bug #1575593: Snappy installed manpages aren't accessible through man <snapd:Triaged> <https://launchpad.net/bugs/1575593> | 21:40 |
| nacc | elsewhere in /snap and bin is just symlinks | 21:40 |
| zyga | nacc: sorry, too tired to think and respond tonight | 21:43 |
| zyga | nacc: I'm working on something that _may_ enable man pages | 21:43 |
| zyga | nacc: but not soon (think 2 releases at least) | 21:43 |
| nacc | zyga: ok, np -- even workarounds that are reasonable for a bit is what i'm looking for | 22:07 |
| nacc | zyga: as, by default, `git ubuntu --help` runs `man git ubuntu` | 22:07 |
| nacc | hrm, also, can a snapd developer subscribe and help resolve degraded services in containers in LP: #1576341? Not sure who is best to subscribe to the bug myself | 22:25 |
| mup | Bug #1576341: systemd in degraded state on startup in LXD containers <amd64> <apport-bug> <patch> <uec-images> <xenial> <lvm2 (Ubuntu):Fix Released by nacc> <lxd (Ubuntu):Invalid> <open-iscsi (Ubuntu):Fix Committed by nacc> <systemd (Ubuntu):Fix Released by xnox> <https://launchpad.net/bugs/1576341> | 22:25 |
| kyrofa | cjwatson, can I publish snaps to branches in LP? | 23:57 |
| nacc | kyrofa: do you mean the other way around? | 23:58 |
| nacc | kyrofa: publish a snap off a branch specifically (rather than master, say)? | 23:58 |
| kyrofa | nacc, no snaps have a relatively new feature called branches | 23:59 |
| kyrofa | nacc, https://forum.snapcraft.io/t/channel-terminology-and-policy | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
