mborzeckimvo: morning06:48
mborzeckimvo: 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 created06:52
mupBug #1738197: Daemons do not have an /run/user/* dir created <Snappy:New> <https://launchpad.net/bugs/1738197>06:52
mborzeckithe 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 anything06:53
mvohey mborzecki good morning06:59
mvomborzecki: I don't remember the backstory :( and the commit description does not help much. I think zyga will remember07:00
mborzeckimvo: i also found this PR https://github.com/snapcore/snap-confine/pull/19507:01
mupPR 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
mborzeckiopened and closed by zyga,  i suppose there were some security concerns raised by jdstrand07:01
mborzeckimvo: switched to bug report to confirmed for now07:03
mupPR snapd#4519 opened: arch: add "armv8l" to ubuntuArchFromKernelArch table <Created by mvo5> <https://github.com/snapcore/snapd/pull/4519>07:24
mupBug #1738222 changed: FAIL: main_test.go:769: snapSeccompSuite.TestCompatArchWorks <Snappy:Fix Released by maciek-borzecki> <https://launchpad.net/bugs/1738222>07:31
mupBug #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
kalikianamoin moin08:00
mborzeckizyga-ubuntu: kalikiana: morning08:01
zyga-ubuntuwhat is armv8l?08:01
zyga-ubuntucan anyone please do 2nd review for https://github.com/snapcore/snapd/pull/396308:04
mupPR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>08:04
zyga-ubuntupstolowski, 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 top08:07
mupPR snapd#4519 closed: arch: add "armv8l" to ubuntuArchFromKernelArch table <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4519>08:08
kalikianao/ mborzecki pstolowski zyga-ubuntu08:13
pstolowskizyga-ubuntu, looking08:15
mupPR snapd#4520 opened: daemon: unlock state even if RefreshSchedule() fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4520>08:15
zyga-ubuntumvo: you didn't add the mount unit08:16
mvozyga-ubuntu: meh, sorry and thanks08:20
mvozyga-ubuntu: are the spread tests under cmd/snap-confine still run?08:20
mvozyga-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 bases08:21
mborzecki4520 ^^ trivial review08:22
mupPR 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-ubuntumvo: no, only those in tests/ are used08:40
zyga-ubuntumvo: there are probably a few stale tests under snap-confine08:40
mvozyga-ubuntu: do you mind if I remove at least the one dealing with snappy-app-dev?08:40
zyga-ubuntumvo: do they hurt? I think those should be (eventually) ported and re-enabled08:41
zyga-ubuntumvo: is that test actually running now?08:42
zyga-ubuntumvo: and relevant to the discussion is https://github.com/snapcore/snapd/pull/439908:42
mupPR #4399: rewrite snappy-app-dev <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4399>08:42
pstolowskizyga-ubuntu, reviewed, some tiny remarks08:43
zyga-ubuntupstolowski: thank you! looking08:44
Chipacazyga-ubuntu: that traceback and error, is that fedora in our tests, or in the wild?08:47
zyga-ubuntuChipaca: I think that was in the tests that cachio ran08:47
Chipacathe net.Error case is new, but the tricky code existed before08:47
ChipacaI'll push something08:48
zyga-ubuntuwhen you hack on go08:50
zyga-ubuntudo you keep a symlink in ~ to the $GOPATH/src/yadayadayada directory?08:50
zyga-ubuntuI ask because I do and I hate how go fmt is stupid and doesn't cope with that08:50
Chipacazyga-ubuntu: I don't understand what you symlink09:08
Chipacazyga-ubuntu: in any case, no i don't keep a symlink in ~ to that :-)09:09
zyga-ubuntuChipaca: ~/snapd -> ~/go/src/github.com/snapcore/snapd09:10
zyga-ubuntupstolowski: updated09:10
pstolowskizyga-ubuntu, k, looking09:10
Chipacazyga-ubuntu: I just ^R cd ~ and it completes that :-)09:11
Chipacazyga-ubuntu: but it helps that I just have two go workspaces i work in with any frequency, snapd and my personal one09:12
Chipacaif i had more i'd need to get inventive09:12
pstolowskizyga-ubuntu, thanks for the helpers! looks very nice!09:13
zyga-ubuntupstolowski: thank you for the idea, I will use them in the rest of the code next09:19
zyga-ubuntuChipaca: I see, thanks09:19
Chipacadid we have a checker for "it's one of these two"?09:20
zyga-ubuntuChipaca: so, I feel like I could benefit from your walker and container validation thing09:20
zyga-ubuntuChipaca: I could use it to validate that the layout makes sense09:21
zyga-ubuntuChipaca: you could abuse "contains" checker in reverse, I presume09:21
zyga-ubuntuofftopic: my new favourite theme: agola green09:22
Chipacazyga-ubuntu: ebola green?09:22
Chipacazyga-ubuntu: i'll push this pr and then fix my container thing09:23
zyga-ubuntuChipaca: thanks, it's not urgent, just something I realized09:26
Chipacaaaand i've just done the old "committed to my master and pushed" idiocy09:28
zyga-ubuntuChipaca: classic, I do that all the time09:28
* Chipaca now needs to go to github, flip a flag, push force, flip it back09:28
zyga-ubuntupstolowski: can you look at https://github.com/snapcore/snapd/pull/4502 please, it's related09:28
mupPR #4502: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502>09:28
zyga-ubuntupstolowski: probably will do a round of similar changes there09:28
mupPR 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-ubuntumvo: https://github.com/snapcore/snapd/pull/4516 is green now but I'm not sure if we want to merge it yet09:30
mupPR #4516: spread: setup machine creation on Linode <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4516>09:30
pstolowskizyga-ubuntu, sure09:30
mupPR 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
Chipacazyga-ubuntu: ^ should address the issue09:31
zyga-ubuntuChipaca: +109:33
zyga-ubuntumvo: commented on 451709:37
mvozyga-ubuntu: thanks, I am not hopefully for any of these approaches09:44
zyga-ubuntumvo: what do you think will happen?09:44
mvozyga-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 busy09:44
zyga-ubuntumvo: yuck, that's indeed bad09:45
zyga-ubuntumvo: so09:45
mvozyga-ubuntu: so something more fundamental would be good except that we can't ship it in other distros :/09:45
zyga-ubuntumvo: maybe time to share one (very weird and crazy) idea09:45
mvozyga-ubuntu: more targeted may mean to just run this bind,share if condition=virtual is meet09:45
mvozyga-ubuntu: sure, share!09:45
zyga-ubuntumvo: you can do this:09:45
zyga-ubuntumvo: mkdir foo09:45
zyga-ubuntumvo: in one terminal unshare, mount --bind foo foo09:46
zyga-ubuntumvo: in another terminal, afterwards, rmdir foo09:46
zyga-ubuntumvo: this works09:46
zyga-ubuntumvo: now, this lets us make a namespace where a bind mount is present and where we can do whatever we want09:46
zyga-ubuntumvo: here's a crazy idea09:46
zyga-ubuntumvo: what if we did all the rsharing in a mount namespace snap-confine implicitly joins as soon as it starts09:46
mvozyga-ubuntu: hm, if that works, +109:47
zyga-ubuntumvo: that ns could be a slave of the real thing09:47
zyga-ubuntumvo: and it could do all the magic needed that wouldn't leak outside09:47
zyga-ubuntumvo: so apt and friends can remove things as they usually do09:47
zyga-ubuntumvo: not sure, just thought about it, I can give it a try09:47
mvozyga-ubuntu: please, I will poke around a bit more but I doubt the current mount unit approach is feasible09:48
zyga-ubuntumvo: I wonder if this can be fixed in containers09:51
zyga-ubuntumvo: maybe lxd can just do the right thing09:51
=== chihchun_afk is now known as chihchun
zyga-ubuntuFailed 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-ubuntuis it snap.mount or snap.mount.service?09:57
zyga-ubuntulooks like a simple error there mvo09:57
mupPR 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
mvozyga-ubuntu: indeed, let me fix, it should be snap.mount only10:07
zyga-ubuntuChipaca: hey11:00
zyga-ubuntuyour change broke one very unexpected place11:00
zyga-ubuntu+ echo 'error: cannot install ["test-snapd-classic-confinement"]: classic confinement11:00
zyga-ubuntu       requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap'11:00
zyga-ubuntuerror: pattern not found, got:11:00
zyga-ubuntusee ["foo"] vs "foo"11:00
zyga-ubuntuerror: cannot install ["test-snapd-classic-confinement"]: classic confinement requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap11:00
Chipacazyga-ubuntu: hah. Not _that_ unexpected11:00
Chipacazyga-ubuntu: in fact i was wondering if that'd come up11:00
Chipacazyga-ubuntu: I can fix :-)11:00
Chipacathanks for the heads-up11:00
zyga-ubuntumvo: snap.mount doesn't work :/11:01
zyga-ubuntuRemoving snapd (1337.2.30) ...11:01
zyga-ubuntuJob for snap.mount failed. See "systemctl status snap.mount" and "journalctl -xe" for details.11:01
zyga-ubuntudpkg: error processing package snapd (--purge):11:01
mvozyga-ubuntu: yeah, I was afraid this would happen11:05
mvozyga-ubuntu: snap.mount cannot be stopped as the mount point is busy. but we cannot make it not-busy unless we purge11:05
zyga-ubuntuhmm hmm hmm11:06
zyga-ubuntubut why is it busy11:06
zyga-ubuntuit is busy because it is a mount point?11:06
zyga-ubuntumaybe what we need is a bind mount from /var/lib/snapd/snap to /snap11:06
zyga-ubuntumaybe it's a systemd bug11:06
zyga-ubuntuI would presume systemd would stop all the snap mount units inside first11:06
zyga-ubuntuthen stop snap.mount11:06
mvoniemeyer: 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/365311:07
mvozyga-ubuntu: I think it is because /snap/* is still available on remove, we only get rid of the actual snaps on purge11:08
zyga-ubuntumvo: hmmm,11:08
zyga-ubuntumvo: but if dpkg starts this, dpkg first should run prerm script11:08
zyga-ubuntumvo: do we stop services and unmount snaps in prerm?11:09
zyga-ubuntuiff we do, it could just work11:09
mborzeckizyga-ubuntu: can you try to use snap-mgmt in prerm?11:10
zyga-ubuntumborzecki: I think we should unify script management but it's hard due to way dpkg handles files11:11
zyga-ubuntumborzecki: it'd be easier if our build system split snap-mgmt and injected it into actual dpkg management scripts11:11
mvozyga-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 purge11:11
zyga-ubuntumborzecki: as those have differnet lifecycle from the other package files11:11
zyga-ubuntumvo: actually...11:12
zyga-ubuntumvo: we only have to unmount /snap on purge too11:12
zyga-ubuntumvo: can we make dpkg ingore /snap?11:12
zyga-ubuntumvo: if we don't ship it11:12
zyga-ubuntumvo: just create it in a script:?11:12
mvozyga-ubuntu: yeah, we would have to create it in postinst and manage it manually11:12
mvozyga-ubuntu: ugly as **** but worth a try11:13
Chipacazyga-ubuntu: tweaked #4522 a little, should address that failure you saw (and be a little nicer)11:15
mupPR #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-ubuntuChipaca: nice, looking11:15
Chipacawhen it's just one snap, error message should now be identical to what it was before11:16
Chipacawhen it's something else, it'll be something else :-) but nicer11:16
Chipacaalso less duplication, in exchange for some shenaniganry11:17
Chipaca(take *that*, branch predictor!)11:19
* Chipaca fixes the fix11:33
mupPR 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
Chipacais raspbian always armel?12:05
ackkkalikiana, hi, do you think https://github.com/snapcore/snapcraft/pull/1617 can be merged now?12:07
mupPR snapcraft#1617: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617>12:07
zyga-ubuntucachio: observation: go test ./... is far far far faster than our run checks --unit12:13
zyga-ubuntuactually, can you guys please: time go test ./...12:14
zyga-ubuntufrom the top of the tree12:14
cachiozyga-ubuntu, I'll try it12:15
zyga-ubuntupstolowski: Attr() cannot be used to check if an attribute of _any_ type exists12:19
zyga-ubuntupassing interface{} won't cut it12:19
zyga-ubuntupstolowski: I'd like to add HasAttr()12:19
pstolowskizyga-ubuntu, I know. I've addressed this in #451012:20
mupPR #4510: asserts: use Attrer in policy checks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510>12:20
zyga-ubuntuah, nice12:20
zyga-ubuntuhmm hmm12:20
zyga-ubuntuok, I'll add a todo and wait12:21
pstolowskizyga-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 guess12:21
kalikianaackk: I'd suggest to check with kyrofa  - I don't have merge powers :-D12:21
pstolowskizyga-ubuntu, 4510 needs Samuele's review.. not sure if you can wait till he is back?12:22
mupPR 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-ubuntupstolowski: I think this is fine, I added a TODO note to use Lookup12:23
Chipacazyga-ubuntu: snap.ValidateContainer on master12:23
zyga-ubuntuChipaca: I saw, thank you!12:23
pstolowskizyga-ubuntu, k12:23
zyga-ubuntuChipaca: so with that, I will probably look at making it useful for validating layout12:24
zyga-ubuntuhttps://github.com/snapcore/snapd/pull/4329 needs a 2nd review12:24
mupPR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>12:24
mupPR snapd#4523 opened: interfaces/builtin: allow introspecting UDisks2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4523>12:33
zyga-ubuntumborzecki: about 452312:38
zyga-ubuntumborzecki: does the new xml snippet mean anyone can introspect udisks?12:38
zyga-ubuntuI think the plug apparmor part must define something like that too12:39
zyga-ubuntuah, it already does that12:39
mborzeckizyga-ubuntu: yeah, it was missing from the slot12:39
mborzeckizyga-ubuntu: once i got that, the dbus rule was disallowing calls to Introspectable :/12:40
mborzeckidbus snakepit12:40
zyga-ubuntuChipaca: so, for containers, did you come up with a practical way to mock them?12:54
Chipacazyga-ubuntu: simplest way is to use a snapdir12:54
Chipacazyga-ubuntu: look at the tests of validate container in snap/container_test.go12:55
zyga-ubuntuyeah, I just need to tweak my code to accept a container12:55
zyga-ubuntuand not attempt to derive one from snap info12:55
zyga-ubuntuthat will be much nicer for testing12:55
mupPR 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 lunchj13:44
* kalikiana going for lunch (and yay, a little bit of sun)13:51
Chipacaniemeyer: https://forum.snapcraft.io/t/snapshots-implementation-details/365613:53
Chipacaniemeyer: i think that touches on the bits that were making you nervous, or for which you were lacking context13:54
Chipacagetting it working so you can play with it is what i'm working towards, eta tomorrow13:55
Chipacanotably the switch to zip at the toplevel was painless :-)13:55
niemeyerChipaca: 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 cringe13:56
Chipacaniemeyer: I know you'll persevere and do it anyways :-)13:57
Chipacaniemeyer: (i'm joking; bring on the suggestions)13:57
niemeyerChipaca: I'll try to see that as a compliment :D13:57
Chipacaniemeyer: are those suggestions going to be on the forum?14:02
niemeyerChipaca: 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 case14:03
niemeyercachio: That unit test takes about 10 minutes alone14:08
niemeyercachio: This is definitely making a significant impact on the overall test, because it's mixed in with all the other tests14:09
niemeyerImagine what happens if systems are all happy churning, and then at the 20 minutes mark they start running unit tests, for example14:10
niemeyerThat's probably one of the reasons why we fail to improve the overall test performance.. I'll have a look into this today14:11
niemeyerIn any case, " Ran for 25 min 49 sec"14:11
* pstolowski lunch14:12
cachioniemeyer, ok, I'm researching that as well14:17
cachioniemeyer, thanks for the heads-up14:17
* cachio afk 14:25
* Chipaca afk for a bit14:40
greybackjdstrand: 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
greybackso the plug would call "snap get x11 socket" and get a path to the socket back14:53
zyga-ubuntugreyback: this is something that will be done via interface hooks14:54
zyga-ubuntugreyback: please look at this PR, the tests do something quite like this14:54
greybackzyga-ubuntu: interesting, looking...14:55
mupPR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>14:55
zyga-ubuntujdstrand: https://github.com/snapcore/snapd/pull/4523 needs your 2nd review (very short)14:56
mupPR #4523: interfaces/builtin: allow introspecting UDisks2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4523>14:56
mupPR 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
pstolowskigreyback, 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 finalized14:59
zyga-ubuntujdstrand: this PR https://github.com/snapcore/snapd/pull/4521 is related to your work15:01
mupPR #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
greybackpstolowski: yeah it sounds like it. Does it look far from landing?15:01
zyga-ubuntumvo: https://github.com/snapcore/snapd/pull/4512 is green and needs a 2nd review15:01
mupPR #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 4X15:02
jdstrandzyga-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
pstolowskigreyback, my guess is probably a few weeks as there is some followup stuff that needs to land before we can enable the feature15:04
greybackpstolowski: ack, thanks15:04
zyga-ubuntujdstrand: ack15:06
mupPR snapd#4523 closed: interfaces/builtin: allow introspecting UDisks2 <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4523>15:06
zyga-ubuntuniemeyer: can we land https://github.com/snapcore/snapd/pull/4516 or do you need to do more tweaking on it?15:07
mupPR #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
niemeyerzyga-ubuntu: Still working on it15:08
zyga-ubuntucachio: https://github.com/snapcore/snapd/pull/4511 is failing for real15:11
mupPR #4511: tests: new spread test for ssh-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4511>15:11
kyrofaackk, indeed, it seems that feature is contained in 2.30, which has made it to stable, in my mind it can be merged15:16
kyrofaI've updated it to bring it inline with master, the tests are running once more15:16
ackkkyrofa, cool, thanks15:16
kyrofaackk, see sergio's comment on the PR. Are you up for that?15:28
cachiozyga-ubuntu, yes15:28
cachioalso the issue that was seen in fedora should be considered, it failed to read ssh config file15:29
cachiozyga-ubuntu, now as we are not executing ssh to coonect any more the error is not being reproduced15:29
zyga-ubuntucachio: not sure about fedora, the only thing I recall was an error in daemon/api.go -15:31
zyga-ubuntucachio: there's ssh_config in the core snap so it should be there15:32
zyga-ubuntucachio: did you investigate why it failed?15:32
cachiozyga-ubuntu, running it now15:32
zyga-ubuntuthank you!15:32
brunosferHey 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-ubuntubrunosfer: that error looks like app specific thing15:38
mupPR snapcraft#1873 closed: elf: cleaner patchelf experience <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1873>15:38
brunosferzyga-ubuntu: I think the snapcraft is trying to compile the package. However that package is a dependency of the project.15:39
brunosferzyga-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-ubuntukyrofa: ^15:40
mupPR snapcraft#1865 closed: lxd: always (re-)injects snaps <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1865>15:41
kyrofabrunosfer, I'm afraid I don't quite understand the issue. Any chance you can share your YAML?15:41
brunosferkyrofa: How do you suggest to share?15:43
kyrofabrunosfer, pastebin.ubuntu.com works pretty well15:43
kyrofaUnless you already have it in e.g. github15:44
brunosferkyrofa: I'm gonna use pastebin, I don't have the project on github.15:44
kyrofabrunosfer, sure thing15:44
brunosferkyrofa: Please check https://pastebin.ubuntu.com/26444892/15:47
cachiozyga-ubuntu, https://paste.ubuntu.com/26444896/15:48
kyrofabrunosfer, the `bridge` part is being built because you specified it as a part. Is that the one that's failing?15:49
cachiozyga-ubuntu, so, the file does not exist as part of the /etc/ssh/15:50
brunosferkyrofa: yes it is15:51
brunosferkyrofa: yes it is15:51
brunosferkyrofa: how should I specify it?15:51
kyrofabrunosfer, you mention that it's a dependency. A dependency of what?15:52
zyga-ubuntucachio: hmm15:52
zyga-ubuntucachio: that's interesting15:52
zyga-ubuntucachio: maybe some kind of writable path magic? not sure15:52
brunosferkyrofa: The package `bridge` is imported by the main package.15:53
kyrofabrunosfer, you probably don't need to specify it as a part, then15:54
cachiozyga-ubuntu, yes, not sure why it is there15:54
cachiomvo, any idea?15:54
kyrofabrunosfer, just specify the main part15:54
zyga-ubuntucachio: probably because of this15:57
cachiozyga-ubuntu, ouch15:58
cachiozyga-ubuntu, ok, in that case I could either to check on the core snap or skip it for core16:00
cachiozyga-ubuntu, I dont understand why is not mounting just 3 files16:02
mvocachio: sorry, I miss context - you don't see a file or what is going on?16:02
cachiothe ssh-config file is on /snap/core/x1/etc/ssh/ssh_config16:03
cachioand we are checking the file in /etc/ssh16:03
cachioit is happening just on core systems16:03
cachiomvo, so, we are no sure if it is an issue or is it ok that the file is just part of the core snap16:04
mvocachio: the writable-path magic will not copy files there is /etc already exists16:04
mvocachio: do you have a branch where this fails?16:04
mvocachio: I'm still not sure I see the bigger picture16:04
cachiomvo, https://github.com/snapcore/snapd/pull/451116:04
mupPR #4511: tests: new spread test for ssh-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4511>16:05
mvocachio: 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_config16: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 system16:10
mvocachio: so it must be something related to our test setup16:10
cachiomvo, yes, probably16:10
mvocachio: could you please run it with -debug so that we can see the content?16:11
cachioon how we create the core image16:11
cachiomvo, I have a debug open16:11
cachiowhat you want to see16:11
mvocachio: 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 empty16:13
ogra_(in case you poke around in an unbooted image there)16:13
cachiomvo, https://paste.ubuntu.com/26445000/16:14
ogra_looks broken ...16:15
mvocachio: and ls -al /snap/core/current/etc/ssh please?16:15
mvocachio: ok, the issue is with prepare.sh16: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 the16:18
ogra_                 source  directory  on  the  writable  partition   not   exist16:18
ogra_                 initially: if this condition is satisfied, the directory will16:18
ogra_                 then be created and the data moved on  first  boot.  Although16:18
ogra_                 the  mountpoint  will be writable, note that subsequent boots16:18
ogra_                 will ignore any new files appearing or  disappearing  in  the16:18
ogra_                 original  read-only  rootfs  location  unless  you  perform a16:18
ogra_                 factory reset."16:18
mvocachio: 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 fix16:19
niemeyercachio: I can confirm the theory..16:19
mvocachio: please try https://paste.ubuntu.com/26445024/16:19
ogra_makin it synced might help here16:19
mvoogra_: yeah, that would also work16:19
niemeyercachio: Found logs showing the Go unit tests starting to run 21 minutes into the logs16:20
niemeyerWhich pushes the full run into 30+ minutes even if everything else has finished16:20
niemeyerI'm tuning it16:20
cachioniemeyer, 21 minutes?16:20
niemeyercachio: Yeah, after 21 minutes of everything else working, the long task kicked in16:20
cachioniemeyer, are you going the define something like order on spread?16:21
niemeyercachio: 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 reused16:23
cachiomvo, so, for ubuntu-core I should check inside the core snap, right?16:23
brunosferkyrofa: The error is exactly that! When I specify the main as a part. The snapcraft tool doesn't recognize the `bridge`.16:23
mvocachio: just check /etc/ssh/ssh_config and apply the patch I pastebined to your PR and things should work16:23
mvocachio: i.e. just apply my pastebin :)16:24
cachiook, running16:24
mvocachio: and re-run the test and it should be fine16:24
brunosferkyrofa: The error is: "package bridge: unrecognized import path "bridge" (import path does not begin with hostname)"16:24
kyrofabrunosfer, ah, so you get that error if you remove the bridge part?16:24
cachiomvo, I'll tell you the result16:25
cachioniemeyer, otherwise we could split the unit test to make smaller tasks16:25
brunosferkyrofa: 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
cachioniemeyer, that could help too16:26
niemeyercachio: Yes, but that'd be a bit boring to maintain over time16:26
mupPR snapd#4524 opened: cmd: remove unused execArg0/execEnv  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4524>16:26
niemeyercachio: Introducing a priority setting feels much nicer16:26
kyrofabrunosfer, alright, the picture is getting clearer. Let me finish this meeting I'm in now and I'll help further16:26
brunosferkyrofa: Awesome! Thank you.16:27
cachioniemeyer, I could implement that if you think it could be valuable16:27
mvocould someone one fedora paste me /lib/systemd/system/systemd-sysusers.service please?16:28
niemeyercachio: Thanks, I'm pretty sure it will be valueable.. let's see what the result of changing it looks like16:28
cachioniemeyer, ok, I'll work on that16:29
niemeyercachio: Thanks!16:29
cachioniemeyer, what do you think that could be better something like [HIGH ,LOW] or a numeric system [1...10]?16:31
niemeyercachio: Something like "priority: 42" seems nice16:31
cachioniemeyer, ok16:31
niemeyercachio: Defaults to zero.. then we just need to sort the job list after the shuffle16:32
niemeyercachio: Note that the sort must be stable16:32
niemeyercachio: Otherwise the shuffle will be undone16:32
cachioniemeyer, ok, so, bigger is bigger priority, ritght?16:33
niemeyercachio: Yes, I suspect that'll be easier to work with16:33
cachioniemeyer, yes, agree16:33
niemeyercachio: As oppoesed to renice-like inverted priority16:33
Chipacamvo: let me figure out how to pastebin it and sure16:34
Chipacamvo: https://paste.ubuntu.com/26445110/16:36
Chipacamvo: that's from Fedora Cloud Base 2416:36
Chipacawhich may or may not be what you wanted16:36
Chipaca- but it's what i had -16:36
mvoChipaca: thank you!16:40
mvoChipaca: that is perfect16:40
niemeyer" Ran for 23 min 2 sec "16:44
niemeyerAnd that's before even isolating the tests.. let's see now16:45
cachioniemeyer, wow16:46
niemeyerSaviq: ping16:48
Saviqniemeyer: here16:49
niemeyerSaviq: Heya..16:49
niemeyerSaviq: Dynamic allocations are a thing now.. can you please update your repository's spread.yaml with this snippet under the backend:16:50
niemeyerplan: 8GB16:50
niemeyerlocation: fremont16:50
niemeyerSaviq: 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 place16:51
niemeyerThat goes inside the linode backend stanza, next to the key16:51
Saviqniemeyer: we're using the snapped spread, FWIW16:51
Saviqshould we switch to your build already?16:51
kalikianakyrofa: sergiusens: elopio FYI shared the minutes with you. please double-check your junk mail etc. if you don't seem to be getting them16:51
niemeyerSaviq: Ah, okay, so you won't see it..16:52
kyrofakalikiana, I always get them!16:52
niemeyerSaviq: I haven't touched your other PRs yet, so probably not16:52
kalikianakyrofa: 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 :-D16:52
* zyga-ubuntu -> loooong walk16:52
niemeyerSaviq: Or are you using the stock spread snap?16:52
Saviqniemeyer: stock snap16:53
elopiothanks kalikiana. Not on the spam this time :)16:53
Saviqlet me confirm16:53
kalikianakyrofa: I use my best hand-writing there, so I hope they will be read ;-)16:53
niemeyerSaviq: Okay, great.. so please just update the spread.yaml file with these fields, and it will all take care of itself in due time16:53
kalikianaelopio: Awesome! Thanks for confirming16:53
codeplugHi, how can I set a snap to automatically start when booting up?16:57
kyrofacodeplug, make the app in the snap a service16:59
kyrofaYou can do that by adding `daemon: simple` to the app definition (alongside `command`)16:59
codeplugwill try. Thanks!16:59
kyrofacodeplug, note that this is a system service-- it runs as root17:00
* Chipaca EODs17:00
kyrofasergiusens, you joining the summit prep?17:04
sergiusenskyrofa yeah, sorry17:04
brunosferkyrofa: Sorry to bother you with this issue, but I'm really stuck here. =S17:06
kyrofabrunosfer, no problem, I haven't forgotten! Just a few more minutes17:06
brunosferkyrofa: Ok! Thanks ;)17:06
diddledanEOD: Emergence of Destruction?17:14
lundmarHmm, 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
lundmarI thought snapcraft made staging appear as the system root.17:19
nacclundmar: have you ordered your yaml correctly?17:21
nacclundmar: which Qt do you mean, stage is a build-time thing, as well17:21
diddledanlundmar: snapcraft doesn't make the stage dir into a fake root17:22
lundmarnacc: 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/3ef4d1ba179d2c1a5cbac450d06f604ded24bbf417:22
lundmardiddledan: ok, so it's all LDCONFIG and enviroment variables directed.17:23
nacclundmar: you should be able to `snapcraft stage qtcharts` (iirc) and see what it put in stage/17:23
diddledanthe 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 parts17:24
lundmarthats 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
diddledantry adding a prefix of "/usr" which will be redirected into `$SNAPCRAFT_STAGE/usr`17:24
naccif they are in usr/local, then you need to tell Qt that, otherwise what diddledan is saying17:24
lundmarnacc: during build it seems to stage qtcharts successfully.17:25
lundmarI'll try change the prefix17:26
lundmarassuming the qmake plugin supports it haha17:26
diddledanI'm not familiar with qmake but cmake and autotools both provide the ability to set prefix=17:26
diddledanso I'd be surprised if qmake was different17:26
lundmarI'll find out17:26
nacci'm guessing it's a qmake option?17:27
lundmarthats a short doc he he17:27
diddledanok, so if you find out the qmake command line flag then set `options: [--your-qmake-prefix-flag=/usr]`17:27
lundmarqmake PREFIX=...17:30
diddledanok so `options: [PREFIX=/usr]` should work17:31
lundmarI've started a build using that17:31
lundmarbtw, is there any way to avoid downloaing stuff repeatedly when using e.g. cleanbuild --debug ?17:33
lundmarI mean, it's a lot of download for each debug iteration17:33
lundmarwould be nice if it could be cached17: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
kyrofaniemeyer, what's the status of some way for a snap to say "I'm in use, don't update!" ?17:36
niemeyerkyrofa: Planned, wanted :)17:37
niemeyerkyrofa: Not in the schedule just yet..17:38
kyrofaAlright, thank you17:38
niemeyerkyrofa: That and manual postponing may be nice things for after the current promised features17:38
nacclundmar: yeah, i wish too17:38
nacclundmar: the probably is, it doesn't keep the lxd around, of course17:38
nacclundmar: 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
lundmarnacc: 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
naccogra_: yeah that works too17:42
naccogra_: the issue being if you ahve multiple envs, maintaining all of them starts to be a pain17:42
nacclundmar: --^ for the above, lxd profiles are nnice17:43
kyrofabrunosfer, I'm out of my meeting!17:43
naccbut afaik, snapcraft can't use them yet17:43
diddledanuse `SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft` instead of `snapcraft cleanbuild`17:43
kyrofabrunosfer, you still around?17:43
naccdiddledan: ah does that just call lxc directly?17:43
diddledanthen it will keep the lxc container between runs17:43
naccdiddledan: ah17:43
brunosferkyrofa: Yep! Still stuck...17:43
kyrofabrunosfer, very good. It's been a while since I've written some go, so let me test something out real quick17:44
brunosferkyrofa: Ok! Thanks ;)17:44
lundmardiddledan: oh, thanks. I'll try that.17:44
diddledanbest 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 available17:44
lundmardiddledan: 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
diddledanyup that looks right17:45
lundmarI 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
lundmarso for staging the way snapcraft foes this becomes an issue of course17:47
nacclundmar: even with a flag?17:47
lundmarnacc: I've haven't been able to find that flag.17:48
lundmarwouldn'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
nacclundmar: then you would be using the system ... which would not be a confinned snap?17:50
lundmarno no, I mean, during snap creation.17:50
diddledanlundmar: does `QMAKE_LIBDIR` work?17:51
lundmarduring runtime it should of course not use system but still be confined.17:51
lundmardiddledan: I've tried QMAKE_LIBDIR and QMAKE_INCDIR in the .pro file.17:52
nacclundmar: but presumably it nneeds those built things to be in the snap?17:52
lundmarnacc: yes, the ones that are staged.17:53
kyrofabrunosfer, alright, which part in the YAML is the "main" one? Are all the other go parts dependencies?17:53
nacclundmar: right, so you wouldn't want ot use the system if it had them :)17:53
lundmarnacc: in this case it stages qtchart and the remaining qt5 stuff comes from the core image.17:53
kyrofabrunosfer, the problem is that you're specifying a source that doesn't include the dependencies required17:54
lundmardiddledan: let me try the QMAKE_LIBDIR again17:54
brunosferkyrofa: the main part is "hype"17:55
diddledanyou might need to set it to QMAKE_LIBDIR="$QMAKE_LIBDIR:$SNAPCRAFT_STAGE/usr/lib" or some such17:55
brunosferkyrofa: how do you include the source from the required dependencies?17:55
diddledanagain IANAL so I probably got the syntax wrong17:56
lundmardiddledan: yeah, to avoid overriding it. got it.17:57
kyrofabrunosfer, 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
diddledanI expect snapcraft is setting it already, so you need to _add_ your path17:58
kyrofabrunosfer, local imports, like you're going here, can bite you17:58
kyrofaRelative imports17:59
brunosferkyrofa: but how can I set an absolute path for packages that I built in go?18:00
kyrofabrunosfer, here, this should help: https://stackoverflow.com/a/10688069/92548618:00
brunosferkyrofa: BTW The application is running in golang with no problems.18:00
kyrofabrunosfer, that's what I'm asking-- how do you have your workspace setup, and how are you building the application?18:01
brunosferkyrofa: 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
brunosferkyrofa: 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
kyrofabrunosfer, I'm asking how you do this _outside_ of snaps18:04
kyrofabrunosfer, ignoring snaps, what does your go workspace look like?18:04
brunosferkyrofa: I do: go run main.go18:05
brunosferkyrofa: GOPATH="/home/user"18:05
kyrofabrunosfer, and where is main.go relative to the GOPATH?18:06
brunosferkyrofa: GOROOT="/usr/lib/go-1.8"18:06
brunosferkyrofa: The main.go is in src/client/ and the bridge is in src/bridge relative to the GOPATH18:07
kyrofabrunosfer, so you have /home/usr/src/client and /home/usr/src/bridge ?18:07
brunosferkyrofa: Yes.18:08
kyrofabrunosfer, what happens if you run `go install client` ?18:09
brunosferkyrofa: It installs the client package in /usr/local/pkg18:10
kyrofaNot bin?18:10
brunosferkyrofa: But is this needed with the snapcraft tool? I though it would only be needed in go.18:11
brunosferkyrofa: Sorry /usr/bin/pkg18:11
brunosferkyrofa: Sorry for the bad information regarding the `go install client` process. It's giving me error on the GOROOTPATH18:15
kyrofabrunosfer, okay, so it doesn't work. What is the error?18:15
brunosferkyrofa: cannot find the package bridge. I guess it's some problem related with the GOROOT path, however I cannot change it.18:17
kyrofabrunosfer, no, it's the problem I just told you was a problem :)18:18
kyrofaPlease read that stackoverflow post18:18
kyrofaIf you manage to get it working with `go install`, it'll work in snapcraft18:18
brunosferkyrofa: Sorry I didn't understood...18:19
mvoogra_: is edge behind? in theory we should have edge builds (modulo bugs of course)18:20
ogra_mvo, 2.30 ...18:20
mvoogra_: uh, let me check why18:20
kyrofakalikiana, dude, just saw the on..to push18:21
ogra_(at least on armhf)18:21
kyrofakalikiana, tell me that's not a simple implementation18:21
kyrofaBeautiful work18:22
kyrofaAnd easy to make more generic, I think18:22
mvoogra_: 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=xenial18:23
mvoogra_: it says build starts in ~30min so fingers crossed, thanks for notifying me18:23
ogra_yeah :/18:23
ogra_i wonder when we're back to normal ...18:23
kalikianakyrofa: I feel I must've missed something. It looks too simple. Tests passed, though :-D18:23
kyrofaI know!18:23
* kyrofa waits with baited breath on Travis18:24
kyrofaErr. Bated18:24
ogra_yeah, baited might be a bit fishy ...18:24
kyrofaogra_, exactly what I thought as I pressed enter :P18:25
kalikianaMy thought was you might have bbq breath or something, and dogs looking at you18:26
kyrofaMmm, bbq18:26
kalikianaMight be the fact I'm due for dinner18:26
brunosferkyrofa: 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
kyrofabrunosfer, it has nothing to do with YAML. The problem is that you don't have a suitable workspace setup18:27
brunosferkyrofa: Ok. I will look further on that. Thanks.18:28
ogra_yeah, re-arragne that staplet there18:28
ogra_twist it 30° left ... that should work then :)18:28
kyrofaHmm... now I can't remember if I've shown my wife that movie18:28
kyrofabrunosfer, that stackoverflow answer has a link to the go conventions, try to follow them and your life will become less filled with pain18:29
brunosferkyrofa: Ahahahah Thanks for the medication ;)18:31
mupPR snapd#4525 opened: tests: new spread test for interface gpg-keys <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4525>18:53
kyrofaelopio, have you tried autopkgtests lately? It sounds like restrictions on other platforms may be over19:31
elopiokyrofa: like, no 500 anymore?19:33
kyrofaelopio, yeah, it might be back up now19:33
naccrequest.cgi is still disabled19:34
nacc(just asking Laney about it)19:34
jdstrandzyga-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#r16335259219:34
mupPR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4505>19:34
naccthe build farm is on, on all archs, that's all I can say19:34
elopiokyrofa: nop, 500 again19:34
kyrofanacc, in -devel?19:46
nacckyrofa: sorry, which, in -devel? you19:47
kyrofanacc, sorry, were you asking Laney in #ubuntu-devel? But now I realize the conversation is probably over, haha19:48
nacckyrofa: yeah, i pinged Laney there19:49
kyrofanacc, no response yet, though?19:51
nacckyrofa: yeah, nothing yet, afaict, it's still disabled (that's seaprate from the build farm)19:51
kyrofaAlright, I'll idle there and see what comes up19:51
kyrofanacc, thanks for letting us know :)19:51
nacckyrofa: np19:52
niemeyercachio: Fiddling with the images is proving very frustrating.. more so than just implementing priorities. Do you have that ready yet?20:19
mupPR snapd#4526 opened: tests: new spread test for gpg-public-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4526>20:19
cachioniemeyer, no yet, I was finishing the new tests for gpg20:20
niemeyercachio: Ok, let me dig into that then20:20
cachioniemeyer, sure20:20
niemeyercachio: The problem with the images is that we have too many assumptions on the name of the image20:20
niemeyercachio: So creating a new system that works just for one specific test ends up being troublesome20:20
cachioniemeyer, agree20:21
niemeyerI'm hoping to get done with these Spread fixes today still20:21
niemeyerWell, improvements really.. nothing is broken20:21
cachioniemeyer, ok, the next step to reduce test time should be automatically update the images20:22
cachiowith the dependencies20:22
cachioI have that task in the todo list since long time20:22
sergiusenskyrofa mind taking an initial view on snapcraft#1881 ? wording and what not21:48
mupPR snapcraft#1881: elf: better handling for newer libc6 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1881>21:48
kyrofasergiusens, sure thing21:48
mupPR snapcraft#1881 opened: elf: better handling for newer libc6 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1881>21:48
kyrofasergiusens, you may be interested in bug #174504022:09
mupBug #1745040: help command replaces the name of commands with itself <Snapcraft:New> <https://launchpad.net/bugs/1745040>22:09
mupPR 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!