| mborzecki | morning | 06:01 |
|---|---|---|
| mborzecki | mvo: morning | 06:48 |
| mborzecki | mvo: do you know the story behind disabling setting up XDG_RUNTIME_DIR? i'm looking at https://bugs.launchpad.net/snappy/+bug/1738197 and the dir is not created | 06:52 |
| mup | Bug #1738197: Daemons do not have an /run/user/* dir created <Snappy:New> <https://launchpad.net/bugs/1738197> | 06:52 |
| mborzecki | the piece of code that created runtime dir was disabled with this commit https://github.com/snapcore/snapd/commit/7ea43f1c74e1e056250359031cb715cb85adb349 but there's no message or anything | 06:53 |
| mvo | hey mborzecki good morning | 06:59 |
| mvo | mborzecki: I don't remember the backstory :( and the commit description does not help much. I think zyga will remember | 07:00 |
| mborzecki | mvo: i also found this PR https://github.com/snapcore/snap-confine/pull/195 | 07:01 |
| mup | PR snap-confine#195: Fix creation of $XDG_RUNTIME_DIR and $SNAP_USER_DATA <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snap-confine/pull/195> | 07:01 |
| mborzecki | opened and closed by zyga, i suppose there were some security concerns raised by jdstrand | 07:01 |
| mborzecki | mvo: switched to bug report to confirmed for now | 07:03 |
| mvo | ta | 07:08 |
| mup | PR snapd#4519 opened: arch: add "armv8l" to ubuntuArchFromKernelArch table <Created by mvo5> <https://github.com/snapcore/snapd/pull/4519> | 07:24 |
| mup | Bug #1738222 changed: FAIL: main_test.go:769: snapSeccompSuite.TestCompatArchWorks <Snappy:Fix Released by maciek-borzecki> <https://launchpad.net/bugs/1738222> | 07:31 |
| mup | Bug #1705220 changed: Removing desktop-ubuntu-app-platform broke any app relying on the webapp-helper <amd64> <apport-bug> <artful> <julyshakedown> <third-party-packages> <Snappy:Invalid> <snapcraft (Ubuntu):Invalid> <https://launchpad.net/bugs/1705220> | 07:40 |
| zyga-ubuntu | o/ | 07:54 |
| kalikiana | moin moin | 08:00 |
| mborzecki | zyga-ubuntu: kalikiana: morning | 08:01 |
| zyga-ubuntu | what is armv8l? | 08:01 |
| pstolowski | mornings! | 08:03 |
| zyga-ubuntu | can anyone please do 2nd review for https://github.com/snapcore/snapd/pull/3963 | 08:04 |
| mup | PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963> | 08:04 |
| zyga-ubuntu | pstolowski, mvo: can you please give concrete votes on 4505, I'd like to know if there's more work there or can I iterate on top | 08:07 |
| mup | PR snapd#4519 closed: arch: add "armv8l" to ubuntuArchFromKernelArch table <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4519> | 08:08 |
| kalikiana | o/ mborzecki pstolowski zyga-ubuntu | 08:13 |
| pstolowski | zyga-ubuntu, looking | 08:15 |
| mup | PR snapd#4520 opened: daemon: unlock state even if RefreshSchedule() fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4520> | 08:15 |
| zyga-ubuntu | mvo: you didn't add the mount unit | 08:16 |
| zyga-ubuntu | thanks! | 08:16 |
| mvo | zyga-ubuntu: meh, sorry and thanks | 08:20 |
| mvo | zyga-ubuntu: are the spread tests under cmd/snap-confine still run? | 08:20 |
| mvo | zyga-ubuntu: I ask because there is one that is concerned with snappy-app-dev and this needs to move to /usr/lib/snapd to work with bases | 08:21 |
| mborzecki | 4520 ^^ trivial review | 08:22 |
| mup | PR snapd#4521 opened: many: move /lib/udev/snappy-app-dev to /usr/lib/snapd/snappy-app-dev <Created by mvo5> <https://github.com/snapcore/snapd/pull/4521> | 08:38 |
| zyga-ubuntu | mvo: no, only those in tests/ are used | 08:40 |
| zyga-ubuntu | mvo: there are probably a few stale tests under snap-confine | 08:40 |
| mvo | zyga-ubuntu: do you mind if I remove at least the one dealing with snappy-app-dev? | 08:40 |
| zyga-ubuntu | mvo: do they hurt? I think those should be (eventually) ported and re-enabled | 08:41 |
| zyga-ubuntu | mvo: is that test actually running now? | 08:42 |
| zyga-ubuntu | mvo: and relevant to the discussion is https://github.com/snapcore/snapd/pull/4399 | 08:42 |
| mup | PR #4399: rewrite snappy-app-dev <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4399> | 08:42 |
| pstolowski | zyga-ubuntu, reviewed, some tiny remarks | 08:43 |
| zyga-ubuntu | pstolowski: thank you! looking | 08:44 |
| Chipaca | zyga-ubuntu: that traceback and error, is that fedora in our tests, or in the wild? | 08:47 |
| zyga-ubuntu | Chipaca: I think that was in the tests that cachio ran | 08:47 |
| Chipaca | the net.Error case is new, but the tricky code existed before | 08:47 |
| Chipaca | I'll push something | 08:48 |
| zyga-ubuntu | question | 08:50 |
| zyga-ubuntu | when you hack on go | 08:50 |
| zyga-ubuntu | do you keep a symlink in ~ to the $GOPATH/src/yadayadayada directory? | 08:50 |
| zyga-ubuntu | I ask because I do and I hate how go fmt is stupid and doesn't cope with that | 08:50 |
| Chipaca | zyga-ubuntu: I don't understand what you symlink | 09:08 |
| Chipaca | zyga-ubuntu: in any case, no i don't keep a symlink in ~ to that :-) | 09:09 |
| zyga-ubuntu | Chipaca: ~/snapd -> ~/go/src/github.com/snapcore/snapd | 09:10 |
| zyga-ubuntu | pstolowski: updated | 09:10 |
| pstolowski | zyga-ubuntu, k, looking | 09:10 |
| Chipaca | zyga-ubuntu: I just ^R cd ~ and it completes that :-) | 09:11 |
| Chipaca | zyga-ubuntu: but it helps that I just have two go workspaces i work in with any frequency, snapd and my personal one | 09:12 |
| Chipaca | if i had more i'd need to get inventive | 09:12 |
| pstolowski | zyga-ubuntu, thanks for the helpers! looks very nice! | 09:13 |
| pstolowski | +1 | 09:14 |
| zyga-ubuntu | pstolowski: thank you for the idea, I will use them in the rest of the code next | 09:19 |
| zyga-ubuntu | Chipaca: I see, thanks | 09:19 |
| Chipaca | did we have a checker for "it's one of these two"? | 09:20 |
| zyga-ubuntu | Chipaca: so, I feel like I could benefit from your walker and container validation thing | 09:20 |
| zyga-ubuntu | Chipaca: I could use it to validate that the layout makes sense | 09:21 |
| zyga-ubuntu | Chipaca: you could abuse "contains" checker in reverse, I presume | 09:21 |
| zyga-ubuntu | offtopic: my new favourite theme: agola green | 09:22 |
| Chipaca | zyga-ubuntu: ebola green? | 09:22 |
| zyga-ubuntu | https://packagecontrol.io/packages/Agola%20Color%20Schemes | 09:22 |
| Chipaca | zyga-ubuntu: i'll push this pr and then fix my container thing | 09:23 |
| zyga-ubuntu | Chipaca: thanks, it's not urgent, just something I realized | 09:26 |
| Chipaca | aaand i've just done the old "committed to my master and pushed" idiocy | 09:28 |
| zyga-ubuntu | Chipaca: classic, I do that all the time | 09:28 |
| * Chipaca now needs to go to github, flip a flag, push force, flip it back | 09:28 | |
| zyga-ubuntu | pstolowski: can you look at https://github.com/snapcore/snapd/pull/4502 please, it's related | 09:28 |
| mup | PR #4502: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502> | 09:28 |
| zyga-ubuntu | pstolowski: probably will do a round of similar changes there | 09:28 |
| mup | PR snapd#4520 closed: daemon: unlock state even if RefreshSchedule() fails <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4520> | 09:29 |
| zyga-ubuntu | mvo: https://github.com/snapcore/snapd/pull/4516 is green now but I'm not sure if we want to merge it yet | 09:30 |
| mup | PR #4516: spread: setup machine creation on Linode <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4516> | 09:30 |
| pstolowski | zyga-ubuntu, sure | 09:30 |
| mup | PR snapd#4522 opened: daemon: avoid panic'ing building an error response w/no snaps given <Created by chipaca> <https://github.com/snapcore/snapd/pull/4522> | 09:31 |
| Chipaca | zyga-ubuntu: ^ should address the issue | 09:31 |
| zyga-ubuntu | Chipaca: +1 | 09:33 |
| zyga-ubuntu | mvo: commented on 4517 | 09:37 |
| mvo | zyga-ubuntu: thanks, I am not hopefully for any of these approaches | 09:44 |
| zyga-ubuntu | mvo: what do you think will happen? | 09:44 |
| mvo | zyga-ubuntu: I have the feeling we need something more fundamental or more targeted, the problem is right now e.g. apt remove snapd fails because /snap is probably busy | 09:44 |
| zyga-ubuntu | mvo: yuck, that's indeed bad | 09:45 |
| zyga-ubuntu | mvo: so | 09:45 |
| mvo | zyga-ubuntu: so something more fundamental would be good except that we can't ship it in other distros :/ | 09:45 |
| zyga-ubuntu | mvo: maybe time to share one (very weird and crazy) idea | 09:45 |
| mvo | zyga-ubuntu: more targeted may mean to just run this bind,share if condition=virtual is meet | 09:45 |
| mvo | zyga-ubuntu: sure, share! | 09:45 |
| zyga-ubuntu | mvo: you can do this: | 09:45 |
| zyga-ubuntu | mvo: mkdir foo | 09:45 |
| zyga-ubuntu | mvo: in one terminal unshare, mount --bind foo foo | 09:46 |
| zyga-ubuntu | mvo: in another terminal, afterwards, rmdir foo | 09:46 |
| zyga-ubuntu | mvo: this works | 09:46 |
| zyga-ubuntu | mvo: now, this lets us make a namespace where a bind mount is present and where we can do whatever we want | 09:46 |
| zyga-ubuntu | mvo: here's a crazy idea | 09:46 |
| zyga-ubuntu | mvo: what if we did all the rsharing in a mount namespace snap-confine implicitly joins as soon as it starts | 09:46 |
| mvo | zyga-ubuntu: hm, if that works, +1 | 09:47 |
| zyga-ubuntu | mvo: that ns could be a slave of the real thing | 09:47 |
| zyga-ubuntu | mvo: and it could do all the magic needed that wouldn't leak outside | 09:47 |
| zyga-ubuntu | mvo: so apt and friends can remove things as they usually do | 09:47 |
| zyga-ubuntu | mvo: not sure, just thought about it, I can give it a try | 09:47 |
| mvo | zyga-ubuntu: please, I will poke around a bit more but I doubt the current mount unit approach is feasible | 09:48 |
| zyga-ubuntu | mvo: I wonder if this can be fixed in containers | 09:51 |
| zyga-ubuntu | mvo: maybe lxd can just do the right thing | 09:51 |
| === chihchun_afk is now known as chihchun | ||
| zyga-ubuntu | Failed to issue method call: Unit snap.mount.service failed to load: No such file or directory. See system logs and 'systemctl status snap.mount.service' for details. | 09:57 |
| zyga-ubuntu | is it snap.mount or snap.mount.service? | 09:57 |
| zyga-ubuntu | looks like a simple error there mvo | 09:57 |
| mup | PR snapd#4505 closed: interfaces/mount,snap: early support for snap layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4505> | 09:59 |
| === chihchun is now known as chihchun_afk | ||
| mvo | zyga-ubuntu: indeed, let me fix, it should be snap.mount only | 10:07 |
| zyga-ubuntu | Chipaca: hey | 11:00 |
| zyga-ubuntu | your change broke one very unexpected place | 11:00 |
| zyga-ubuntu | + echo 'error: cannot install ["test-snapd-classic-confinement"]: classic confinement | 11:00 |
| zyga-ubuntu | requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap' | 11:00 |
| zyga-ubuntu | error: pattern not found, got: | 11:00 |
| zyga-ubuntu | see ["foo"] vs "foo" | 11:00 |
| zyga-ubuntu | error: cannot install ["test-snapd-classic-confinement"]: classic confinement requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap | 11:00 |
| Chipaca | zyga-ubuntu: hah. Not _that_ unexpected | 11:00 |
| Chipaca | zyga-ubuntu: in fact i was wondering if that'd come up | 11:00 |
| Chipaca | zyga-ubuntu: I can fix :-) | 11:00 |
| Chipaca | thanks for the heads-up | 11:00 |
| zyga-ubuntu | mvo: snap.mount doesn't work :/ | 11:01 |
| zyga-ubuntu | Removing snapd (1337.2.30) ... | 11:01 |
| zyga-ubuntu | Job for snap.mount failed. See "systemctl status snap.mount" and "journalctl -xe" for details. | 11:01 |
| zyga-ubuntu | dpkg: error processing package snapd (--purge): | 11:01 |
| zyga-ubuntu | :-( | 11:01 |
| mvo | zyga-ubuntu: yeah, I was afraid this would happen | 11:05 |
| mvo | zyga-ubuntu: snap.mount cannot be stopped as the mount point is busy. but we cannot make it not-busy unless we purge | 11:05 |
| zyga-ubuntu | hmm hmm hmm | 11:06 |
| zyga-ubuntu | but why is it busy | 11:06 |
| zyga-ubuntu | it is busy because it is a mount point? | 11:06 |
| zyga-ubuntu | maybe what we need is a bind mount from /var/lib/snapd/snap to /snap | 11:06 |
| zyga-ubuntu | maybe it's a systemd bug | 11:06 |
| zyga-ubuntu | I would presume systemd would stop all the snap mount units inside first | 11:06 |
| zyga-ubuntu | then stop snap.mount | 11:06 |
| mvo | niemeyer: you mentioned yesterday that you want to learn more about the writable handling for etc and var, I wrote a summary of the status now and a proposal into https://forum.snapcraft.io/t/writing-to-etc-and-var-from-the-core-snap/3653 | 11:07 |
| mvo | zyga-ubuntu: I think it is because /snap/* is still available on remove, we only get rid of the actual snaps on purge | 11:08 |
| zyga-ubuntu | mvo: hmmm, | 11:08 |
| zyga-ubuntu | mvo: but if dpkg starts this, dpkg first should run prerm script | 11:08 |
| zyga-ubuntu | mvo: do we stop services and unmount snaps in prerm? | 11:09 |
| zyga-ubuntu | iff we do, it could just work | 11:09 |
| mborzecki | zyga-ubuntu: can you try to use snap-mgmt in prerm? | 11:10 |
| zyga-ubuntu | mborzecki: I think we should unify script management but it's hard due to way dpkg handles files | 11:11 |
| zyga-ubuntu | mborzecki: it'd be easier if our build system split snap-mgmt and injected it into actual dpkg management scripts | 11:11 |
| mvo | zyga-ubuntu: we could do that, yes. it would be different from what we are doing currently. i.e. we leave the snaps and only purge on purge | 11:11 |
| zyga-ubuntu | mborzecki: as those have differnet lifecycle from the other package files | 11:11 |
| zyga-ubuntu | mvo: actually... | 11:12 |
| zyga-ubuntu | mvo: we only have to unmount /snap on purge too | 11:12 |
| zyga-ubuntu | mvo: can we make dpkg ingore /snap? | 11:12 |
| zyga-ubuntu | mvo: if we don't ship it | 11:12 |
| zyga-ubuntu | mvo: just create it in a script:? | 11:12 |
| mvo | zyga-ubuntu: yeah, we would have to create it in postinst and manage it manually | 11:12 |
| mvo | zyga-ubuntu: ugly as **** but worth a try | 11:13 |
| Chipaca | zyga-ubuntu: tweaked #4522 a little, should address that failure you saw (and be a little nicer) | 11:15 |
| mup | PR #4522: daemon: avoid panic'ing building an error response w/no snaps given <Created by chipaca> <https://github.com/snapcore/snapd/pull/4522> | 11:15 |
| zyga-ubuntu | Chipaca: nice, looking | 11:15 |
| Chipaca | when it's just one snap, error message should now be identical to what it was before | 11:16 |
| zyga-ubuntu | ++ | 11:16 |
| zyga-ubuntu | yep | 11:16 |
| Chipaca | when it's something else, it'll be something else :-) but nicer | 11:16 |
| Chipaca | also less duplication, in exchange for some shenaniganry | 11:17 |
| Chipaca | (take *that*, branch predictor!) | 11:19 |
| Chipaca | hmmmmm | 11:33 |
| * Chipaca fixes the fix | 11:33 | |
| mup | PR snapd#4522 closed: daemon: avoid panic'ing building an error response w/no snaps given <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4522> | 11:58 |
| Chipaca | is raspbian always armel? | 12:05 |
| ackk | kalikiana, hi, do you think https://github.com/snapcore/snapcraft/pull/1617 can be merged now? | 12:07 |
| mup | PR snapcraft#1617: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617> | 12:07 |
| zyga-ubuntu | cachio: observation: go test ./... is far far far faster than our run checks --unit | 12:13 |
| zyga-ubuntu | actually, can you guys please: time go test ./... | 12:14 |
| zyga-ubuntu | from the top of the tree | 12:14 |
| cachio | zyga-ubuntu, I'll try it | 12:15 |
| zyga-ubuntu | pstolowski: Attr() cannot be used to check if an attribute of _any_ type exists | 12:19 |
| zyga-ubuntu | passing interface{} won't cut it | 12:19 |
| zyga-ubuntu | ideas? | 12:19 |
| zyga-ubuntu | pstolowski: I'd like to add HasAttr() | 12:19 |
| pstolowski | zyga-ubuntu, I know. I've addressed this in #4510 | 12:20 |
| mup | PR #4510: asserts: use Attrer in policy checks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510> | 12:20 |
| zyga-ubuntu | ah, nice | 12:20 |
| zyga-ubuntu | hmm hmm | 12:20 |
| zyga-ubuntu | ok, I'll add a todo and wait | 12:21 |
| pstolowski | zyga-ubuntu, note, attributes can be nested. in 4510 I've also added support for dotted paths. HasAttr() will only make sense with dotted paths I guess | 12:21 |
| kalikiana | ackk: I'd suggest to check with kyrofa - I don't have merge powers :-D | 12:21 |
| pstolowski | zyga-ubuntu, 4510 needs Samuele's review.. not sure if you can wait till he is back? | 12:22 |
| mup | PR snapd#4506 closed: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4506> | 12:22 |
| zyga-ubuntu | pstolowski: I think this is fine, I added a TODO note to use Lookup | 12:23 |
| Chipaca | zyga-ubuntu: snap.ValidateContainer on master | 12:23 |
| zyga-ubuntu | Chipaca: I saw, thank you! | 12:23 |
| Chipaca | k | 12:23 |
| pstolowski | zyga-ubuntu, k | 12:23 |
| zyga-ubuntu | Chipaca: so with that, I will probably look at making it useful for validating layout | 12:24 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/4329 needs a 2nd review | 12:24 |
| mup | PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329> | 12:24 |
| mup | PR snapd#4523 opened: interfaces/builtin: allow introspecting UDisks2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4523> | 12:33 |
| zyga-ubuntu | mborzecki: about 4523 | 12:38 |
| zyga-ubuntu | mborzecki: does the new xml snippet mean anyone can introspect udisks? | 12:38 |
| zyga-ubuntu | I think the plug apparmor part must define something like that too | 12:39 |
| zyga-ubuntu | ah, it already does that | 12:39 |
| mborzecki | zyga-ubuntu: yeah, it was missing from the slot | 12:39 |
| mborzecki | zyga-ubuntu: once i got that, the dbus rule was disallowing calls to Introspectable :/ | 12:40 |
| mborzecki | dbus snakepit | 12:40 |
| zyga-ubuntu | hmm | 12:54 |
| zyga-ubuntu | Chipaca: so, for containers, did you come up with a practical way to mock them? | 12:54 |
| Chipaca | zyga-ubuntu: simplest way is to use a snapdir | 12:54 |
| Chipaca | zyga-ubuntu: look at the tests of validate container in snap/container_test.go | 12:55 |
| zyga-ubuntu | mmm | 12:55 |
| zyga-ubuntu | yeah, I just need to tweak my code to accept a container | 12:55 |
| zyga-ubuntu | and not attempt to derive one from snap info | 12:55 |
| zyga-ubuntu | that will be much nicer for testing | 12:55 |
| mup | PR snapd#4515 closed: tests: new spread test for netlink-audit interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4515> | 13:26 |
| === ogasawara_ is now known as ogasawara | ||
| === ogasawara is now known as Guest58359 | ||
| * zyga-ubuntu jumps for quick lunchj | 13:44 | |
| * kalikiana going for lunch (and yay, a little bit of sun) | 13:51 | |
| Chipaca | niemeyer: https://forum.snapcraft.io/t/snapshots-implementation-details/3656 | 13:53 |
| Chipaca | niemeyer: i think that touches on the bits that were making you nervous, or for which you were lacking context | 13:54 |
| Chipaca | getting it working so you can play with it is what i'm working towards, eta tomorrow | 13:55 |
| Chipaca | notably the switch to zip at the toplevel was painless :-) | 13:55 |
| niemeyer | Chipaca: Thanks! I'm actually kinda nervous that we didn't talk much about the overall design.. I'm worried of introducing late suggestions that would make you cringe | 13:56 |
| Chipaca | niemeyer: I know you'll persevere and do it anyways :-) | 13:57 |
| Chipaca | niemeyer: (i'm joking; bring on the suggestions) | 13:57 |
| niemeyer | Chipaca: I'll try to see that as a compliment :D | 13:57 |
| Chipaca | niemeyer: are those suggestions going to be on the forum? | 14:02 |
| niemeyer | Chipaca: We should definitely at least have a summary there, but depending on the topics to be covered a call might be nice.. I'll ping you this afternoon in either case | 14:03 |
| niemeyer | cachio: That unit test takes about 10 minutes alone | 14:08 |
| niemeyer | cachio: This is definitely making a significant impact on the overall test, because it's mixed in with all the other tests | 14:09 |
| niemeyer | Imagine what happens if systems are all happy churning, and then at the 20 minutes mark they start running unit tests, for example | 14:10 |
| niemeyer | That's probably one of the reasons why we fail to improve the overall test performance.. I'll have a look into this today | 14:11 |
| niemeyer | In any case, " Ran for 25 min 49 sec" | 14:11 |
| * pstolowski lunch | 14:12 | |
| cachio | niemeyer, ok, I'm researching that as well | 14:17 |
| cachio | niemeyer, thanks for the heads-up | 14:17 |
| * cachio afk | 14:25 | |
| * Chipaca afk for a bit | 14:40 | |
| kalikiana | re | 14:46 |
| greyback | jdstrand: question on an x11 slot. The X socket is hardcoded to /tmp/.X11-unix/X*. If X server is snapped, that /tmp is actually a private subdir of /tmp/$SNAP. I'm struggling to see a nice way to share the socket path with another snap that plugs in. Would the config system be a sensible way? | 14:52 |
| greyback | so the plug would call "snap get x11 socket" and get a path to the socket back | 14:53 |
| zyga-ubuntu | greyback: this is something that will be done via interface hooks | 14:54 |
| zyga-ubuntu | greyback: please look at this PR, the tests do something quite like this | 14:54 |
| greyback | zyga-ubuntu: interesting, looking... | 14:55 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/4358 | 14:55 |
| mup | PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358> | 14:55 |
| zyga-ubuntu | specifically... | 14:55 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/4358/files#diff-1ee943f85f142e4019d5625a0045a88dR7 | 14:56 |
| zyga-ubuntu | jdstrand: https://github.com/snapcore/snapd/pull/4523 needs your 2nd review (very short) | 14:56 |
| mup | PR #4523: interfaces/builtin: allow introspecting UDisks2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4523> | 14:56 |
| mup | PR snapd#4502 closed: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4502> | 14:57 |
| pstolowski | greyback, sounds like a good use case for interface hooks indeed. basically, on 'snap connect..' hooks are executed on plug and slot sides, and they can exchange data before connection is finalized | 14:59 |
| zyga-ubuntu | jdstrand: this PR https://github.com/snapcore/snapd/pull/4521 is related to your work | 15:01 |
| mup | PR #4521: many: move /lib/udev/snappy-app-dev to /usr/lib/snapd/snappy-app-dev <Created by mvo5> <https://github.com/snapcore/snapd/pull/4521> | 15:01 |
| greyback | pstolowski: yeah it sounds like it. Does it look far from landing? | 15:01 |
| zyga-ubuntu | mvo: https://github.com/snapcore/snapd/pull/4512 is green and needs a 2nd review | 15:01 |
| mup | PR #4512: tests: new spread test for ssh-public-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4512> | 15:01 |
| zyga-ubuntu | (we are getting close to having 3X reviews rather than 4X | 15:02 |
| jdstrand | zyga-ubuntu: re 4523, done. re 4521, ack (note that I put that on the backburner for the moment to get to other higher priority items) | 15:03 |
| pstolowski | greyback, my guess is probably a few weeks as there is some followup stuff that needs to land before we can enable the feature | 15:04 |
| greyback | pstolowski: ack, thanks | 15:04 |
| elopio | Hello! | 15:05 |
| zyga-ubuntu | jdstrand: ack | 15:06 |
| mup | PR snapd#4523 closed: interfaces/builtin: allow introspecting UDisks2 <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4523> | 15:06 |
| zyga-ubuntu | niemeyer: can we land https://github.com/snapcore/snapd/pull/4516 or do you need to do more tweaking on it? | 15:07 |
| mup | PR #4516: spread: setup machine creation on Linode <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4516> | 15:07 |
| zyga-ubuntu | (alternatively close it) | 15:07 |
| niemeyer | zyga-ubuntu: Still working on it | 15:08 |
| zyga-ubuntu | ack | 15:09 |
| zyga-ubuntu | cachio: https://github.com/snapcore/snapd/pull/4511 is failing for real | 15:11 |
| mup | PR #4511: tests: new spread test for ssh-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4511> | 15:11 |
| kyrofa | ackk, indeed, it seems that feature is contained in 2.30, which has made it to stable, in my mind it can be merged | 15:16 |
| kyrofa | I've updated it to bring it inline with master, the tests are running once more | 15:16 |
| ackk | kyrofa, cool, thanks | 15:16 |
| kyrofa | ackk, see sergio's comment on the PR. Are you up for that? | 15:28 |
| cachio | zyga-ubuntu, yes | 15:28 |
| cachio | also the issue that was seen in fedora should be considered, it failed to read ssh config file | 15:29 |
| cachio | zyga-ubuntu, now as we are not executing ssh to coonect any more the error is not being reproduced | 15:29 |
| zyga-ubuntu | cachio: not sure about fedora, the only thing I recall was an error in daemon/api.go - | 15:31 |
| zyga-ubuntu | cachio: there's ssh_config in the core snap so it should be there | 15:32 |
| zyga-ubuntu | cachio: did you investigate why it failed? | 15:32 |
| cachio | zyga-ubuntu, running it now | 15:32 |
| zyga-ubuntu | thank you! | 15:32 |
| brunosfer | Hey guys! I need a little help from you. I'm snapcrafting my application into a snap and I'm getting some errors importing a package I called bridge. The error is: "package bridge: unrecognized import path "bridge" (import path does not begin with hostname)" | 15:33 |
| zyga-ubuntu | brunosfer: that error looks like app specific thing | 15:38 |
| mup | PR snapcraft#1873 closed: elf: cleaner patchelf experience <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1873> | 15:38 |
| brunosfer | zyga-ubuntu: I think the snapcraft is trying to compile the package. However that package is a dependency of the project. | 15:39 |
| brunosfer | zyga-ubuntu: Is there a way in the yaml file where I can specify that the specific package is a dependency and it should not be compiled? | 15:39 |
| zyga-ubuntu | kyrofa: ^ | 15:40 |
| kyrofa | Hmm | 15:40 |
| mup | PR snapcraft#1865 closed: lxd: always (re-)injects snaps <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1865> | 15:41 |
| kyrofa | brunosfer, I'm afraid I don't quite understand the issue. Any chance you can share your YAML? | 15:41 |
| brunosfer | kyrofa: How do you suggest to share? | 15:43 |
| kyrofa | brunosfer, pastebin.ubuntu.com works pretty well | 15:43 |
| kyrofa | Unless you already have it in e.g. github | 15:44 |
| brunosfer | kyrofa: I'm gonna use pastebin, I don't have the project on github. | 15:44 |
| kyrofa | brunosfer, sure thing | 15:44 |
| brunosfer | kyrofa: Please check https://pastebin.ubuntu.com/26444892/ | 15:47 |
| cachio | zyga-ubuntu, https://paste.ubuntu.com/26444896/ | 15:48 |
| kyrofa | brunosfer, the `bridge` part is being built because you specified it as a part. Is that the one that's failing? | 15:49 |
| cachio | zyga-ubuntu, so, the file does not exist as part of the /etc/ssh/ | 15:50 |
| brunosfer | kyrofa: yes it is | 15:51 |
| brunosfer | kyrofa: yes it is | 15:51 |
| brunosfer | kyrofa: how should I specify it? | 15:51 |
| kyrofa | brunosfer, you mention that it's a dependency. A dependency of what? | 15:52 |
| zyga-ubuntu | cachio: hmm | 15:52 |
| zyga-ubuntu | cachio: that's interesting | 15:52 |
| zyga-ubuntu | cachio: maybe some kind of writable path magic? not sure | 15:52 |
| brunosfer | kyrofa: The package `bridge` is imported by the main package. | 15:53 |
| kyrofa | brunosfer, you probably don't need to specify it as a part, then | 15:54 |
| cachio | zyga-ubuntu, yes, not sure why it is there | 15:54 |
| cachio | mvo, any idea? | 15:54 |
| kyrofa | brunosfer, just specify the main part | 15:54 |
| zyga-ubuntu | cachio: probably because of this | 15:57 |
| zyga-ubuntu | https://github.com/snapcore/core-build/blob/master/config/etc/system-image/writable-paths#L50 | 15:57 |
| cachio | zyga-ubuntu, ouch | 15:58 |
| cachio | zyga-ubuntu, ok, in that case I could either to check on the core snap or skip it for core | 16:00 |
| cachio | zyga-ubuntu, I dont understand why is not mounting just 3 files | 16:02 |
| mvo | cachio: sorry, I miss context - you don't see a file or what is going on? | 16:02 |
| cachio | the ssh-config file is on /snap/core/x1/etc/ssh/ssh_config | 16:03 |
| cachio | and we are checking the file in /etc/ssh | 16:03 |
| cachio | it is happening just on core systems | 16:03 |
| cachio | mvo, so, we are no sure if it is an issue or is it ok that the file is just part of the core snap | 16:04 |
| mvo | cachio: the writable-path magic will not copy files there is /etc already exists | 16:04 |
| mvo | cachio: do you have a branch where this fails? | 16:04 |
| mvo | cachio: I'm still not sure I see the bigger picture | 16:04 |
| cachio | mvo, https://github.com/snapcore/snapd/pull/4511 | 16:04 |
| mup | PR #4511: tests: new spread test for ssh-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4511> | 16:05 |
| mvo | cachio: that is interessting, I'm sure its related to writable-paths. however when I try this on my pristine core device I have /etc/ssh/ssh_config | 16:10 |
| ogra_ | zyga-ubuntu, whats wrong with that writable-path line ? it defines that all content of the dir is copied to writable on first boot so that you have /etc/ssh on the running system | 16:10 |
| mvo | cachio: so it must be something related to our test setup | 16:10 |
| cachio | mvo, yes, probably | 16:10 |
| mvo | cachio: could you please run it with -debug so that we can see the content? | 16:11 |
| cachio | on how we create the core image | 16:11 |
| cachio | mvo, I have a debug open | 16:11 |
| cachio | what you want to see | 16:11 |
| mvo | cachio: ls -al /etc/ssh for a start :) | 16:12 |
| ogra_ | note that the writable-paths are processed by the initrd on first boot ... before you booted for the first time all these dirs will be empty | 16:13 |
| ogra_ | (in case you poke around in an unbooted image there) | 16:13 |
| cachio | mvo, https://paste.ubuntu.com/26445000/ | 16:14 |
| ogra_ | looks broken ... | 16:15 |
| mvo | cachio: and ls -al /snap/core/current/etc/ssh please? | 16:15 |
| cachio | https://paste.ubuntu.com/26445012/ | 16:16 |
| mvo | cachio: ok, the issue is with prepare.sh | 16:18 |
| * ogra_ points to http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html and specifically the description in paragraph 4 (transition) | 16:18 | |
| ogra_ | "WARNING: This is a one-off operation which requires that the | 16:18 |
| ogra_ | source directory on the writable partition not exist | 16:18 |
| ogra_ | initially: if this condition is satisfied, the directory will | 16:18 |
| ogra_ | then be created and the data moved on first boot. Although | 16:18 |
| ogra_ | the mountpoint will be writable, note that subsequent boots | 16:18 |
| ogra_ | will ignore any new files appearing or disappearing in the | 16:18 |
| ogra_ | original read-only rootfs location unless you perform a | 16:18 |
| ogra_ | factory reset." | 16:18 |
| mvo | cachio: we write a custom /etc/ssh/sshd_config into /writable and this prevents the writable-paths stuff to copy things because the dir already exists, this is only an inssue in the test. give me 2min and there should be a pastebin with the fix | 16:19 |
| niemeyer | cachio: I can confirm the theory.. | 16:19 |
| mvo | cachio: please try https://paste.ubuntu.com/26445024/ | 16:19 |
| ogra_ | makin it synced might help here | 16:19 |
| mvo | ogra_: yeah, that would also work | 16:19 |
| niemeyer | cachio: Found logs showing the Go unit tests starting to run 21 minutes into the logs | 16:20 |
| niemeyer | Which pushes the full run into 30+ minutes even if everything else has finished | 16:20 |
| niemeyer | I'm tuning it | 16:20 |
| cachio | niemeyer, 21 minutes? | 16:20 |
| niemeyer | cachio: Yeah, after 21 minutes of everything else working, the long task kicked in | 16:20 |
| cachio | niemeyer, are you going the define something like order on spread? | 16:21 |
| niemeyer | cachio: Maybe.. in the first experiment I'll just isolate these tasks in their own system to force parallelism.. that's less ideal than defining ordering because the systems are trashed after the task is done.. priority ordering would be better because the systems can be reused | 16:23 |
| cachio | mvo, so, for ubuntu-core I should check inside the core snap, right? | 16:23 |
| brunosfer | kyrofa: The error is exactly that! When I specify the main as a part. The snapcraft tool doesn't recognize the `bridge`. | 16:23 |
| mvo | cachio: just check /etc/ssh/ssh_config and apply the patch I pastebined to your PR and things should work | 16:23 |
| mvo | cachio: i.e. just apply my pastebin :) | 16:24 |
| cachio | ok, running | 16:24 |
| mvo | cachio: and re-run the test and it should be fine | 16:24 |
| brunosfer | kyrofa: The error is: "package bridge: unrecognized import path "bridge" (import path does not begin with hostname)" | 16:24 |
| kyrofa | brunosfer, ah, so you get that error if you remove the bridge part? | 16:24 |
| cachio | mvo, I'll tell you the result | 16:25 |
| cachio | niemeyer, otherwise we could split the unit test to make smaller tasks | 16:25 |
| brunosfer | kyrofa: Yes. When I remove the `bridge` as a part and I only set as a part the `main` I get that error and I don't know why. | 16:25 |
| cachio | niemeyer, that could help too | 16:26 |
| niemeyer | cachio: Yes, but that'd be a bit boring to maintain over time | 16:26 |
| mup | PR snapd#4524 opened: cmd: remove unused execArg0/execEnv <Created by mvo5> <https://github.com/snapcore/snapd/pull/4524> | 16:26 |
| niemeyer | cachio: Introducing a priority setting feels much nicer | 16:26 |
| kyrofa | brunosfer, alright, the picture is getting clearer. Let me finish this meeting I'm in now and I'll help further | 16:26 |
| brunosfer | kyrofa: Awesome! Thank you. | 16:27 |
| cachio | niemeyer, I could implement that if you think it could be valuable | 16:27 |
| mvo | could someone one fedora paste me /lib/systemd/system/systemd-sysusers.service please? | 16:28 |
| mvo | (pastebin) | 16:28 |
| niemeyer | cachio: Thanks, I'm pretty sure it will be valueable.. let's see what the result of changing it looks like | 16:28 |
| cachio | niemeyer, ok, I'll work on that | 16:29 |
| niemeyer | cachio: Thanks! | 16:29 |
| cachio | niemeyer, what do you think that could be better something like [HIGH ,LOW] or a numeric system [1...10]? | 16:31 |
| niemeyer | cachio: Something like "priority: 42" seems nice | 16:31 |
| cachio | niemeyer, ok | 16:31 |
| niemeyer | cachio: Defaults to zero.. then we just need to sort the job list after the shuffle | 16:32 |
| niemeyer | cachio: Note that the sort must be stable | 16:32 |
| niemeyer | cachio: Otherwise the shuffle will be undone | 16:32 |
| cachio | niemeyer, ok, so, bigger is bigger priority, ritght? | 16:33 |
| niemeyer | cachio: Yes, I suspect that'll be easier to work with | 16:33 |
| cachio | niemeyer, yes, agree | 16:33 |
| niemeyer | cachio: As oppoesed to renice-like inverted priority | 16:33 |
| Chipaca | mvo: let me figure out how to pastebin it and sure | 16:34 |
| Chipaca | mvo: https://paste.ubuntu.com/26445110/ | 16:36 |
| Chipaca | mvo: that's from Fedora Cloud Base 24 | 16:36 |
| Chipaca | which may or may not be what you wanted | 16:36 |
| Chipaca | - but it's what i had - | 16:36 |
| mvo | Chipaca: thank you! | 16:40 |
| mvo | Chipaca: that is perfect | 16:40 |
| niemeyer | " Ran for 23 min 2 sec " | 16:44 |
| niemeyer | And that's before even isolating the tests.. let's see now | 16:45 |
| cachio | niemeyer, wow | 16:46 |
| niemeyer | Saviq: ping | 16:48 |
| Saviq | niemeyer: here | 16:49 |
| niemeyer | Saviq: Heya.. | 16:49 |
| niemeyer | Saviq: Dynamic allocations are a thing now.. can you please update your repository's spread.yaml with this snippet under the backend: | 16:50 |
| niemeyer | plan: 8GB | 16:50 |
| niemeyer | location: fremont | 16:50 |
| Saviq | w00t | 16:50 |
| niemeyer | Saviq: If you've run anything recently, it was already dynamically allocated.. but that's because I've put a hack in our spread binary tarball.. I need to remove the hack, and for your runs to not break that snippet needs to be in place | 16:51 |
| niemeyer | That goes inside the linode backend stanza, next to the key | 16:51 |
| Saviq | niemeyer: we're using the snapped spread, FWIW | 16:51 |
| Saviq | should we switch to your build already? | 16:51 |
| kalikiana | kyrofa: sergiusens: elopio FYI shared the minutes with you. please double-check your junk mail etc. if you don't seem to be getting them | 16:51 |
| niemeyer | Saviq: Ah, okay, so you won't see it.. | 16:52 |
| kyrofa | kalikiana, I always get them! | 16:52 |
| niemeyer | Saviq: I haven't touched your other PRs yet, so probably not | 16:52 |
| kalikiana | kyrofa: Leo told me that's where they went. I don't know if that was just Google being "smart", I just want to be sure you get the minutes :-D | 16:52 |
| * zyga-ubuntu -> loooong walk | 16:52 | |
| niemeyer | Saviq: Or are you using the stock spread snap? | 16:52 |
| Saviq | niemeyer: stock snap | 16:53 |
| elopio | thanks kalikiana. Not on the spam this time :) | 16:53 |
| Saviq | let me confirm | 16:53 |
| kalikiana | kyrofa: I use my best hand-writing there, so I hope they will be read ;-) | 16:53 |
| niemeyer | Saviq: Okay, great.. so please just update the spread.yaml file with these fields, and it will all take care of itself in due time | 16:53 |
| kalikiana | elopio: Awesome! Thanks for confirming | 16:53 |
| codeplug | Hi, how can I set a snap to automatically start when booting up? | 16:57 |
| kyrofa | codeplug, make the app in the snap a service | 16:59 |
| kyrofa | You can do that by adding `daemon: simple` to the app definition (alongside `command`) | 16:59 |
| codeplug | will try. Thanks! | 16:59 |
| kyrofa | codeplug, note that this is a system service-- it runs as root | 17:00 |
| * Chipaca EODs | 17:00 | |
| kyrofa | sergiusens, you joining the summit prep? | 17:04 |
| sergiusens | kyrofa yeah, sorry | 17:04 |
| brunosfer | kyrofa: Sorry to bother you with this issue, but I'm really stuck here. =S | 17:06 |
| kyrofa | brunosfer, no problem, I haven't forgotten! Just a few more minutes | 17:06 |
| brunosfer | kyrofa: Ok! Thanks ;) | 17:06 |
| diddledan | EOD: Emergence of Destruction? | 17:14 |
| diddledan | :-p | 17:14 |
| lundmar | Hmm, how does snapcraft actually stage stuff? I'm having some trouble trying to make Qt detect a QT "charts" module which is built and installed using the qmake plugin. The "charts" module is not available in Ubuntu Xenial. It seems the charts module (libs, headers) etc. ends up in staging but this is different from the normal system location so it is not found by Qt. | 17:17 |
| lundmar | I thought snapcraft made staging appear as the system root. | 17:19 |
| lundmar | */assumed | 17:19 |
| nacc | lundmar: have you ordered your yaml correctly? | 17:21 |
| nacc | lundmar: which Qt do you mean, stage is a build-time thing, as well | 17:21 |
| diddledan | lundmar: snapcraft doesn't make the stage dir into a fake root | 17:22 |
| lundmar | nacc: I'm trying to do this after I've found out Xenial does not have qtcharts5: https://github.com/lxi-tools/lxi-tools.snapcraft/commit/3ef4d1ba179d2c1a5cbac450d06f604ded24bbf4 | 17:22 |
| lundmar | diddledan: ok, so it's all LDCONFIG and enviroment variables directed. | 17:23 |
| diddledan | yup | 17:23 |
| nacc | lundmar: you should be able to `snapcraft stage qtcharts` (iirc) and see what it put in stage/ | 17:23 |
| diddledan | the chances are you're installing to $SNAPCRAFT_STAGE/usr/local which I don't think is included in the default overridden search paths for headers and libraries for other parts | 17:24 |
| nacc | yeah' | 17:24 |
| lundmar | thats kind of the problem, I can't find a way to tell Qt to look for the additional charts module installed in staging. | 17:24 |
| diddledan | try adding a prefix of "/usr" which will be redirected into `$SNAPCRAFT_STAGE/usr` | 17:24 |
| nacc | if they are in usr/local, then you need to tell Qt that, otherwise what diddledan is saying | 17:24 |
| lundmar | nacc: during build it seems to stage qtcharts successfully. | 17:25 |
| lundmar | I'll try change the prefix | 17:26 |
| lundmar | assuming the qmake plugin supports it haha | 17:26 |
| diddledan | I'm not familiar with qmake but cmake and autotools both provide the ability to set prefix= | 17:26 |
| lundmar | :) | 17:26 |
| diddledan | so I'd be surprised if qmake was different | 17:26 |
| lundmar | I'll find out | 17:26 |
| nacc | https://docs.snapcraft.io/reference/plugins/qmake | 17:26 |
| nacc | i'm guessing it's a qmake option? | 17:27 |
| lundmar | thats a short doc he he | 17:27 |
| diddledan | ok, so if you find out the qmake command line flag then set `options: [--your-qmake-prefix-flag=/usr]` | 17:27 |
| lundmar | qmake PREFIX=... | 17:30 |
| diddledan | ok so `options: [PREFIX=/usr]` should work | 17:31 |
| lundmar | I've started a build using that | 17:31 |
| lundmar | btw, is there any way to avoid downloaing stuff repeatedly when using e.g. cleanbuild --debug ? | 17:33 |
| lundmar | I mean, it's a lot of download for each debug iteration | 17:33 |
| lundmar | would be nice if it could be cached | 17:34 |
| ogra_ | mvo, once the core is in stable, will you make sure we get a proper edge build with master again ... i'm itching to test the multi-volume fix (and the customer too) | 17:35 |
| kyrofa | niemeyer, what's the status of some way for a snap to say "I'm in use, don't update!" ? | 17:36 |
| niemeyer | kyrofa: Planned, wanted :) | 17:37 |
| kyrofa | Prioritized? | 17:37 |
| niemeyer | kyrofa: Not in the schedule just yet.. | 17:38 |
| kyrofa | Alright, thank you | 17:38 |
| niemeyer | kyrofa: That and manual postponing may be nice things for after the current promised features | 17:38 |
| nacc | lundmar: yeah, i wish too | 17:38 |
| nacc | lundmar: the probably is, it doesn't keep the lxd around, of course | 17:38 |
| nacc | lundmar: so you need to cache it in the lxd host (e.g., apt-cacher-ng or so) | 17:38 |
| ogra_ | nacc, snap install packageproxy ... and make sure your sources.lists point to localhost:9999 ;) | 17:41 |
| lundmar | nacc: one thing is for sure, the more popular snap gets, the more some sort of cache mechanism is wished for. Also, to offload the hard pressed Ubuntu build servers. | 17:41 |
| nacc | ogra_: yeah that works too | 17:42 |
| nacc | ogra_: the issue being if you ahve multiple envs, maintaining all of them starts to be a pain | 17:42 |
| nacc | lundmar: --^ for the above, lxd profiles are nnice | 17:43 |
| ogra_ | indeed | 17:43 |
| kyrofa | brunosfer, I'm out of my meeting! | 17:43 |
| nacc | but afaik, snapcraft can't use them yet | 17:43 |
| diddledan | use `SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft` instead of `snapcraft cleanbuild` | 17:43 |
| kyrofa | brunosfer, you still around? | 17:43 |
| nacc | diddledan: ah does that just call lxc directly? | 17:43 |
| diddledan | then it will keep the lxc container between runs | 17:43 |
| nacc | diddledan: ah | 17:43 |
| brunosfer | kyrofa: Yep! Still stuck... | 17:43 |
| kyrofa | brunosfer, very good. It's been a while since I've written some go, so let me test something out real quick | 17:44 |
| brunosfer | kyrofa: Ok! Thanks ;) | 17:44 |
| lundmar | diddledan: oh, thanks. I'll try that. | 17:44 |
| diddledan | best to still check with a proper cleanbuild once you've got it running though in case you installed a `build-package` which you rely on and then removed it from the yaml because it'll still be in the container but a cleanbuild won't have it available | 17:44 |
| lundmar | diddledan: using the PREFIX still fails. It gets installed in /root/build_lxi-tools/stage/usr/lib/x86_64-linux-gnu which looks right. | 17:44 |
| diddledan | yup that looks right | 17:45 |
| lundmar | I think the main problem is that qmake does not seem to support looking for "external" Qt modules installed outside of its normal Qt module installation dir (/usr/lib/x86_64-linux-gnu). | 17:46 |
| lundmar | so for staging the way snapcraft foes this becomes an issue of course | 17:47 |
| lundmar | does* | 17:47 |
| nacc | lundmar: even with a flag? | 17:47 |
| lundmar | nacc: I've haven't been able to find that flag. | 17:48 |
| lundmar | wouldn't it be possible to overlay the staging root with the systems root and solve avoid this type of problem? | 17:49 |
| ogra_ | make sure you capture it once you found it ;) | 17:49 |
| nacc | lundmar: then you would be using the system ... which would not be a confinned snap? | 17:50 |
| lundmar | no no, I mean, during snap creation. | 17:50 |
| diddledan | lundmar: does `QMAKE_LIBDIR` work? | 17:51 |
| lundmar | during runtime it should of course not use system but still be confined. | 17:51 |
| lundmar | diddledan: I've tried QMAKE_LIBDIR and QMAKE_INCDIR in the .pro file. | 17:52 |
| nacc | lundmar: but presumably it nneeds those built things to be in the snap? | 17:52 |
| lundmar | nacc: yes, the ones that are staged. | 17:53 |
| kyrofa | brunosfer, alright, which part in the YAML is the "main" one? Are all the other go parts dependencies? | 17:53 |
| nacc | lundmar: right, so you wouldn't want ot use the system if it had them :) | 17:53 |
| lundmar | nacc: in this case it stages qtchart and the remaining qt5 stuff comes from the core image. | 17:53 |
| kyrofa | brunosfer, the problem is that you're specifying a source that doesn't include the dependencies required | 17:54 |
| lundmar | diddledan: let me try the QMAKE_LIBDIR again | 17:54 |
| brunosfer | kyrofa: the main part is "hype" | 17:55 |
| diddledan | you might need to set it to QMAKE_LIBDIR="$QMAKE_LIBDIR:$SNAPCRAFT_STAGE/usr/lib" or some such | 17:55 |
| brunosfer | kyrofa: how do you include the source from the required dependencies? | 17:55 |
| diddledan | again IANAL so I probably got the syntax wrong | 17:56 |
| lundmar | diddledan: yeah, to avoid overriding it. got it. | 17:57 |
| diddledan | bingo | 17:58 |
| kyrofa | brunosfer, well, you've got your project organized a bit unconventially, and go is all about convention. How do you have this setup when you're not building a snap? | 17:58 |
| diddledan | I expect snapcraft is setting it already, so you need to _add_ your path | 17:58 |
| kyrofa | brunosfer, local imports, like you're going here, can bite you | 17:58 |
| kyrofa | Relative imports | 17:59 |
| brunosfer | kyrofa: but how can I set an absolute path for packages that I built in go? | 18:00 |
| kyrofa | brunosfer, here, this should help: https://stackoverflow.com/a/10688069/925486 | 18:00 |
| brunosfer | kyrofa: BTW The application is running in golang with no problems. | 18:00 |
| kyrofa | brunosfer, that's what I'm asking-- how do you have your workspace setup, and how are you building the application? | 18:01 |
| brunosfer | kyrofa: Inside the snapcraft staging dir I have a folder called "src" and inside this folder I have several folders that I refer in the yaml file as parts. Inside each of those folders I have a golang package. | 18:03 |
| brunosfer | kyrofa: My problem is how can I make a yaml file config where I have a golang package in a different folder from the main package. | 18:04 |
| kyrofa | brunosfer, I'm asking how you do this _outside_ of snaps | 18:04 |
| kyrofa | brunosfer, ignoring snaps, what does your go workspace look like? | 18:04 |
| brunosfer | kyrofa: I do: go run main.go | 18:05 |
| brunosfer | kyrofa: GOPATH="/home/user" | 18:05 |
| kyrofa | brunosfer, and where is main.go relative to the GOPATH? | 18:06 |
| brunosfer | kyrofa: GOROOT="/usr/lib/go-1.8" | 18:06 |
| brunosfer | kyrofa: The main.go is in src/client/ and the bridge is in src/bridge relative to the GOPATH | 18:07 |
| kyrofa | brunosfer, so you have /home/usr/src/client and /home/usr/src/bridge ? | 18:07 |
| brunosfer | kyrofa: Yes. | 18:08 |
| kyrofa | brunosfer, what happens if you run `go install client` ? | 18:09 |
| brunosfer | kyrofa: It installs the client package in /usr/local/pkg | 18:10 |
| kyrofa | Not bin? | 18:10 |
| brunosfer | kyrofa: But is this needed with the snapcraft tool? I though it would only be needed in go. | 18:11 |
| brunosfer | kyrofa: Sorry /usr/bin/pkg | 18:11 |
| brunosfer | kyrofa: Sorry for the bad information regarding the `go install client` process. It's giving me error on the GOROOTPATH | 18:15 |
| kyrofa | brunosfer, okay, so it doesn't work. What is the error? | 18:15 |
| brunosfer | kyrofa: cannot find the package bridge. I guess it's some problem related with the GOROOT path, however I cannot change it. | 18:17 |
| kyrofa | brunosfer, no, it's the problem I just told you was a problem :) | 18:18 |
| kyrofa | Please read that stackoverflow post | 18:18 |
| kyrofa | If you manage to get it working with `go install`, it'll work in snapcraft | 18:18 |
| brunosfer | kyrofa: Sorry I didn't understood... | 18:19 |
| mvo | ogra_: is edge behind? in theory we should have edge builds (modulo bugs of course) | 18:20 |
| ogra_ | mvo, 2.30 ... | 18:20 |
| mvo | ogra_: uh, let me check why | 18:20 |
| kyrofa | kalikiana, dude, just saw the on..to push | 18:21 |
| ogra_ | (at least on armhf) | 18:21 |
| kyrofa | kalikiana, tell me that's not a simple implementation | 18:21 |
| kyrofa | Beautiful work | 18:22 |
| kyrofa | And easy to make more generic, I think | 18:22 |
| mvo | ogra_: yeah, looks like the builds are behind: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 18:23 |
| mvo | ogra_: it says build starts in ~30min so fingers crossed, thanks for notifying me | 18:23 |
| ogra_ | yeah :/ | 18:23 |
| ogra_ | i wonder when we're back to normal ... | 18:23 |
| kalikiana | kyrofa: I feel I must've missed something. It looks too simple. Tests passed, though :-D | 18:23 |
| kyrofa | I know! | 18:23 |
| * kyrofa waits with baited breath on Travis | 18:24 | |
| kyrofa | Err. Bated | 18:24 |
| ogra_ | yeah, baited might be a bit fishy ... | 18:24 |
| kyrofa | ogra_, exactly what I thought as I pressed enter :P | 18:25 |
| ogra_ | heh | 18:25 |
| kalikiana | My thought was you might have bbq breath or something, and dogs looking at you | 18:26 |
| kyrofa | Mmm, bbq | 18:26 |
| kalikiana | Exactly | 18:26 |
| kalikiana | Might be the fact I'm due for dinner | 18:26 |
| brunosfer | kyrofa: The main package (client) can only be compiled and sent to the `/usr/bin/` when the package `bridge` which is a dependency of the package `client` is recognized. The problem I still have is that the yaml config file cannot recognize the path of the bridge. | 18:27 |
| kyrofa | brunosfer, it has nothing to do with YAML. The problem is that you don't have a suitable workspace setup | 18:27 |
| brunosfer | kyrofa: Ok. I will look further on that. Thanks. | 18:28 |
| ogra_ | yeah, re-arragne that staplet there | 18:28 |
| ogra_ | *stapler | 18:28 |
| ogra_ | twist it 30° left ... that should work then :) | 18:28 |
| kyrofa | Hmm... now I can't remember if I've shown my wife that movie | 18:28 |
| kyrofa | brunosfer, that stackoverflow answer has a link to the go conventions, try to follow them and your life will become less filled with pain | 18:29 |
| brunosfer | kyrofa: Ahahahah Thanks for the medication ;) | 18:31 |
| kyrofa | :D | 18:32 |
| mup | PR snapd#4525 opened: tests: new spread test for interface gpg-keys <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4525> | 18:53 |
| kyrofa | elopio, have you tried autopkgtests lately? It sounds like restrictions on other platforms may be over | 19:31 |
| elopio | kyrofa: like, no 500 anymore? | 19:33 |
| kyrofa | elopio, yeah, it might be back up now | 19:33 |
| nacc | request.cgi is still disabled | 19:34 |
| nacc | afaik | 19:34 |
| nacc | (just asking Laney about it) | 19:34 |
| jdstrand | zyga-ubuntu: hey, been going through the layouts PRs. I notied that prt 4505 is already committed, but please see https://github.com/snapcore/snapd/pull/4505/files#r163352592 | 19:34 |
| mup | PR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4505> | 19:34 |
| nacc | the build farm is on, on all archs, that's all I can say | 19:34 |
| elopio | kyrofa: nop, 500 again | 19:34 |
| kyrofa | nacc, in -devel? | 19:46 |
| nacc | kyrofa: sorry, which, in -devel? you | 19:47 |
| nacc | s/you// | 19:47 |
| kyrofa | nacc, sorry, were you asking Laney in #ubuntu-devel? But now I realize the conversation is probably over, haha | 19:48 |
| nacc | kyrofa: yeah, i pinged Laney there | 19:49 |
| kyrofa | nacc, no response yet, though? | 19:51 |
| nacc | kyrofa: yeah, nothing yet, afaict, it's still disabled (that's seaprate from the build farm) | 19:51 |
| kyrofa | Alright, I'll idle there and see what comes up | 19:51 |
| kyrofa | nacc, thanks for letting us know :) | 19:51 |
| nacc | kyrofa: np | 19:52 |
| niemeyer | cachio: Fiddling with the images is proving very frustrating.. more so than just implementing priorities. Do you have that ready yet? | 20:19 |
| mup | PR snapd#4526 opened: tests: new spread test for gpg-public-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4526> | 20:19 |
| cachio | niemeyer, no yet, I was finishing the new tests for gpg | 20:20 |
| niemeyer | cachio: Ok, let me dig into that then | 20:20 |
| cachio | niemeyer, sure | 20:20 |
| niemeyer | cachio: The problem with the images is that we have too many assumptions on the name of the image | 20:20 |
| niemeyer | cachio: So creating a new system that works just for one specific test ends up being troublesome | 20:20 |
| cachio | niemeyer, agree | 20:21 |
| niemeyer | I'm hoping to get done with these Spread fixes today still | 20:21 |
| niemeyer | Well, improvements really.. nothing is broken | 20:21 |
| cachio | niemeyer, ok, the next step to reduce test time should be automatically update the images | 20:22 |
| cachio | with the dependencies | 20:22 |
| cachio | periodically | 20:22 |
| cachio | I have that task in the todo list since long time | 20:22 |
| sergiusens | kyrofa mind taking an initial view on snapcraft#1881 ? wording and what not | 21:48 |
| mup | PR snapcraft#1881: elf: better handling for newer libc6 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1881> | 21:48 |
| kyrofa | sergiusens, sure thing | 21:48 |
| mup | PR snapcraft#1881 opened: elf: better handling for newer libc6 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1881> | 21:48 |
| zyga-ubuntu | re | 21:51 |
| kyrofa | sergiusens, you may be interested in bug #1745040 | 22:09 |
| mup | Bug #1745040: help command replaces the name of commands with itself <Snapcraft:New> <https://launchpad.net/bugs/1745040> | 22:09 |
| mup | PR snapd#4527 opened: Fix comment about running gofmt on contributions <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4527> | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!