| mwhudson | oy slackers get https://github.com/mvo5/net/commit/0c0cd2628b36f2b053b7cc1ec04b76aab4c5189c upstream pls | 01:20 |
|---|---|---|
| mwhudson | or at least try | 01:20 |
| mwhudson | ah https://github.com/golang/go/issues/20556 | 01:24 |
| === chihchun_afk is now known as chihchun | ||
| zyga-arch | good morning | 06:40 |
| mup | PR snapd#3638 opened: packaging: add current arch packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/3638> | 06:40 |
| zyga-arch | janisozaur1: https://github.com/snapcore/snapd/pull/3638 | 06:41 |
| mup | PR snapd#3638: packaging: add current arch packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/3638> | 06:41 |
| zyga-arch | that's the current packaging | 06:41 |
| zyga-arch | so there's a nice way to review changes later | 06:41 |
| zyga-arch | I'll merge this as soon as I can | 06:41 |
| mwhudson | zyga-arch: o/ | 06:56 |
| zyga-arch | hey | 06:56 |
| mwhudson | you have mail | 06:56 |
| mwhudson | s | 06:56 |
| mwhudson | even | 06:56 |
| mwhudson | but i'm not really here for an hour or so so no hurry :) | 06:56 |
| * zyga-arch looks | 06:56 | |
| zyga-arch | mwhudson: aha | 06:58 |
| zyga-arch | mwhudson: thank you for pointing that out and finding it | 06:59 |
| zyga-arch | mwhudson: I think that mvo may be on holidays still, if he's back we should pursue this | 07:00 |
| === ikey|afk is now known as ikey | ||
| zyga-arch | jamesh: hey | 07:19 |
| jamesh | hi zyga-arch | 07:19 |
| pstolowski | jamesh, hey! :) | 07:20 |
| zyga-arch | I replied to the thread with you and jdstrand | 07:21 |
| zyga-arch | please have a look and if you want to discuss something quickly now, let's do it | 07:21 |
| jamesh | zyga-arch: thanks. reading | 07:21 |
| jamesh | hi pstolowski | 07:21 |
| jamesh | zyga-arch: do you currently ever update the persistent namespaces rather than throwing them away to start over? | 07:22 |
| janisozaur1 | zyga-arch: nice, but I see some unrelated(?) test failed on travis? | 07:22 |
| zyga-arch | jamesh: we update them when the fstab file (content interface and parts of layouts) change | 07:23 |
| zyga-arch | jamesh: we have a very serious bug where we don't update them on base snap change that I cannot fix because it breaks apparmor and we'd have to unconfine snap-confine | 07:24 |
| zyga-arch | jamesh: and I also forgot to meniton that snap-update-ns may need to get a new, specific, confinement for a *given snap* as it will process snap-specific mount profile | 07:24 |
| zyga-arch | otherwise it must be unconfined to do that | 07:25 |
| zyga-arch | janisozaur1: yes, master is very unhappy lately | 07:25 |
| zyga-arch | janisozaur1: I ran into an issue where snap-seccomp needs to link libseccomp statically, I need to reverse that for arch | 07:25 |
| jamesh | zyga-arch: but does "update" mean changing the existing namespace in use by running processes, or only making sure new processes see the changes? | 07:25 |
| zyga-arch | yes | 07:25 |
| zyga-arch | we change it live | 07:25 |
| zyga-arch | existing processes see this | 07:26 |
| zyga-arch | the "easy" solution was nacked as this fractured the view | 07:26 |
| zyga-arch | that is essentially what snap-update-ns does | 07:26 |
| zyga-arch | jamesh: the invalidation of base snap includes snap-confine figuring out that the base snap is not the same device anymore, using the freezer cgroup to see if any process uses the namespace and discarding/rebuilding it | 07:29 |
| zyga-arch | jamesh: one more complexity is that snap-confine/snap-update-ns must work from within the constructed namespace and this brings in extra complexity (mainly around bugs in apparmor) | 07:29 |
| zyga-arch | where naive setns() to pid 1 breaks everything | 07:30 |
| jamesh | ah. I'd been concentrating on snap-confine and missed snap-update-ns | 07:31 |
| zyga-arch | there's a small PR that starts this already... | 07:31 |
| zyga-arch | https://github.com/snapcore/snapd/pull/3621 | 07:32 |
| mup | PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621> | 07:32 |
| zyga-arch | please have a look | 07:32 |
| zyga-arch | jamesh: oh, and also reexec and base snaps adds more complexity (obviously) | 07:32 |
| zyga-arch | because snap-confine needs to run snap-update-ns | 07:32 |
| zyga-arch | but the base snap may not even have a normal FHS | 07:32 |
| zyga-arch | reexec certainly adds some level of problems where we need to ensure tools use a consistent set of executables | 07:33 |
| zyga-arch | and not a mix of the two | 07:33 |
| zyga-arch | "reexec" only conceptually, really it is "using binaries from core snap" | 07:33 |
| zyga-arch | jamesh: I'll grab something for breakfast, please tell me what you think, I'll be readin | 07:36 |
| jamesh | zyga-arch: sure. I'm replying to your email with a description of what I need. | 07:38 |
| jamesh | zyga-arch: okay. Replied with some details of how xdg-document-portal works | 07:56 |
| zyga-arch | jamesh: wait, so this is /run/user/$UID/doc? | 07:57 |
| zyga-arch | jamesh: so... we need nothing? | 07:58 |
| zyga-arch | run is mounted as a slave of the host /run | 07:58 |
| zyga-arch | so if you mount /run/whatever on the host this automatically works in the snap | 07:58 |
| zyga-arch | no user-specific mount namespaces necessary | 07:59 |
| zyga-arch | just make sure this is mounted on from the session and not from the snap (since it is a slave of the peer group) | 07:59 |
| zyga-arch | does that make sense or am I prematurely enthusiastic? | 07:59 |
| jamesh | zyga-arch: it is a different bind mount per package | 08:01 |
| zyga-arch | per-package? | 08:01 |
| jamesh | yes | 08:01 |
| jamesh | read on a bit further :) | 08:01 |
| zyga-arch | ok | 08:01 |
| jamesh | the daemon produces per-package subdirectories inside the fuse file system that get mounted at /run/user/$UID/doc | 08:02 |
| zyga-arch | aha | 08:02 |
| zyga-arch | so we're back to square one | 08:03 |
| jamesh | presumably because a fuse daemon doesn't know what pid originates each request, and/or the kernel may cache inode information between requests | 08:03 |
| zyga-arch | are you familiar with bubblewrap and how flatpak uses it? | 08:04 |
| zyga-arch | what's the mount namespace story there? | 08:04 |
| jamesh | it builds a new namespace for each instance of the app | 08:04 |
| zyga-arch | jamesh: so snapd 2.0.2 story | 08:04 |
| jamesh | it doesn't try to share or update existing namespaces | 08:04 |
| zyga-arch | jamesh: how does it access process specific namespace? just via /proc/$PID/ns/mnt? | 08:05 |
| jamesh | (at least that's what I understood from reading it) | 08:05 |
| zyga-arch | ohhh | 08:05 |
| zyga-arch | and it's also FUSE | 08:05 |
| zyga-arch | man | 08:05 |
| zyga-arch | all the stars align to spell "oblivion" | 08:05 |
| zyga-arch | rbind is just a set of recursively created bind mounts *at the time you call mount* | 08:06 |
| zyga-arch | further changes are propagated using peer groups | 08:06 |
| zyga-arch | so if I do a change in one process | 08:06 |
| zyga-arch | and another process shares that peer group | 08:06 |
| zyga-arch | and is a slave | 08:06 |
| zyga-arch | it will see the change (things get mounted) | 08:07 |
| zyga-arch | if a slave does a change the master won't see it | 08:07 |
| jamesh | but does it break the master/slave relationship if the slave makes changes? | 08:07 |
| zyga-arch | there are a few sharing modes (private, shared, slave, master, and one more I forgot) | 08:07 |
| zyga-arch | no | 08:07 |
| zyga-arch | slave can make changes that only it will see | 08:07 |
| zyga-arch | so if you think about making changes to /run from within the snap namespace they won't propagate outwards | 08:08 |
| jamesh | so if the process creates a new mount namespace as a slave rbind of the persistent namespace and then mounts the document portal over the top, things might work? | 08:08 |
| zyga-suse | well, not sure, the sharing is per *mount point* | 08:09 |
| zyga-suse | one sec | 08:09 |
| zyga-suse | https://forum.snapcraft.io/t/feature-snap-layouts/1471 | 08:11 |
| zyga-suse | there's a link to how peer groups function there | 08:11 |
| zyga-suse | https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt | 08:11 |
| zyga-suse | so assuming we still need the user mount namespace | 08:11 |
| zyga-suse | and that it *probably* has to be persistent too | 08:12 |
| zyga-suse | (for that users) | 08:12 |
| jamesh | https://github.com/projectatomic/bubblewrap/blob/master/bubblewrap.c <- that's the bubblewrap code. It definitely isn't trying to share namespaces | 08:13 |
| zyga-suse | we could do a bind mount from /run/user/doc/by-app (which is tricky if >1 app is in a snap) to /run/user/doc | 08:13 |
| jamesh | zyga-suse: treat by-app as by-package | 08:13 |
| jamesh | my proof of concept patches were doing permissions at the package level, since that seemed most sane | 08:14 |
| jamesh | for flatpak, apps == packages so they are a bit loose with that terminology | 08:15 |
| zyga-arch | right | 08:17 |
| zyga-arch | but in our model one snap can ship two flatpaks really | 08:17 |
| zyga-arch | hmm | 08:18 |
| jamesh | right. I'm just saying that the "by-app" directory inside the document portal file system is effectively per-package | 08:21 |
| jamesh | If you give one app from a snap access to a document, there isn't much to stop it giving another app from the same snap access | 08:21 |
| zyga-arch | well, we can still use apparmor | 08:23 |
| zyga-arch | ;-) | 08:23 |
| zyga-arch | but yeahg | 08:23 |
| zyga-arch | so, who does the bind mounting of all of that? | 08:23 |
| zyga-arch | the portal runtime running in the session? | 08:25 |
| mwhudson | how many zyga's is too many | 08:28 |
| jamesh | flatpak constructs a bubblewrap command line that says how to set up the sandbox | 08:29 |
| mwhudson | also 2.26.*14* ? oh dear | 08:29 |
| zyga-arch | mwhudson: well, it's just cooperative multi tasking so it's not any better than one :D | 08:29 |
| jamesh | one of the arguments tells bubblewrap to bind mount the document portal | 08:29 |
| zyga-arch | mwhudson: *yes* | 08:29 |
| zyga-arch | we found more bugs but mvo didn't want 15 | 08:29 |
| mwhudson | zyga-arch: i made a thing https://docs.google.com/spreadsheets/d/1ndk9eN5uSSY9A3SYzBRLBxOLMWw5--A2KNbS0v0y6_g/edit?usp=sharing | 08:31 |
| zyga-arch | aha, looking | 08:36 |
| zyga-ubuntu | mwhudson: I requested write access to add some notes | 08:37 |
| mwhudson | zyga-ubuntu: granted | 08:39 |
| zyga-ubuntu | mwhudson: ok, comments made | 08:40 |
| zyga-ubuntu | I think the biggest thing is the net fork | 08:40 |
| zyga-ubuntu | the gettext package seems like a low hanging fruit | 08:41 |
| mwhudson | is that only used for a test? | 08:41 |
| zyga-ubuntu | as is the go-flags update | 08:41 |
| zyga-ubuntu | gettext? | 08:41 |
| mwhudson | the net fork | 08:41 |
| zyga-ubuntu | or net? | 08:41 |
| zyga-ubuntu | I don't recall, let me check | 08:41 |
| zyga-ubuntu | but my bet is not just tests | 08:41 |
| mwhudson | git grep mvo5/net/bdf | 08:41 |
| zyga-ubuntu | mwhudson: actually | 08:43 |
| zyga-ubuntu | it seems just for tests | 08:43 |
| mwhudson | ok good | 08:43 |
| zyga-ubuntu | so we could patch that away for now | 08:43 |
| mwhudson | yeah | 08:43 |
| zyga-ubuntu | (except on big-endian arches where it works by accident) | 08:43 |
| zyga-ubuntu | Chipaca: hey hey | 08:44 |
| Chipaca | zyga-ubuntu: hiya | 08:44 |
| mwhudson | zyga-ubuntu: looks like subunit-go is unused in 2.26.14 too? | 08:45 |
| zyga-ubuntu | I had a look at weather in London today | 08:45 |
| zyga-ubuntu | 16C vs 30+ here :/ | 08:46 |
| zyga-ubuntu | I miss London | 08:46 |
| zyga-ubuntu | mwhudson: I think we never used it | 08:46 |
| zyga-ubuntu | it may have been pulled in earlier by something else | 08:46 |
| zyga-ubuntu | but not directly via snapd tests | 08:46 |
| zyga-ubuntu | no matches in grep | 08:46 |
| mwhudson | oh i guess it could be a transitive dep | 08:47 |
| mwhudson | easy to find out | 08:48 |
| zyga-ubuntu | I think it is gone totally now, I grepped in the vendor tree as well | 08:48 |
| mwhudson | zyga-ubuntu: hnngh https://github.com/mvo5/libseccomp-golang is a fork too? | 08:50 |
| zyga-ubuntu | https://github.com/mvo5/libseccomp-golang/commits/master it seems so | 08:52 |
| zyga-ubuntu | not sure if we want to package the fork | 08:52 |
| zyga-ubuntu | or work with upstream | 08:52 |
| zyga-ubuntu | aha, mvo added support for older libseccomp | 08:52 |
| zyga-ubuntu | but not sure if this is even landable | 08:52 |
| zyga-ubuntu | I think it may refer to our special-cased patched 2.1.1 from ubuntu | 08:53 |
| mwhudson | https://github.com/mvo5/goconfigparser is not a fork but the debian package is of a version that is not tagged in the repo | 08:53 |
| zyga-ubuntu | (wehre it is more like 2.2) | 08:53 |
| zyga-ubuntu | mwhudson: I think for that we can use master or ask mvo for a release | 08:53 |
| zyga-ubuntu | is that even used though? | 08:53 |
| mwhudson | yeah i don't know if it's a problem, it's just making filling this sheet out less trivial :) | 08:53 |
| zyga-ubuntu | /partition/grub_test.go:"github.com/mvo5/goconfigparser" | 08:53 |
| zyga-ubuntu | partition/grub_test.go:cfg := goconfigparser.New() | 08:53 |
| zyga-ubuntu | just in tests? | 08:54 |
| zyga-ubuntu | feels bogus | 08:54 |
| zyga-ubuntu | I think it's a leftover | 08:54 |
| zyga-ubuntu | and the test can be patched away | 08:54 |
| zyga-ubuntu | we moved to something else in the tree now | 08:54 |
| zyga-ubuntu | I think this became "partition/grubenv" | 08:55 |
| zyga-ubuntu | well, maybe, not sure | 08:55 |
| Chipaca | sigh | 09:17 |
| Chipaca | an hour and a bit wasted because 17.10 was using wayland behind my back | 09:18 |
| pedronis | Chipaca: it was one hour in the future | 09:18 |
| Chipaca | pedronis: hey, welcome back :-) | 09:18 |
| zyga-arch | Chipaca: oh? what broke? | 09:23 |
| zyga-ubuntu | Chipaca: could you please do a review of https://github.com/snapcore/snapd/pull/3636 | 09:27 |
| mup | PR snapd#3636: snap: add support for parsing snap layout section <Created by zyga> <https://github.com/snapcore/snapd/pull/3636> | 09:27 |
| mup | PR snapd#3637 closed: interfaces/unity7: allow receiving media key events in (at least) gnome-shell <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3637> | 09:27 |
| Chipaca | zyga-ubuntu: if you ssh -X into a thing that's running wayland, gtk apps start in the wayland session | 09:30 |
| * zyga-ubuntu posted https://forum.snapcraft.io/t/slow-core-downloads-breaks-tests/1521/1 | 09:32 | |
| zyga-ubuntu | Chipaca: and? | 09:32 |
| zyga-ubuntu | Chipaca: about that cache thing you mentioned | 09:32 |
| zyga-ubuntu | Chipaca: you'd be interested, I suspect | 09:32 |
| mwhudson | zyga-ubuntu: in general for the deps where snapd is way behind debian should i just propose PRs that update the snapd version? | 09:35 |
| mwhudson | and let CI decide if it works | 09:35 |
| zyga-ubuntu | mwhudson: I'd say yes | 09:35 |
| zyga-ubuntu | mwhudson: but one by one so that we can evaluate where it breaks | 09:35 |
| mwhudson | heh yes | 09:35 |
| zyga-ubuntu | thanks | 09:35 |
| mwhudson | i'm not that daft :) | 09:35 |
| pedronis | mwhudson: :) | 09:41 |
| mup | PR snapd#3638 closed: packaging: add current arch packaging <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3638> | 10:24 |
| zyga-ubuntu | wow | 10:29 |
| zyga-ubuntu | Chipaca: not quantitative, but this feels way faster | 10:29 |
| Son_Goku | hm? | 10:30 |
| Son_Goku | you mean the Arch packaging? | 10:30 |
| Son_Goku | it's deliberately designed to not be able to do a lot | 10:30 |
| Son_Goku | it's derived from how we do things in RPM, but drastically simplified | 10:31 |
| zyga-ubuntu | Son_Goku: no, I was talking to Chipaca in private about this https://forum.snapcraft.io/t/slow-core-downloads-breaks-tests/1521/2 | 10:31 |
| zyga-ubuntu | Son_Goku: a small optimization with huge wins for testing | 10:31 |
| zyga-ubuntu | Son_Goku: pre-cache heavy snaps we download | 10:31 |
| zyga-ubuntu | no coding required | 10:31 |
| Son_Goku | duh? | 10:31 |
| Son_Goku | why weren't we doing that before? | 10:31 |
| Chipaca | Son_Goku: ¯\_(ツ)_/¯ | 10:31 |
| zyga-ubuntu | effort != 0 | 10:31 |
| zyga-ubuntu | ;) | 10:31 |
| Son_Goku | I thought we were already doing that | 10:32 |
| zyga-ubuntu | and nobody cared before | 10:32 |
| Chipaca | sure, easy to say "duh" after the fact | 10:32 |
| Chipaca | :-D | 10:32 |
| zyga-ubuntu | now when it takes one failure out of a 1000 tests to break the run | 10:32 |
| Son_Goku | Chipaca: there's thing thing that I call base expectations | 10:32 |
| zyga-ubuntu | nobody expected base expectations | 10:32 |
| Son_Goku | when we do not even do system updates before running the tests anymore, I expected we were caching the snaps | 10:32 |
| zyga-ubuntu | proper caching is still not there | 10:32 |
| zyga-ubuntu | but this is a huge win | 10:32 |
| zyga-ubuntu | test took 19 minutes | 10:34 |
| mup | PR snapd#3639 opened: Update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639> | 10:34 |
| zyga-ubuntu | I'll do some tweaks and do A/B | 10:35 |
| Son_Goku | hm, does that mean that with this dep upgrade, snapd won't build on Fedora 25 anymore? | 10:35 |
| Son_Goku | Debian sid is on Go 1.8, and Fedora 25 is only on 1.7 | 10:36 |
| zyga-ubuntu | Son_Goku: dep update? | 10:37 |
| Son_Goku | [06:34:47 AM] <mup>PR snapd#3639 opened: Update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639> | 10:37 |
| mup | PR snapd#3639: Update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639> | 10:37 |
| zyga-ubuntu | ah | 10:37 |
| zyga-ubuntu | good question | 10:37 |
| mwhudson | Son_Goku: i don't think so, this is only the crypto bits, they should still support 1.7 | 10:42 |
| Chipaca | zyga-ubuntu: i have code i can push | 10:43 |
| Chipaca | actually, let me run all the unit tests first :-D | 10:43 |
| * Chipaca _thinks_ he's covered all the angles, but | 10:43 | |
| mup | PR snapcraft#1434 opened: lxd: clean with no parts should only delete <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1434> | 10:43 |
| Chipaca | basically: if the snap has a known size, and it's equal to the resume, then skip the download; and if it has a non-empty hash, check the hash | 10:44 |
| Chipaca | those ifs should make it work with the tests as they stand (and they make some sort of sense) | 10:44 |
| * mwhudson zzzz | 10:44 | |
| zyga-ubuntu | Chipaca: haha, easy prey :) | 10:45 |
| zyga-ubuntu | thank you for fixing it | 10:45 |
| zyga-ubuntu | Chipaca: will it rename .partial files that aren't "partial" too? | 10:45 |
| zyga-ubuntu | mwhudson: night night! thank you! | 10:46 |
| Chipaca | zyga-ubuntu: what does that mean? | 10:46 |
| zyga-arch | Chipaca: if I naively "snap download core" | 10:48 |
| zyga-arch | stick it as .partial in /var/lib/snapd/snaps/ | 10:48 |
| zyga-arch | will it choke? | 10:49 |
| zyga-arch | I mean, I don't mind chopping of the final byte | 10:49 |
| Chipaca | zyga-arch: yes, that's what the patch is for | 10:49 |
| zyga-arch | excellent | 10:49 |
| Chipaca | zyga-arch: no need to even talk to the server if we already have the whole thing | 10:49 |
| Chipaca | and, unit tests pass | 10:49 |
| Chipaca | if you have a pr i can push this to it | 10:50 |
| Chipaca | or | 10:50 |
| Chipaca | we can do it backwards | 10:50 |
| Chipaca | maybe easier to do it backwards :-) | 10:50 |
| zyga-ubuntu | backwards as in who goes first? | 10:52 |
| Chipaca | zyga-ubuntu: yes | 10:53 |
| Chipaca | zyga-ubuntu: https://github.com/snapcore/snapd/pull/3640 | 10:53 |
| mup | PR snapd#3640: store: do not resume a download when we already have the whole thing <Created by chipaca> <https://github.com/snapcore/snapd/pull/3640> | 10:53 |
| mup | PR snapd#3640 opened: store: do not resume a download when we already have the whole thing <Created by chipaca> <https://github.com/snapcore/snapd/pull/3640> | 10:53 |
| Chipaca | zyga-ubuntu: if you push your changes to that, everybody should be happy | 10:54 |
| zyga-ubuntu | Chipaca: understood | 10:54 |
| Chipaca | it changes the logic for downloading deltas a teeny bit | 10:54 |
| Chipaca | bit it shouldn't change things in practice | 10:54 |
| zyga-ubuntu | I'll review it in a moment | 10:54 |
| Chipaca | if the store says "no deltas", download begins, download is canceled, download is reattempted and the store says there are deltas, currently we don't resume; this makes the resume win | 10:55 |
| Chipaca | in practice it shouldn't make much difference except outside tests | 10:55 |
| Chipaca | i mean except inside tests :-) | 10:55 |
| Chipaca | anyway | 10:55 |
| Chipaca | time for me to take a break, run, and lunch | 10:56 |
| * Chipaca afk | 10:56 | |
| zyga-ubuntu | ok, I will need ~45 minutes to finish the A/B timing tests | 10:59 |
| zyga-ubuntu | and in the meantime I can review | 10:59 |
| zyga-ubuntu | actually | 10:59 |
| zyga-ubuntu | scratch that | 10:59 |
| zyga-ubuntu | I can push my PR directly to see how long it takes | 10:59 |
| ogra | hrm ... travis ?? | 11:09 |
| ogra | Chipaca, are you still working on the shutdown stuff (unmounting /writable and /lib/modules failing) or is that on hold ? | 11:15 |
| mup | PR snapd#3641 opened: tests: download core and ubuntu-core at most once <Created by zyga> <https://github.com/snapcore/snapd/pull/3641> | 11:15 |
| zyga-ubuntu | ogra: that's merged | 11:16 |
| zyga-ubuntu | ogra: loooong ago | 11:16 |
| ogra | zyga-ubuntu, where ? that never changed on any ubuntu core images i run | 11:16 |
| zyga-ubuntu | ogra: look at /usr/lib/snapd/ | 11:16 |
| zyga-ubuntu | there should be a shutdown executable there | 11:16 |
| zyga-ubuntu | there's a systemd job that puts it in the special place that systemd uses on shutdown | 11:16 |
| zyga-ubuntu | I think it runs all the time for ~6 months now | 11:17 |
| ogra | well, it didnt fix the bug obviously | 11:17 |
| zyga-ubuntu | oh? | 11:17 |
| zyga-ubuntu | Chipaca: ^ | 11:17 |
| ogra | [FAILED] Failed unmounting /lib/modules. | 11:17 |
| ogra | [ OK ] Unmounted /etc/sudoers.d. | 11:17 |
| ogra | [ OK ] Unmounted /run/snapd/ns. | 11:17 |
| ogra | [FAILED] Failed unmounting /writable. | 11:17 |
| ogra | i still see that all the time on every shutdown on every install | 11:17 |
| zyga-ubuntu | mmmmm | 11:18 |
| zyga-ubuntu | maybe something broke? | 11:18 |
| zyga-ubuntu | I wonder if we can get some logs from the tool | 11:18 |
| ogra | well, i never "not" saw it | 11:18 |
| zyga-ubuntu | I remember testing the thing in kvm | 11:18 |
| ogra | (i actually thought john is still working on it ) | 11:18 |
| ogra | i see the systemd job simply copies it to /run/initramfs/ | 11:23 |
| zyga-ubuntu | another faiure of FAIL: overlord_test.go:360: overlordSuite.TestEnsureLoopPrune | 11:27 |
| * ogra pokes https://travis-ci.org/snapcore/core-build/builds/259703332 with a pointy stick in the eye ... | 11:39 | |
| zyga-ubuntu | ogra: remember the abyss quote | 11:40 |
| jdstrand | mwhudson: haven't read all backscroll. it seems like getting snapd in Debian (properly?) depends on using non-embedded code copies? | 11:44 |
| zyga-ubuntu | jdstrand: yes, and we did de-vendorize everything | 11:44 |
| zyga-ubuntu | jdstrand: but now the problem is we have a few forks | 11:45 |
| zyga-ubuntu | jdstrand: and it's unclear if we should move the vendorized deps ahead when we do this in debian | 11:45 |
| mup | PR snapd#3642 opened: cmd/snap: get keys or root document <Created by stolowski> <https://github.com/snapcore/snapd/pull/3642> | 11:46 |
| jdstrand | that's interesting. we have asimilar policy in Ubuntu but was told do to time constraints to relax the requirement for snapd | 11:52 |
| jdstrand | due* | 11:52 |
| jdstrand | interesting the work is happening now | 11:53 |
| zyga-ubuntu | ogra: can you open a thread about that /writable bug? | 11:55 |
| zyga-ubuntu | jdstrand: it's only happening for debian | 11:56 |
| zyga-ubuntu | jdstrand: I think that in ubuntu it is not even considered | 11:56 |
| zyga-ubuntu | jdstrand: especially since it impacts testing value | 11:56 |
| zyga-ubuntu | jdstrand: and that we reexec anyway | 11:56 |
| jdstrand | well, if there weren't outside factors influencing what we are doing in Ubuntu I would imagine we wuld do it in Ubuntu | 11:57 |
| zyga-ubuntu | jdstrand: I think the key factor was OMG time | 11:58 |
| jdstrand | it seems like Debian picked up on Ubuntu's definition of how to support golang packages but are actually enforcing it | 11:58 |
| zyga-ubuntu | jdstrand: though we lack in debian/copyright heavily todayu | 11:58 |
| pstolowski | cachio,hey! have you found any pattern for reproducing hook errors from https://paste.ubuntu.com/25218225/ ? e.g. linode vs local qemu etc? | 12:00 |
| Chipaca | huh, i might've broken deltas (according to spread) | 12:03 |
| * Chipaca will fix after lunch | 12:03 | |
| Chipaca | zyga-ubuntu: ogra: those [FAILED] are from systemd | 12:03 |
| Chipaca | zyga-ubuntu: ogra: our helper runs _after_ that; those failed are the reason we need the helper | 12:04 |
| zyga-ubuntu | jdstrand: jdstrand:policy-updates-xxvi | 12:05 |
| zyga-ubuntu | jdstrand: wow, roman numerals! | 12:05 |
| zyga-ubuntu | Chipaca: lots of refresh tests failed with your PR https://travis-ci.org/snapcore/snapd/builds/260146033?utm_source=github_status&utm_medium=notification | 12:07 |
| ogra | Chipaca, well, can we quieten them ? | 12:07 |
| Chipaca | zyga-ubuntu: yes, as i said, i seem to have broken deltas (or their tests) | 12:13 |
| Chipaca | ogra: sure! systemd is free software, right? | 12:14 |
| ogra | dunno, ask redhat :P | 12:14 |
| ogra | (surely open source though :) ) | 12:15 |
| Chipaca | nu-uh, they're on the other side of the river from me | 12:15 |
| jdstrand | zyga-ubuntu: yeah, rocking it old school. keeping it fun! :) | 12:29 |
| Chipaca | zyga-ubuntu: about your patch, unless i'm much mistaken the way you've done it won't work | 12:39 |
| Chipaca | zyga-ubuntu: that is: only the first test will find the .partial | 12:39 |
| Chipaca | zyga-ubuntu: you need to download them somewhere, and then at the start of each test copy them? or sth like that | 12:39 |
| zyga-ubuntu | Chipaca: isn't that exactly what is going on | 12:40 |
| Chipaca | otherwise, test downloads thing, tests its stuff, cleans up -> no more thing | 12:40 |
| zyga-ubuntu | this is doing in the "prepare the magic state tarball" stop | 12:40 |
| zyga-ubuntu | step* | 12:40 |
| zyga-ubuntu | and then it gets restored in each one | 12:40 |
| zyga-ubuntu | or maybe I misunderstood the restore logic | 12:40 |
| Chipaca | zyga-ubuntu: ah... if that's the case then it's ok :-) | 12:40 |
| zyga-ubuntu | Chipaca: but now that you said it, I'm not sure it is restored in each test | 12:40 |
| Chipaca | zyga-ubuntu: easy to test | 12:41 |
| zyga-ubuntu | TBH the spread setup is so wonky now someone could sit down and write a comprehensive document about it | 12:41 |
| zyga-ubuntu | Chipaca: how? | 12:41 |
| Chipaca | zyga-ubuntu: spread --shell yadda | 12:41 |
| zyga-ubuntu | mmm, let me try, thanks! | 12:41 |
| Chipaca | zyga-ubuntu: tweak spread.yaml to workers:1 | 12:42 |
| zyga-ubuntu | ah | 12:42 |
| zyga-ubuntu | good iea | 12:42 |
| zyga-ubuntu | ctrlc- | 12:42 |
| zyga-ubuntu | I think too late | 12:43 |
| zyga-ubuntu | 2017-08-02 14:43:04 Server <nil> (Spread-44) exceeds halt-timeout. Shutting it down... | 12:43 |
| cachio | pstolowski, I could reproduce it in qemu | 12:43 |
| zyga-ubuntu | interesting server! | 12:43 |
| zyga-ubuntu | Chipaca: on the up side, it's very refreshing to see green tests | 12:45 |
| pstolowski | cachio, every time? | 12:45 |
| cachio | yes | 12:45 |
| cachio | using branch | 12:46 |
| cachio | release/2.27 | 12:46 |
| cachio | pstolowski, so far I ran it twice and I saw it twice | 12:46 |
| pstolowski | cachio, interesting; did you run just this problematic test or entire suite? | 12:47 |
| zyga-ubuntu | pstolowski: hey, any hints on which snaps have config or how to play with your PR? | 12:47 |
| cachio | no, the entire mainsuite | 12:47 |
| pstolowski | zyga-ubuntu, i guess you can try core; you can try to add extra dummy config to core via snap set core foo=bar | 12:49 |
| zyga-ubuntu | pstolowski: and they are not discarded?! | 12:49 |
| zyga-ubuntu | pstolowski: this seems pretty dangerous | 12:50 |
| zyga-ubuntu | pstolowski: $ snap set author.name=frank | 12:50 |
| zyga-ubuntu | pstolowski: snap set --help | 12:50 |
| zyga-ubuntu | pstolowski: this example seems broken since there's no snap-name there | 12:50 |
| zyga-ubuntu | woah | 12:51 |
| zyga-ubuntu | that's surely a bug | 12:51 |
| zyga-ubuntu | people can set whatever they want now | 12:51 |
| zyga-ubuntu | and once we add options tomorrow it starts to have a meaning | 12:51 |
| F0rTh3J3st | nyce! | 12:51 |
| zyga-ubuntu | brb, see you at the call | 12:52 |
| pstolowski | zyga-ubuntu, yeah, not discarded, and also known I think. i'm not sure it was considered an issue | 12:52 |
| pedronis | you can read it as a bug or a feature depending | 12:54 |
| pedronis | I think the plan is still to have some kind of schema at some point | 12:55 |
| zyga-ubuntu | Chipaca: the .partial files are there | 13:00 |
| zyga-ubuntu | 2fa | 13:02 |
| * ogra wonders if travis will ever start ... in total i'm waiting for that job since 14h now | 13:16 | |
| ogra | (with a timeout over night and a manual re-start) | 13:17 |
| === chihchun is now known as chihchun_afk | ||
| pedronis | Chipaca: was my explanation about timeouts understandable? | 13:22 |
| Chipaca | pedronis: that our timeouts were too aggressive? | 13:28 |
| pedronis | yes | 13:29 |
| Chipaca | pedronis: for downloads, right? | 13:30 |
| pedronis | for everything really | 13:30 |
| Chipaca | pedronis: well... for interactive things, we're waiting too long, not too little | 13:30 |
| Chipaca | but that might mean that, for interactive things, we should retry less and wait more | 13:31 |
| * ogra shakes fist at https://travis-ci.org/snapcore/core-build/builds/259703332 | 13:32 | |
| pedronis | Chipaca: well, is not realistic to get a server answer in 100ms from almost anywhere | 13:32 |
| pedronis | if we are too slow we need to cache | 13:33 |
| Chipaca | pedronis: OTOH the store is taking >1s to anser more than 1% of requests | 13:33 |
| pedronis | yes, but an aggressive timeout doesn't help, it's just more load | 13:33 |
| Chipaca | pedronis: is the random >1s responses because of load? | 13:34 |
| pedronis | I don't know | 13:34 |
| pedronis | but using 2+ requets for everything doesn't help | 13:34 |
| Chipaca | pedronis: are we? | 13:36 |
| pedronis | I suspect so | 13:36 |
| zyga-arch | janisozaur1: hey, I made some progress, I fixed two things breaking tests | 13:39 |
| zyga-arch | janisozaur1: and I got the bulk of the code to build | 13:39 |
| zyga-arch | janisozaur1: still a few things to do but I should have a *much* better package soon | 13:39 |
| pstolowski | cachio, so, I need release/2.27 to reproduce the bug? | 13:42 |
| cachio | pstolowski, yes | 13:42 |
| pstolowski | thanks | 13:42 |
| zyga-arch | hmmm | 14:02 |
| * zyga-arch breaks for some drinks while staring at the test failure | 14:02 | |
| PhoenixMage | Hi all, is it possible to set the SSO credentials for a fresh install in a config file prior to first boot? | 14:19 |
| ogra | PhoenixMage, https://docs.ubuntu.com/core/en/reference/assertions/system-user | 14:20 |
| ogra | you need an USB key though | 14:20 |
| PhoenixMage | USB keys I have plenty of but no monitor that has HDMI and no serial cable | 14:21 |
| PhoenixMage | Thanks for the tip | 14:21 |
| zyga-arch | hmm | 14:30 |
| PhoenixMage | ok so I understand how to create the assertion but have no idea what the format on the usb has to be such as filename | 14:35 |
| zyga-arch | PhoenixMage: hey | 14:38 |
| zyga-arch | PhoenixMage: you need to put "auto-import.assert" in the root of the drive | 14:40 |
| zyga-arch | PhoenixMage: the file can contain any assertions | 14:41 |
| zyga-arch | PhoenixMage: I think you want to format the USB drive as a FAT filesystem | 14:41 |
| zyga-arch | PhoenixMage: it will be auto-imported on boot | 14:42 |
| zyga-arch | PhoenixMage: you can test this with "snap auto-import" | 14:42 |
| zyga-arch | PhoenixMage: but you must be on a core device (it is disabled on classic) | 14:42 |
| PhoenixMage | zyga-arch: I can run it up in a core VM | 14:43 |
| PhoenixMage | zyga-arch: Sorry for the silly question but where can I get an authority-id? | 14:43 |
| zyga-arch | PhoenixMage: you probably want to talk to pedronis about this, ideally in a forum thread so that it is reusable for others | 14:45 |
| zyga-arch | PhoenixMage: in short you want to have your own brand | 14:45 |
| zyga-arch | PhoenixMage: and then issue (as the brand) an assertion that lets you create accounts on unowned machines using that brand | 14:45 |
| zyga-arch | PhoenixMage: canonical could issue such assertions but for the moment this is not done | 14:46 |
| zyga-arch | PhoenixMage: for some insight you can also look at a test that is checking this feature | 14:46 |
| zyga-arch | PhoenixMage: where it is fully done (end-to-end) | 14:46 |
| zyga-arch | PhoenixMage: but I'm not that sure it's easier than asking pedronis given that it assumes a lot of context | 14:46 |
| PhoenixMage | zyga-arch: Thanks, might have to leave that to another day, its nearly 1am here | 14:47 |
| mup | PR snapcraft#1435 opened: lxd: Wait on lock files before running apt commands <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1435> | 14:49 |
| zyga-arch | PhoenixMage: good luck :-) | 14:55 |
| ogra | PhoenixMage, good morning ! | 14:56 |
| ogra | :) | 14:56 |
| zyga-arch | (insert quote about bilbo and gandalf good morning) | 15:00 |
| PhoenixMage | I still call this evening, in my book there is no such thing as a good morning | 15:00 |
| PhoenixMage | Appreciate the sentiment though ;) | 15:00 |
| PhoenixMage | Was hoping to create a couple of headless active directort domain controllers using Pis and Core :/ | 15:01 |
| ogra | surely possible ... but you need a snamba snap first i guess | 15:01 |
| ogra | *samba | 15:01 |
| ogra | (not sure there is one in the store yet) | 15:02 |
| PhoenixMage | ogra: first I need a Pi core instance I can use | 15:02 |
| ogra | true | 15:02 |
| PhoenixMage | Then I will worry about learning how to make/use snaps | 15:02 |
| PhoenixMage | Core is new to mwe | 15:02 |
| zyga-arch | PhoenixMage: then you don't need the assertion yet | 15:03 |
| PhoenixMage | Getting close to morning, there goes my typing | 15:03 |
| zyga-arch | PhoenixMage: that's for waaaaaay later | 15:03 |
| ogra | zyga-arch, well, he has no kbd, serial or monitor ... | 15:03 |
| zyga-arch | ogra: pi zero? | 15:03 |
| PhoenixMage | Understand the whole secure at first boot thing, my background is security but there should be a way I can at least put an ssh-key on it without having internet access | 15:04 |
| ogra | no idea, does that matter if you dont have any peripherials ? | 15:04 |
| zyga-arch | ogra: if normal pi then it is significantly easier to get a serial port connected | 15:04 |
| zyga-arch | PhoenixMage: there is but only the brand has a way to issue those | 15:04 |
| PhoenixMage | But then again, web devs | 15:04 |
| ogra | zyga-arch, only if you have the cable :) | 15:04 |
| zyga-arch | ogra: you do realize we are arguing about making a model assertion and making a new core image just so that we don't need to get a 5$ cable | 15:04 |
| ogra | we need to really make it easier to set up a board without any peripherial HW | 15:05 |
| * ogra was pondering to fiddle with USB gadget networking ... then you can ssh through the OTG port | 15:05 | |
| ogra | zyga-arch, we're not arguing | 15:06 |
| ogra | (at least i'm not) | 15:06 |
| PhoenixMage | I dont think its unreasonable to expect someone to have a usb thumb drive, but a serial cable or a compatible screen or keyboard isnt necessarily available | 15:06 |
| zyga-arch | arguing as in discussing :-) | 15:06 |
| zyga-arch | PhoenixMage: for embedded devices it's pretty common, I recognize there are some things missing in the story today, I'm just telling what is the easiest path forward | 15:06 |
| PhoenixMage | I like to play with stuff like this in hotel rooms when I travel so nothing is given except board access and I have likely forgotten a serial cable | 15:06 |
| zyga-arch | for hacking just use kvm | 15:07 |
| ogra | what i'd really like is to enable gadget networking in our images ... then you can just access console-conf via USB without extra cables | 15:07 |
| zyga-arch | no more hardware needed | 15:07 |
| zyga-arch | if you need an intro to snaps and core that's the most comfortable way to do it | 15:07 |
| PhoenixMage | ogra: that would be nice, everyone has at least 1 micro usb cable around | 15:07 |
| ogra | right | 15:07 |
| PhoenixMage | Well until usb c is ubiquitous | 15:08 |
| zyga-arch | raspberry pi, shiny metal ass edition | 15:09 |
| zyga-arch | with usb-c | 15:09 |
| zyga-arch | 40GB cable | 15:09 |
| zyga-arch | doing 100MBit networking | 15:09 |
| PhoenixMage | I'd settle for gig networking | 15:09 |
| zyga-arch | 40Gb | 15:09 |
| zyga-arch | and the board will be white | 15:09 |
| zyga-arch | with no sharp edges | 15:09 |
| ogra | that sounds like a beaglebone white ... | 15:10 |
| ogra | :P | 15:10 |
| PhoenixMage | I am trying to get all my essentials on to Pi to minimise my power bills and will fire up the rest of my lab when I need it | 15:10 |
| PhoenixMage | I am looking at an Olimex Lime 2 for my more network intensive applications like next cloud | 15:10 |
| PhoenixMage | So does a brand cost money? | 15:11 |
| PhoenixMage | I am assuming not but hey | 15:11 |
| ogra | no, it is just your store account | 15:11 |
| PhoenixMage | It says talk to sales on the website lol | 15:11 |
| zyga-arch | PhoenixMage: nope | 15:12 |
| PhoenixMage | I did look at banana/orange pis too but the olimex looks nicer | 15:13 |
| ogra | if you look at https://dashboard.snapcraft.io/dev/account/ .... there is your account id ... | 15:14 |
| ogra | if you are the owner of the kernel and gadget snaps for yur image you can use that id as your brand-id | 15:14 |
| zyga-arch | PhoenixMage: think about software, not hardware | 15:15 |
| ogra | (model assertion, kernel and gadget need to be owned by the same id as the system-user assertion ... ) | 15:15 |
| zyga-arch | all the hardware is nice on the product page | 15:15 |
| zyga-arch | then you get it and, whoops, the kernel is weird | 15:15 |
| zyga-arch | anyway | 15:15 |
| zyga-arch | back to hacking | 15:15 |
| PhoenixMage | And sleep for me | 15:16 |
| PhoenixMage | Thanks for all your help, appreciate it | 15:16 |
| zyga-arch | o/ | 15:16 |
| ogra | sleep well ... | 15:16 |
| PhoenixMage | I got a pregnant lady in the bed not much chance | 15:17 |
| * zyga-arch fixed a bug in cmd_test.go | 15:21 | |
| rharper | ogra: thanks for merging my change to core-build; when would the core snap in edge get that change? I looked at core_2554 in edge today and it's not there yet; | 15:34 |
| ogra | rharper, well.... i'm waiting for https://travis-ci.org/snapcore/core-build/builds/259703332 since yesterday afternoon | 15:34 |
| rharper | ogra: ok | 15:35 |
| ogra | rharper, it needs a new deb in the PPA,, i'll get to it once travis passed | 15:35 |
| rharper | cool, thanks for the info | 15:35 |
| ogra | i'll ping you once it is in edge | 15:35 |
| rharper | thanks! | 15:35 |
| mup | PR snapd#3643 opened: overlord/devicestate, store: update device auth endpoints URLs <Created by matiasb> <https://github.com/snapcore/snapd/pull/3643> | 15:40 |
| zyga-arch | Chipaca: yo, you around sir? | 15:41 |
| Chipaca | zyga-arch: yup | 15:41 |
| Chipaca | for now at least | 15:42 |
| zyga-arch | excellent | 15:42 |
| zyga-arch | one liner fix for you | 15:42 |
| Chipaca | zyga-arch: go on then | 15:42 |
| pstolowski | cachio, hey, no luck with reproducing the failure you saw :( | 15:48 |
| * zyga-arch makes a few PRs | 15:48 | |
| zyga-arch | Chipaca: https://github.com/snapcore/snapd/pull/3644 | 15:51 |
| mup | PR snapd#3644: cmd: fix tests that assume /snap mount <Created by zyga> <https://github.com/snapcore/snapd/pull/3644> | 15:51 |
| mup | PR snapd#3644 opened: cmd: fix tests that assume /snap mount <Created by zyga> <https://github.com/snapcore/snapd/pull/3644> | 15:51 |
| mup | PR snapd#3645 opened: cmd: mark arch as non-reexecing distro <Created by zyga> <https://github.com/snapcore/snapd/pull/3645> | 15:51 |
| zyga-arch | and 3645 | 15:51 |
| zyga-arch | I made them separate because I wanted nice description on GH and it's easier to cherry pick | 15:51 |
| Chipaca | zyga-arch: lel | 15:52 |
| zyga-arch | lel? | 15:52 |
| zyga-arch | lets-evaluate-laughing? | 15:52 |
| zyga-arch | oh | 15:53 |
| zyga-arch | 3644 is buggy | 15:53 |
| zyga-arch | but not caught by tests | 15:53 |
| Chipaca | zyga-arch: it can't be, i approved it | 15:53 |
| zyga-arch | (corrected) | 15:53 |
| zyga-arch | sorry, I didn't notice | 15:54 |
| zyga-arch | now it's good | 15:54 |
| zyga-arch | I force pushed to get the easy cherry pick for the packaging | 15:54 |
| zyga-arch | thank you sir! | 15:55 |
| zyga-arch | janisozaur1: ^ little by little | 15:55 |
| zyga-arch | pedronis: ^ if you have a sec and could do a 2nd review on the pair? | 15:57 |
| zyga-arch | Chipaca: fun fact | 16:01 |
| zyga-arch | I just logged into my server | 16:01 |
| zyga-arch | as root, unusually | 16:01 |
| zyga-arch | my /root/snap/core is interesting | 16:01 |
| zyga-arch | we never recycle those directories | 16:01 |
| zyga-arch | I see all the revisions we ever did | 16:01 |
| zyga-arch | all empty | 16:01 |
| zyga-arch | but ... well | 16:01 |
| zyga-arch | is that the same thing that pstolowski reported ? | 16:01 |
| Chipaca | zyga-arch: a'yup | 16:02 |
| zyga-arch | perfect, thank you | 16:02 |
| pstolowski | zyga-arch, yes | 16:02 |
| pedronis | what's the policy, our queue is grewing again? | 16:02 |
| zyga-arch | pedronis: downstream bugfixes for packaging | 16:03 |
| zyga-arch | pedronis: not sure if we have a policy, we should definitely process the review queue | 16:04 |
| zyga-arch | Chipaca: are we using some local proxy during testing? | 16:12 |
| zyga-arch | Aug 02 14:38:41 autopkgtest snapd[32266]: 2017/08/02 14:38:41.789947 retry.go:52: DEBUG: The retry loop for http://localhost:11028/api/v1/snaps/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2 finished after 1 retries, elapsed time=1.850053ms, status: Get http://localhost:11028/api/v1/snaps/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2: dial tcp 127.0.0.1:11028: getsockopt: con | 16:12 |
| zyga-arch | nection refused | 16:12 |
| zyga-arch | this is from a failed test run | 16:12 |
| zyga-arch | now why is snapd calling localhost? | 16:12 |
| * ogra cries ... | 16:12 | |
| ogra | https://travis-ci.org/snapcore/core-build/builds/259703332 | 16:12 |
| ogra | sigh | 16:12 |
| zyga-arch | ogra: at least travis has nice faces | 16:12 |
| Chipaca | zyga-arch: some of the tests use a fake store | 16:12 |
| zyga-arch | ogra: restarted | 16:12 |
| ogra | zyga-arch, yeah, i only noticed recently that there a females now | 16:13 |
| zyga-arch | aha, I see | 16:13 |
| ogra | zyga-arch, i restarted it twice already since yesterday | 16:13 |
| zyga-arch | ogra: how does it fail? | 16:13 |
| ogra | it sits there forever and then fails with that error | 16:13 |
| zyga-arch | travis hiccup? | 16:13 |
| ogra | dunno the exact wording since you just restarted it and the page auto-refreshed :P | 16:13 |
| zyga-arch | ogra: it said auto-restarting is limited | 16:14 |
| ogra | yeah | 16:14 |
| zyga-arch | ogra: did you force push to it? | 16:14 |
| ogra | no | 16:14 |
| ogra | i only merged the PR after you and Chipaca approved it yesterday | 16:14 |
| zyga-arch | interesting, weird | 16:14 |
| ogra | and the PR is a one word change | 16:14 |
| zyga-arch | let's see what happens now | 16:14 |
| zyga-arch | well ;D | 16:14 |
| zyga-arch | quality :D | 16:14 |
| ogra | i bet the same as the two times before | 16:14 |
| ogra | (nothing ... until something times out) | 16:15 |
| pedronis | zyga-arch: that localhost is the fake store | 16:17 |
| ogra | zyga-arch, hmmm .... the last merge before this hanging one is https://github.com/snapcore/core-build/pull/14 | 16:17 |
| mup | PR core-build#14: initramfs/testing: add unit tests for initrd scripts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/core-build/pull/14> | 16:17 |
| zyga-arch | It *did* pass | 16:18 |
| zyga-arch | maybe something broke since | 16:18 |
| ogra | zyga-arch, are yyou sure that travis gets along with the --rbind change you added there ? | 16:18 |
| zyga-arch | like travis-side | 16:18 |
| zyga-arch | --rbind? | 16:18 |
| ogra | yeah, you changed the travis.yaml ... part of that is to replace all --bind calls with --rbind | 16:18 |
| zyga-arch | I see | 16:19 |
| ogra | uh oh | 16:19 |
| ogra | and i never noticed that you run kvm inside a double stacked chroot ! | 16:19 |
| zyga-arch | I think those are for qemu | 16:19 |
| ogra | oh my | 16:19 |
| zyga-arch | but yes, it all passed | 16:19 |
| zyga-arch | what | 16:19 |
| ogra | (that should really have been a separate test ... not inside the chroooted chroot) | 16:20 |
| zyga-arch | why do you feel thta? | 16:20 |
| zyga-arch | *that | 16:20 |
| ogra | because too many layers ?? | 16:20 |
| zyga-arch | and is that a problem? | 16:21 |
| zyga-arch | layers of what | 16:21 |
| zyga-arch | anyway, this *did* pass | 16:21 |
| zyga-arch | I'm all into figuring out what happens but this is not really anything controversial | 16:21 |
| ogra | there is a travis 14.04 chroot ... in which we create an ubuntu 16.04 chroot ... inside which you tghen install kvm and qemu to run a vm | 16:21 |
| zyga-arch | yes, and I would expect this to just work | 16:21 |
| ogra | well | 16:22 |
| zyga-arch | it runs without kvm on travis btw | 16:22 |
| ogra | me too ... but there can be millions of corner cases | 16:22 |
| zyga-arch | I really don't see how | 16:22 |
| zyga-arch | I'm running an userspace process, without kvm in a chroot | 16:22 |
| zyga-arch | btw, does travis do 16.04 now? | 16:22 |
| zyga-arch | maybe we could drop some of the chroots | 16:23 |
| ogra | no | 16:23 |
| * ogra got a notification that tthey gradually updating to 14.04 from 12.04 right now | 16:23 | |
| ogra | (got that today) | 16:23 |
| ogra | so i guess 16.04 native is far out | 16:23 |
| ogra | but we should really separate the two tests and not mix-mash them | 16:24 |
| zyga-arch | separation will not get you anything positive from travis | 16:25 |
| ogra | chroots in chroots that run a vm really doesnt sound sane | 16:25 |
| ogra | if you run a vm anyway, do it at the toplevel | 16:25 |
| zyga-arch | I'd rather switch to using spread as the substrate so that we can ignore silly travis limitations | 16:25 |
| ogra | there is no need to do this inside the chroot | 16:25 |
| ogra | well, not sure what spread would buy us anyway ... its dpkg source packages ... we should rather use autopkgtest all over | 16:26 |
| pedronis | zyga-arch: seems I should look at some older branches before, anyway about to eod | 16:26 |
| ogra | but since i was forced into that weird tree setup you cant just auto-build the debs anymore | 16:26 |
| ogra | (there is no more toplevel /debian dir due to the fact that i had to put both packages into one tree) | 16:27 |
| zyga-arch | pedronis: as you want, those are super short and tiny | 16:29 |
| zyga-arch | pedronis: I can cherry pick for packaging for now | 16:29 |
| zyga-arch | so no worries | 16:29 |
| ogra | zyga-arch, btw, https://github.com/snapcore/core-build/pull/14 doesnt even seem to have had any travis runs at all | 16:33 |
| mup | PR core-build#14: initramfs/testing: add unit tests for initrd scripts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/core-build/pull/14> | 16:33 |
| ogra | (unless the UI somehow hides them lately) | 16:33 |
| ogra | oh, it actually does ... found it | 16:33 |
| zyga-arch | yeah, that's the green tick | 16:36 |
| ogra | wowo, but we need to fix a lot there | 16:37 |
| * ogra is just reading the logs | 16:37 | |
| ogra | all the initrd re-packing should definitely use the proper compression method ... and the cpio calls should use the correct options from the system, so we end up with the same initrds the system would produce | 16:38 |
| ogra | (there are config files we can read from the system that have all the bits and pieces, so we dont need to re-invent the wheel) | 16:39 |
| ogra | zyga-arch, FYI ... failed fast this time (same error) | 16:42 |
| zyga-arch | ogra: proper compression method? | 16:43 |
| ogra | zyga-arch, yeah, whatever is set for the specific OS in initramfs tools config | 16:43 |
| ogra | you are lucky that gz is still supported :P | 16:43 |
| ogra | (we havent used that iin years for initrds) | 16:43 |
| ogra | core defaults to lzma ... | 16:45 |
| zyga-arch | ogra: can you give me an example? | 16:48 |
| ogra | ? | 16:48 |
| zyga-arch | like the options you refer to | 16:48 |
| ogra | your code hardcoded gzip everywhere | 16:48 |
| zyga-arch | gzip is fast to compress and works | 16:48 |
| ogra | sure | 16:49 |
| zyga-arch | that's the only reason I used it | 16:49 |
| ogra | but not what the actual initrd will use | 16:49 |
| zyga-arch | that's okay, we're not testing that | 16:49 |
| zyga-arch | we're just testing the bash functions | 16:49 |
| ogra | we should be as close to reality as possible with our tests or shouldnt we ? | 16:49 |
| zyga-arch | no, we should not be as close to reality, the point is to test a specific part of the code (the shell code) in a reasonably efficient and sensible way | 16:50 |
| zyga-arch | otherwise everything would be an integration test | 16:50 |
| zyga-arch | look how there are tons of mocking calls there | 16:50 |
| zyga-arch | we're not testing the real thing | 16:50 |
| zyga-arch | ogra: btw, can you please pass a link to the PR again | 16:50 |
| zyga-arch | I cannot find it somehow | 16:50 |
| ogra | which one ? the failing one ? | 16:50 |
| zyga-arch | yep | 16:50 |
| ogra | https://github.com/snapcore/core-build/pull/15 | 16:51 |
| mup | PR core-build#15: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/15> | 16:51 |
| ogra | -policy: search,found=first,maybe=all,notfound=disabled | 16:51 |
| ogra | +policy: search,found=first,maybe=none,notfound=disabled | 16:51 |
| ogra | thats the change | 16:51 |
| ogra | (all vs none) | 16:51 |
| zyga-arch | ah, you merged it now | 16:51 |
| ogra | nothing fancy | 16:51 |
| zyga-arch | did tests pass? | 16:52 |
| ogra | well, yes and no | 16:52 |
| ogra | it passed when the PR was created | 16:52 |
| zyga-arch | I see | 16:52 |
| ogra | not sure why travis runs again on merge ... did it do that before ? | 16:52 |
| zyga-arch | travis has two options: to run on branch push (so branch is tested) and to test merges | 16:52 |
| zyga-arch | it's a per-repo choice | 16:52 |
| ogra | right, i didnt change that ... (i doubt i can actually) | 16:53 |
| ogra | and i dont know if it did that for any of the former PRs in that branch | 16:53 |
| ogra | the tree definitely shows it landed properly in https://github.com/snapcore/core-build/blob/master/config/etc/cloud/ds-identify.cfg | 16:55 |
| ogra | so i dont really get what travis tries to do there | 16:56 |
| zyga-arch | perhaps we turned that off | 16:56 |
| ogra | i can imagine it to run before merge ... but why would it run after ... | 16:56 |
| * zyga-arch rebuilds the arch package with some more fixes | 16:59 | |
| ogra | hmm, funny ... the PR actualy links to the successful travis run from 27 days ago | 17:01 |
| * ogra decides to simply ignore that travis run | 17:03 | |
| mup | Bug #1707474 opened: FTBFS on i386: incompatibility with new xfsprogs <Snappy:New for zyga> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1707474> | 17:03 |
| zyga-arch | hmm | 17:24 |
| zyga-arch | ah, I had a stale file | 17:33 |
| zyga-arch | janisozaur1: hey, how does it work if I would like to maintain a package in the community repo? | 17:35 |
| zyga-arch | janisozaur1: or just co-maintain snapd with timothy? | 17:35 |
| janisozaur1 | zyga-arch: I assume it must be trivial or near-trivial | 17:35 |
| zyga-arch | not trivial in any way but I'm an upstream, does that help? | 17:36 |
| janisozaur1 | in a project I work on, the Windows developer submitted an AUR package | 17:36 |
| zyga-arch | and it's not a core package | 17:36 |
| zyga-arch | we did an AUR package before but it got updated to community | 17:36 |
| zyga-arch | (I'm talking about snapd) | 17:36 |
| janisozaur1 | you can submit snapd-git to AUR without raising any eyebrows | 17:37 |
| zyga-arch | yeah, I think we already had that one, I could do it | 17:37 |
| zyga-arch | ideally I'd work with timothy on the real packge | 17:37 |
| janisozaur1 | it's a common practice to have `x-git`, `x-beta` and so on packages in AUR | 17:37 |
| zyga-arch | package* | 17:37 |
| zyga-arch | aha | 17:37 |
| zyga-arch | that's good to know | 17:37 |
| zyga-arch | we should to that then | 17:37 |
| zyga-arch | especially the -git one | 17:37 |
| janisozaur1 | quite commonly PKGBUILDs used for real repos would be the same as used on AUR | 17:38 |
| janisozaur1 | with the only difference being the sources version they point to | 17:39 |
| zyga-arch | yeah, that's the goal here | 17:39 |
| zyga-arch | ok, one more test to fix | 17:39 |
| janisozaur1 | the one that you downloaded from community repo, just change the pkgver and it will produce updated version | 17:39 |
| zyga-arch | oh, and a *real* bug | 17:40 |
| zyga-arch | well, I have a lot of changes/fixes there | 17:40 |
| zyga-arch | with a bit of luck the last one to make | 17:40 |
| zyga-arch | Chipaca: do you have a sec to hand-hold my logic? | 17:41 |
| zyga-arch | Chipaca: what is the expected value of $SNAP on a distro that uses non-standard /snap location | 17:42 |
| zyga-arch | since we don't support classic confinement | 17:42 |
| zyga-arch | I would say it should just say /snap | 17:42 |
| zyga-arch | since on the inside, where the variable matters, | 17:42 |
| zyga-arch | it is always the same | 17:42 |
| Chipaca | zyga-arch: i do | 17:42 |
| zyga-arch | excellent | 17:42 |
| zyga-arch | one more patch then | 17:42 |
| zyga-arch | really one liner :) | 17:42 |
| Chipaca | zyga-arch: $SNAP is /snap/<snapname>/<revision>/ | 17:43 |
| zyga-arch | right! | 17:43 |
| zyga-arch | +1 that's exactly what I made | 17:43 |
| zyga-arch | just wanted to get an ack that I didn't miss any loophole | 17:43 |
| Chipaca | zyga-arch: now if the snap is classic, i don't know if that is reality | 17:43 |
| zyga-arch | Chipaca: those don't work without /snap on the distro | 17:45 |
| zyga-arch | so that's +1 | 17:45 |
| zyga-arch | Chipaca: PR away | 17:46 |
| zyga-arch | one more patch to my collection | 17:46 |
| mup | PR snapd#3646 opened: snap/snapenv: always expect /snap for $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/3646> | 17:46 |
| zyga-arch | one more makepkg | 17:48 |
| zyga-arch | some say that this is the one where tests pass | 17:48 |
| Chipaca | cachio: i've just had fedora fail to prepare, is that on your radar? | 17:50 |
| Chipaca | cachio: https://s3.amazonaws.com/archive.travis-ci.org/jobs/260290219/log.txt?X-Amz-Expires=30&X-Amz-Date=20170802T174918Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170802/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=ca82ef1041c0f438b599060ab83bf69d943193fed63576fd4a05e273e31399b3 | 17:50 |
| Chipaca | gah, bad url | 17:50 |
| Chipaca | cachio: https://api.travis-ci.org/jobs/260290219/log.txt | 17:51 |
| zyga-arch | Chipaca: and one more | 18:00 |
| mup | PR snapd#3647 opened: gitignore: ignore more build artefacts <Created by zyga> <https://github.com/snapcore/snapd/pull/3647> | 18:01 |
| zyga-arch | and to be fair | 18:02 |
| zyga-arch | it worked | 18:02 |
| zyga-arch | just run-checks is silly | 18:03 |
| Chipaca | ok, i'm EOD | 18:13 |
| zyga-arch | Chipaca: o/ | 18:13 |
| Chipaca | zyga-arch: \o | 18:13 |
| zyga-arch | janisozaur1: it built (and passed all tests!) | 18:15 |
| janisozaur1 | great success! | 18:15 |
| janisozaur1 | what's the plan now? will you submit snapd-git package to AUR? | 18:16 |
| zyga-arch | janisozaur1: how can I merge two packages into one? | 18:16 |
| zyga-arch | first I want to play with it | 18:16 |
| zyga-arch | I will propose a PR to merge the improvements to master | 18:16 |
| zyga-arch | and work on building it there as well (so that it doesn't regress) | 18:16 |
| janisozaur1 | what do you mean "merge two packages"? | 18:16 |
| zyga-arch | as tests turn positive I will ping timothy to update the package in community | 18:16 |
| janisozaur1 | the split package? | 18:17 |
| zyga-arch | there are two binary packages: snapd and snap-confine | 18:17 |
| zyga-arch | we merged them into one in all the other places | 18:17 |
| zyga-arch | so almost good | 18:17 |
| zyga-arch | arch is wrong, must be something still missing from uname mapping | 18:17 |
| zyga-arch | odd, uname just uses x86_64 like all normal kernels do | 18:18 |
| zyga-arch | let me check the place | 18:18 |
| zyga-arch | but | 18:18 |
| janisozaur1 | just have one "package()" instead of two and remove references to split package in header | 18:18 |
| zyga-arch | woot | 18:18 |
| zyga-arch | let me try | 18:18 |
| zyga-arch | how do I deprecate/remove the stale snap-confine package | 18:18 |
| zyga-arch | some files will move to snapd | 18:18 |
| janisozaur1 | i think `replaces=('snap-confine')` should do | 18:19 |
| janisozaur1 | but honestly that might be a better question for #archlinux | 18:20 |
| zyga-arch | good point | 18:21 |
| zyga-arch | ok | 18:22 |
| zyga-arch | snaps seem to work for me | 18:22 |
| zyga-arch | ok | 18:23 |
| zyga-arch | I still need to do tab completion | 18:23 |
| zyga-arch | and then do some comparison to what we ship here and in fedora or debian | 18:23 |
| zyga-arch | but | 18:23 |
| zyga-arch | I can share what I have, do you want to play with it? | 18:23 |
| janisozaur1 | yes | 18:23 |
| janisozaur1 | yes, please :) | 18:23 |
| zyga-arch | can I just say package() { } when I have one binary package? | 18:25 |
| janisozaur1 | yes | 18:25 |
| janisozaur1 | if you submit a PR with updated PKGBUILD, I can work with that | 18:27 |
| janisozaur1 | double check packaging snapd itself works | 18:27 |
| zyga-arch | yep, just building locally | 18:28 |
| zyga-arch | I'll install the tab completion files as well | 18:28 |
| zyga-arch | snaps can do pretty nifty confined tab completion | 18:29 |
| zyga-arch | so far so good | 18:33 |
| mup | PR snapd#3648 opened: release: remove default from VERSION_ID <Created by zyga> <https://github.com/snapcore/snapd/pull/3648> | 18:36 |
| zyga-arch | ok, trying the build with tab completion | 18:42 |
| zyga-arch | if this works I'll push the branch | 18:42 |
| zyga-arch | I also fixed the unknown | 18:43 |
| zyga-arch | (in snap version) | 18:43 |
| zyga-arch | I tried a few snaps already and it's ok | 18:43 |
| zyga-arch | though the update from previous snapd with snap-confine didn't work OK | 18:43 |
| zyga-arch | I had to remove snapd and snap-confine | 18:43 |
| zyga-arch | maybe it works better when this is done in a repo | 18:43 |
| zyga-arch | and not when I just use pacman on files | 18:43 |
| janisozaur1 | I think it should work the same way | 18:44 |
| zyga-arch | maybe I did it incorrectly, I really promise to push in a sec | 18:44 |
| zyga-arch | let me review the patch and push now | 18:44 |
| zyga-arch | can you please try https://github.com/zyga/snapd/commit/4bf43f3f68e856f7a45375f972aaca98bc3295e5 | 18:45 |
| zyga-arch | just get that branch https://github.com/zyga/snapd/tree/feature/improve-arch-package | 18:46 |
| zyga-arch | and do makepkg in packaging/arch | 18:46 |
| zyga-arch | if you have stale src you may need to kill it | 18:46 |
| zyga-arch | aww, hold on | 18:46 |
| zyga-arch | didn't build | 18:46 |
| * zyga-arch correts | 18:48 | |
| zyga-arch | have a look but don't build :) | 18:48 |
| zyga-arch | I'll push the fix over this in a moment | 18:48 |
| zyga-arch | janisozaur1: how do I build a package and skip tests? | 18:50 |
| zyga-arch | just to gain speed | 18:50 |
| janisozaur1 | makepkg --nocheck | 18:51 |
| zyga-arch | build successful, let me install and run a simple snap to check | 18:51 |
| zyga-arch | I think the version is wrong | 18:51 |
| zyga-arch | it should convey "prerelease" | 18:51 |
| zyga-arch | not sure how to do that | 18:52 |
| zyga-arch | 2.27~1-1 something | 18:52 |
| zyga-arch | like in debian? | 18:52 |
| janisozaur1 | is 2.27 already a tag? | 18:52 |
| zyga-arch | no, not yet | 18:53 |
| zyga-arch | that's why :/ | 18:53 |
| zyga-arch | pushed | 18:53 |
| zyga-arch | try it | 18:53 |
| zyga-arch | I'll try it with GUI snaps now | 18:53 |
| janisozaur1 | so the usual way would be: | 18:53 |
| zyga-arch | maybe, krita? | 18:53 |
| janisozaur1 | 1. have the package name `snapd-git` | 18:53 |
| zyga-arch | tab completion for snap works! | 18:53 |
| janisozaur1 | 2. the (stored) package version is only changed when the PKGBUILD itself changes, otherwise it should be autogenerated | 18:54 |
| zyga-arch | janisozaur1: note that the purpose of packaging/arch directory is to keep the refenrence *downstream* release packaging | 18:55 |
| janisozaur1 | 3. the `pkgver() {}` should report dynamic version, e.g. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=zopfli-git#n13 | 18:55 |
| zyga-arch | snapd-git should be a separate AUR package | 18:55 |
| zyga-arch | ah | 18:55 |
| zyga-arch | thank you! | 18:55 |
| zyga-arch | no GLX :/ | 18:55 |
| zyga-arch | I need to improve opengl support :) | 18:56 |
| zyga-arch | it seems this is the thing were we all started | 18:56 |
| janisozaur1 | so you can have the pkgver set to something like 2.26.14-1414-g1bb7d6da9 | 18:56 |
| zyga-arch | I see a billion gpg-agents on my system | 18:57 |
| zyga-arch | hmm | 18:57 |
| zyga-arch | is this gnome-web being dumb or did I break something with tests? | 18:57 |
| zyga-arch | yep | 18:57 |
| zyga-arch | tests are leaking crap | 18:57 |
| zyga-arch | but that's for another moment | 18:57 |
| zyga-arch | janisozaur1: I'll add pkgver and push again | 18:59 |
| zyga-arch | thank you for the link | 18:59 |
| zyga-arch | ok try it! | 19:01 |
| mup | PR snapd#3649 opened: packaging: update arch packaging for 2.27 snapshot <Created by zyga> <https://github.com/snapcore/snapd/pull/3649> | 19:02 |
| zyga-arch | and please comment on https://github.com/snapcore/snapd/pull/3649 | 19:02 |
| mup | PR snapd#3649: packaging: update arch packaging for 2.27 snapshot <Created by zyga> <https://github.com/snapcore/snapd/pull/3649> | 19:02 |
| zyga-arch | I also commented on https://forum.snapcraft.io/t/updates-to-snapd-package-on-arch/1467/6 | 19:04 |
| zyga-arch | aww | 19:15 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| zyga-arch | I got one odd test failure but I didn't change that branch, feels like tab/spaces thing | 19:18 |
| zyga-arch | janisozaur1: any luck? | 19:19 |
| zyga-arch | janisozaur1: I replied on your comment | 19:20 |
| zyga-arch | janisozaur1: let me know how it works with various snaps | 19:20 |
| zyga-arch | I definitely want to look into GLX issues but given my environment (libvirt vm with virtio GPU) I'm not sure that is representative | 19:20 |
| zyga-arch | I need to boot natively and see how it works | 19:21 |
| zyga-arch | but, if you are native today you can tell me how it works for yoiu | 19:21 |
| zyga-arch | you* | 19:21 |
| janisozaur1 | after realoading the daemon i can get textual things to work | 19:21 |
| zyga-arch | what is the hardware you are on? | 19:22 |
| janisozaur1 | i7 4790, geforce 960 | 19:22 |
| zyga-arch | I see | 19:22 |
| zyga-arch | I see DNS resolution issues | 19:22 |
| zyga-arch | wethr snap for instance | 19:22 |
| zyga-arch | doesn't work | 19:23 |
| janisozaur1 | trying to run glxinfo definitely does not work | 19:23 |
| janisozaur1 | > [1] 9519 segmentation fault (core dumped) snap run gl-test-janisozaur.glxinfo | 19:23 |
| zyga-arch | janisozaur1: do a local test | 19:23 |
| zyga-arch | rebuild without --with-nvidia-arch | 19:23 |
| zyga-arch | and see if that changes anything | 19:23 |
| zyga-arch | after doing this you must "sudo unmount /run/snapd/ns/$SNAP_NAME.mnt" | 19:23 |
| janisozaur1 | `--enable-nvidia-arch`? | 19:24 |
| janisozaur1 | it's already in PKGBUILD, though | 19:24 |
| zyga-arch | right | 19:25 |
| zyga-arch | remove it | 19:25 |
| zyga-arch | without it :) | 19:25 |
| zyga-arch | I think it causes the crash | 19:25 |
| zyga-arch | it does some crazy things | 19:25 |
| zyga-arch | *ahem* | 19:25 |
| zyga-arch | I wonder who wrote that | 19:25 |
| janisozaur1 | :P | 19:25 |
| zyga-arch | I should have never done that | 19:25 |
| zyga-arch | without this option you are not going to mix anything from the snap world with the distro world | 19:25 |
| janisozaur1 | i can try that same package on intel gpu | 19:25 |
| zyga-arch | all we need from the system is a running kernel | 19:26 |
| zyga-arch | so if you have the GPU driver module in place | 19:26 |
| zyga-arch | we need a snap with the userspace proprietary bits that is built using a compatible compiler | 19:26 |
| zyga-arch | (compatible with the base/core snap of the snap the app requires) | 19:26 |
| zyga-arch | and then it will work | 19:26 |
| zyga-arch | we're interested in fixing it but it's not super high on the priority list yet | 19:27 |
| zyga-arch | (GNOME theme support is first) | 19:27 |
| zyga-arch | along with other general feature work | 19:27 |
| zyga-arch | but with some experiments it could be made to work | 19:27 |
| zyga-arch | nothing trivial though | 19:27 |
| janisozaur1 | are there any standard debugging snaps? | 19:28 |
| zyga-arch | janisozaur1: depends on what you want | 19:28 |
| zyga-arch | you can always run "snap run --shell snapname.appname | 19:28 |
| zyga-arch | that will drop you into bash instead of whatever the command was | 19:28 |
| zyga-arch | so | 19:28 |
| zyga-arch | I can confirm that I don't get a working resolver | 19:28 |
| zyga-arch | because /etc/nsswitch.conf uses files mymachines resolve | 19:29 |
| zyga-arch | I need to patch this, one sec | 19:29 |
| janisozaur1 | one with glxinfo? | 19:29 |
| zyga-arch | (this is just another bug out of the old design mistake to share /etc) | 19:29 |
| zyga-arch | I don't know any actually | 19:29 |
| zyga-arch | but | 19:29 |
| zyga-arch | you can do some crazy stuff by accessing it from the real filesystem | 19:29 |
| zyga-arch | from /run/snapd/hostfs | 19:29 |
| zyga-arch | not sure if it will work | 19:30 |
| janisozaur1 | can i list apps of a installed snap? | 19:30 |
| zyga-arch | you may need to set library search path | 19:30 |
| zyga-arch | jamespage: snap info $SNAP_NAME | 19:30 |
| zyga-arch | commands: section | 19:30 |
| janisozaur1 | > error: cannot find signatures with metadata for snap "/home/janisozaur/gears_gears_amd64.snap" | 19:31 |
| janisozaur1 | say whaaaa? | 19:31 |
| zyga-arch | sudo snap install --dangerous | 19:34 |
| zyga-arch | snaps come with assertions that describe what the snap is, who made it, etc | 19:34 |
| zyga-arch | this is the root of trust and permissions | 19:34 |
| zyga-arch | those are *separate* from the actual image as they come from the store, signed | 19:34 |
| zyga-arch | you can install a locally built snap with --dangerous | 19:35 |
| janisozaur1 | right, I was using it yesterday, a minor brainfart today | 19:35 |
| zyga-arch | ok, rebuilding with one more patch | 19:37 |
| zyga-arch | if this works I'll open another PR and push an update | 19:37 |
| zyga-arch | this should fix DNS | 19:38 |
| zyga-arch | really the next step is to run comprehensive suite of integrationtests | 19:39 |
| janisozaur1 | on the other system, where i installed the same pacman package, trying to run a snap: | 19:39 |
| zyga-arch | but those take more time to integrate with | 19:39 |
| janisozaur1 | > cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_SVXQPd//dev: No such file or directory | 19:39 |
| zyga-arch | unmount anything in /run/snapd/ns/ | 19:39 |
| zyga-arch | that *may* be at fauld | 19:39 |
| zyga-arch | *fault | 19:39 |
| zyga-arch | and check if you have "core" in "snap list" | 19:40 |
| zyga-arch | hmm | 19:41 |
| zyga-arch | no luck | 19:42 |
| zyga-arch | so | 19:42 |
| zyga-arch | how does it work? | 19:42 |
| zyga-arch | my /etc/hostname is 127.0.0.1 | 19:42 |
| janisozaur1 | I've unmounted /run/snapd/ns/ | 19:42 |
| zyga-arch | is that dnsmasq running as a local resolver? | 19:42 |
| janisozaur1 | now i get | 19:42 |
| janisozaur1 | > core 2462 canonical broken | 19:42 |
| zyga-arch | woah? | 19:43 |
| zyga-arch | are you in snap run --shell shell? | 19:43 |
| zyga-arch | or on the "outside" | 19:43 |
| zyga-arch | and can you run snap list | 19:43 |
| janisozaur1 | outside, that's from snap list | 19:43 |
| zyga-arch | and check /var/lib/snapd/snap/ | 19:43 |
| zyga-arch | is the core snap mounted there? | 19:43 |
| zyga-arch | "broken" says it cannot read the mounted snap | 19:43 |
| zyga-arch | specifically meta/snap.yaml | 19:44 |
| zyga-arch | so | 19:45 |
| janisozaur1 | no, empty | 19:45 |
| zyga-arch | is there a systemd unit for the core snap | 19:45 |
| zyga-arch | maybe something is broken | 19:45 |
| zyga-arch | in /etc/systemd/system | 19:45 |
| zyga-arch | you should see var-lib-snapd-snap-core-2462.mount | 19:45 |
| janisozaur1 | `systemctl| grep snap` says nothing about core | 19:46 |
| zyga-arch | if you start that unit it should work | 19:46 |
| janisozaur1 | yes, much better now | 19:46 |
| janisozaur1 | and custom snap runs work now too | 19:47 |
| janisozaur1 | trying to run glxinfo on that machine with intel gpu: https://hastebin.com/doneyaxolu.md | 19:48 |
| janisozaur1 | zyga-arch: can I PM you? | 19:52 |
| === JanC is now known as Guest87139 | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapd#3650 opened: cmd/snap-confine: don't share /etc/nsswitch from host <Created by zyga> <https://github.com/snapcore/snapd/pull/3650> | 20:08 |
| zyga-arch | janisozaur1: re | 20:12 |
| zyga-arch | sure | 20:12 |
| zyga-arch | I was rebooting to figure out what was wrong on my setup | 20:12 |
| zyga-arch | all fixed now | 20:12 |
| mup | PR snapd#3647 closed: gitignore: ignore more build artefacts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3647> | 20:32 |
| mup | PR snapd#3644 closed: cmd: fix tests that assume /snap mount <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3644> | 20:33 |
| mup | PR snapd#3645 closed: cmd: mark arch as non-reexecing distro <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3645> | 20:33 |
| mup | PR snapd#3646 closed: snap/snapenv: always expect /snap for $SNAP <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3646> | 20:34 |
| cratliff | Has anyone booted a core image recently? I've been trying to generate one and if I reboot the device it cannot find the kernel snap. I've tried kvm and running on a physical pc, this is using the pc-kernel and my custom kernel snap and I keep seeing the same issue. | 21:20 |
| cratliff | If anyone is interested this is the json used to generate the model. | 21:31 |
| cratliff | { "type": "model", "series": "16", "model": "truck", "architecture": "amd64", "gadget": "pc", "kernel": "pc-kernel", "authority-id": "", "brand-id": "", "timestamp": "2017-08-02T15:29:45+00:00", "required-snaps": ["bluez", "network-manager", "dnsmasqd"] } | 21:31 |
| om26er | if a restricted snap is connected to snapd-control interface, does that allow it to be able to talk to snapd commandline interface ? | 21:37 |
| om26er | s/restricted/confined. | 21:37 |
| cratliff | Sorry, how would I check that? | 21:43 |
| mwhudson | well https://github.com/snapcore/snapd/pull/3639 didn't go so well | 23:28 |
| mup | PR snapd#3639: Update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639> | 23:28 |
| mwhudson | i'm fairly confused as to what actually broke though | 23:28 |
| mwhudson | oh eh what? | 23:29 |
| mwhudson | src/github.com/snapcore/snapd/vendor/golang.org/x/crypto/acme/acme.go:18:2: cannot find package "context" in any of: | 23:29 |
| mwhudson | oh right, x/crypto no longer compatible with 1.6 i guess | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!