| === JoshStrobl is now known as JoshStrobl|AFK | ||
| === robert_ancell_ is now known as robert_ancell | ||
| mup | PR snapcraft#1568 closed: lxd: don't re-inject the same snaps <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1568> | 03:46 |
|---|---|---|
| mup | PR snapcraft#1618 closed: states: add scriptlets to build state <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1618> | 03:46 |
| zyga-ubuntu | o/ | 05:21 |
| zyga-ubuntu | mvo: hey | 05:49 |
| zyga-ubuntu | just the man I wanted to see | 05:49 |
| zyga-ubuntu | mvo: https://github.com/snapcore/squashfuse/pull/1 | 05:51 |
| mup | PR squashfuse#1: Tweak implementation of dummy go module <Created by zyga> <https://github.com/snapcore/squashfuse/pull/1> | 05:51 |
| mvo | hey zyga-ubuntu | 05:51 |
| mvo | zyga-ubuntu: hyes, thanks for this PR! did you test it, does that work? I also tried a subdir approach and go get would only checkout the actual dir, not any other dirs. if it works, that would indeed be very nice | 05:53 |
| mvo | zyga-ubuntu: (i was doing it the other way around, the C source in a subdir) | 05:53 |
| zyga-ubuntu | mvo: it go builds but I didn't test the full govendor sync with it (I'd have to change paths) | 05:53 |
| zyga-ubuntu | mvo: right but that failed for me | 05:53 |
| zyga-ubuntu | mvo: the linker part was not working | 05:53 |
| zyga-ubuntu | mvo: and govendor complained if nothing referenced that | 05:54 |
| zyga-ubuntu | mvo: now it's working locally, if you commit I will be able to sync | 05:54 |
| mvo | zyga-ubuntu: let me try quickly based on your branch, if it works, +100, very nice | 05:54 |
| zyga-ubuntu | if it doesn't work we can remove that patch from history | 05:54 |
| zyga-ubuntu | mvo: one sec | 05:54 |
| zyga-ubuntu | http://paste.ubuntu.com/25757470/ | 05:54 |
| zyga-ubuntu | you want this in your snapd tree | 05:54 |
| mvo | zyga-ubuntu: oh, nice, yeah, this way around it works | 05:55 |
| mvo | zyga-ubuntu: \o/ | 05:55 |
| zyga-ubuntu | I can push this into your branch | 05:56 |
| mvo | zyga-ubuntu: please do, I will take care of the rest, that will simply some things | 05:56 |
| zyga-ubuntu | just say the word | 05:56 |
| zyga-ubuntu | done | 05:56 |
| mvo | zyga-ubuntu: thanks | 05:56 |
| mvo | zyga-ubuntu: (I guess that was the word your were looking for ;) | 05:56 |
| * mvo hugs zyga-ubuntu | 05:56 | |
| zyga-ubuntu | woot, I hope we can quickly solve this | 05:57 |
| zyga-ubuntu | do you want to make .6 with this feature? | 05:57 |
| mvo | zyga-ubuntu: no more 2.28 :) it will be part of 2.29 | 05:57 |
| mvo | zyga-ubuntu: unless regression of course, then there will be a .6 | 05:57 |
| zyga-ubuntu | hmmmm | 05:59 |
| zyga-ubuntu | Obtaining dependencies | 05:59 |
| zyga-ubuntu | Found unused ./vendor packages: | 05:59 |
| zyga-ubuntu | vu github.com/snapcore/squashfuse | 05:59 |
| zyga-ubuntu | Please fix via 'govendor remove +unused' | 05:59 |
| zyga-ubuntu | darn, govendor is too picky | 05:59 |
| zyga-ubuntu | why doesn't it see the test reference? | 05:59 |
| zyga-ubuntu | is govendor really syncing sudirectories or nothing? | 06:00 |
| mvo | zyga-ubuntu: hm, it is not complaining here, strange | 06:01 |
| zyga-ubuntu | let me reset my tree | 06:01 |
| zyga-ubuntu | it didn't complain when I had the tree in $GOPATH | 06:02 |
| zyga-ubuntu | but now it does | 06:02 |
| mvo | now I just need to make autogen.sh work in squashfuse | 06:02 |
| zyga-ubuntu | darn govendor | 06:02 |
| zyga-ubuntu | maybe we can just make get-deps.sh not fail on that? | 06:02 |
| mvo | zyga-ubuntu: I removed everyting squashfuse from my GOPATH and ran tests again, no error | 06:03 |
| * zyga-ubuntu thinks | 06:04 | |
| zyga-ubuntu | well | 06:04 |
| zyga-ubuntu | if it works in the build I'll be happy | 06:04 |
| zyga-ubuntu | mvo: and you want to twaek autogen for local development? | 06:04 |
| zyga-ubuntu | mvo: I'm building the package now | 06:04 |
| mvo | zyga-ubuntu: it complains for me about SQ_WANT_HIGHLEVEL missing | 06:05 |
| mvo | eh, "does not appear in AM_CONDITIONAL" | 06:05 |
| mvo | (not missing) | 06:05 |
| zyga-ubuntu | mvo: the beauty of autohell | 06:05 |
| mvo | zyga-ubuntu: did this work for you? | 06:05 |
| zyga-ubuntu | yes | 06:05 |
| zyga-ubuntu | but something odd is going on | 06:05 |
| mvo | zyga-ubuntu: I'm on artful, maybe because of that? | 06:05 |
| zyga-ubuntu | mvo: I just saw your dummy-{gcc,ld} output | 06:06 |
| zyga-ubuntu | something must be cached somewhere | 06:06 |
| zyga-ubuntu | ah | 06:06 |
| zyga-ubuntu | man, we didn't change the hash in vendor.json | 06:06 |
| mvo | zyga-ubuntu: git pull | 06:06 |
| zyga-ubuntu | I'm on artful too | 06:06 |
| zyga-ubuntu | k | 06:06 |
| mvo | zyga-ubuntu: that will update the vendor.json | 06:06 |
| zyga-ubuntu | got that now | 06:06 |
| zyga-ubuntu | fatal: Could not parse object 'f066269fbbcd0ec6232cdffbc0fe48c7e2f7ad97'. | 06:06 |
| mvo | woah | 06:07 |
| zyga-ubuntu | # cd /home/zyga/go/.cache/govendor/github.com/snapcore/squashfuse; git reset --hard f066269fbbcd0ec6232cdffbc0fe48c7e2f7ad97 | 06:07 |
| mvo | thats strange I just did "govendor fetch github.com/snapcore/squashfuse" | 06:07 |
| zyga-ubuntu | I'll kill that cache | 06:07 |
| zyga-ubuntu | now it worked | 06:08 |
| zyga-ubuntu | weird | 06:08 |
| zyga-ubuntu | maybe the cache was confused by my operations on the local tree earlier (I squashed/amended) | 06:08 |
| zyga-ubuntu | building in progress | 06:08 |
| mvo | zyga-ubuntu: yeah, just double checked, the hash i nthe vendor.json matches the git repo | 06:08 |
| zyga-ubuntu | it failed on three automake things now | 06:09 |
| zyga-ubuntu | Makefile.am:6: error: MAKE_EXPORT does not appear in AM_CONDITIONAL | 06:09 |
| zyga-ubuntu | Makefile.am:36: error: SQ_WANT_HIGHLEVEL does not appear in AM_CONDITIONAL | 06:09 |
| zyga-ubuntu | Makefile.am:48: error: SQ_WANT_LOWLEVEL does not appear in AM_CONDITIONAL | 06:09 |
| zyga-ubuntu | I think we are now in sync | 06:09 |
| mvo | yes | 06:10 |
| mvo | same that i get | 06:10 |
| zyga-ubuntu | brb, daughther goes to school | 06:10 |
| zyga-ubuntu | re | 06:31 |
| zyga-ubuntu | sorry, kids as usual :) | 06:31 |
| zyga-ubuntu | mvo: are you patching those? | 06:32 |
| zyga-ubuntu | I just started | 06:32 |
| mvo | zyga-ubuntu: hi, looks like issue #12 for squashfuse discusses the issue we are seeing | 06:32 |
| mup | PR #12: Bugfix/lp1480248 test reenable <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/12> | 06:32 |
| zyga-ubuntu | mvo: looking | 06:32 |
| mvo | zyga-ubuntu: I patched them but got stuck right after that :/ | 06:32 |
| zyga-ubuntu | hehe, look who reported it | 06:33 |
| zyga-ubuntu | mvo: how does it build in the archive? maybe there's a patch | 06:34 |
| mvo | zyga-ubuntu: aha, good idea | 06:34 |
| mvo | zyga-ubuntu: fwiw, feel free to attach your patch :) | 06:34 |
| zyga-ubuntu | mvo: I don't have anything yet, just reading the configure script now | 06:35 |
| mvo | zyga-ubuntu: mehhhh | 06:36 |
| zyga-ubuntu | mvo: I find it sad/silly that a half a dozen C file project is so hard to build | 06:36 |
| zyga-ubuntu | wat? | 06:36 |
| mvo | zyga-ubuntu: the m4 subdir is missing I think | 06:36 |
| zyga-ubuntu | I see it here | 06:36 |
| zyga-ubuntu | missing as in not copied somewhere? | 06:36 |
| mvo | zyga-ubuntu: thats govendor again, its really annyoing about subdirs | 06:36 |
| zyga-ubuntu | ah | 06:36 |
| mvo | zyga-ubuntu: rm -rf the squashfs and get it again | 06:36 |
| zyga-ubuntu | mv dummy m4/ | 06:36 |
| mvo | zyga-ubuntu: and then check the dir | 06:37 |
| zyga-ubuntu | ah, right, I was looking at the full git tree | 06:37 |
| zyga-ubuntu | did you get | 06:39 |
| zyga-ubuntu | extract.c:51:17: warning: implicit declaration of function ‘sqfs_makedev’; did you mean ‘sqfs_mode’? [-Wimplicit-function-declaration] | 06:39 |
| mvo | zyga-ubuntu: I wonder how to overcome the m4 subdir problem | 06:42 |
| zyga-ubuntu | mvo: mv dummy m4/dummy | 06:42 |
| zyga-ubuntu | done | 06:42 |
| zyga-ubuntu | we'll get the full set | 06:42 |
| zyga-ubuntu | (silly but, well it should work) | 06:42 |
| mvo | zyga-ubuntu: heh, smart | 06:42 |
| zyga-ubuntu | mvo: I'd say sad but I think we are in agreement :) | 06:43 |
| * mvo hugs zyga-ubuntu again | 06:43 | |
| zyga-ubuntu | mvo: I'll try something entirely different to see how crazy that would be | 06:43 |
| mvo | zyga-ubuntu: I update the trees for your approach in the meantime | 06:44 |
| zyga-ubuntu | ok | 06:44 |
| zyga-ubuntu | mvo: note that squashfuse uses a library now | 06:45 |
| zyga-ubuntu | mvo: where will we keep it? | 06:45 |
| zyga-ubuntu | mvo: it seems we need to link that statically | 06:45 |
| mvo | zyga-ubuntu: yes, we need to link statically | 06:46 |
| zyga-ubuntu | mvo: note, just the library, the rest can be dynamic | 06:46 |
| zyga-ubuntu | (to avoid hair-pulling in other distros0 | 06:46 |
| mvo | zyga-ubuntu: hm, adding github.com/snapcore/squashfuse/ does no longer work for me without go files in it, it is just silently ignored | 06:53 |
| zyga-ubuntu | mvo: take a break from this problem for two hours please | 06:54 |
| zyga-ubuntu | mvo: if my approach fails we can go back to adding more hackery | 06:54 |
| mvo | zyga-ubuntu: ok | 06:57 |
| zyga-ubuntu | mvo: how are we calling the binary? snapfuse? | 06:58 |
| mvo | zyga-ubuntu: yes | 07:00 |
| mvo | zyga-ubuntu: https://github.com/snapcore/snapd/pull/4049/commits/bff17ef731ea8e2bc88a1ab2066b33a2bc8c0e31#diff-42c07ec7ffa970857b4e0db2614e482bR428 | 07:00 |
| mup | PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049> | 07:00 |
| zyga-ubuntu | thank you! | 07:02 |
| knurd | Lo. Is it still possible somehow to set up your own snap store and configure snap to use it? Looks like https://github.com/noise/snapstore/ stopped working a while ago and was abandoned recently. | 07:03 |
| knurd | I already asked on https://plus.google.com/+ThorstenLeemhuis/posts/HyHfxaFQWz2 but got no reply | 07:03 |
| zyga-ubuntu | knurd: please look at forum.snapcraft.io, this has been extensively discussed there under the topic "extenral repositories" | 07:10 |
| knurd | zyga-ubuntu: thx for the pointer! | 07:12 |
| zyga-ubuntu | wa | 07:14 |
| zyga-ubuntu | mvo: almost there, I think | 07:28 |
| mwhudson | zyga-ubuntu: btw i poked at 2.28.5 in debian, i didn't do the dependency updates though | 07:30 |
| mwhudson | i should push what i have to alioth i guess | 07:30 |
| mwhudson | vendor.json diffs are hard to read :( | 07:30 |
| mvo | fwiw 4047 needs a second review | 07:32 |
| zyga-ubuntu | mwhudson: ack | 07:34 |
| zyga-ubuntu | mwhudson: I'll have a look, I cannot promise anything soon though (I need to trim my PR list) | 07:34 |
| mwhudson | yeah. o | 07:34 |
| mwhudson | bah | 07:34 |
| mwhudson | yeah, i'll try to poke at it over the next couple of days too | 07:35 |
| zyga-ubuntu | mvo: http://pastebin.ubuntu.com/25757771/ | 07:35 |
| zyga-ubuntu | mvo: integrated into our build system | 07:35 |
| mvo | zyga-ubuntu: nice, I wonder if libfuse is installed by default | 07:36 |
| mvo | and 4028 (easy) needs a second review | 07:36 |
| mvo | zyga-ubuntu: curious what you did and how you overcame the m4 subdir issue | 07:39 |
| zyga-ubuntu | mvo: I can link that statically | 07:40 |
| mvo | zyga-ubuntu: I think we just need to check in the lxd base image | 07:40 |
| zyga-ubuntu | mvo: I just integrated that into our build, the whole set of m4 macros is needed for things we don't need | 07:40 |
| zyga-ubuntu | we can also drop code like non xz compression and windows support files | 07:41 |
| mvo | zyga-ubuntu: *nod* | 07:41 |
| zyga-ubuntu | mvo: shall I review 4028? :D | 07:47 |
| mvo | zyga-ubuntu: ;) I was hoping pstolowski or chipaca might have a look | 07:48 |
| zyga-ubuntu | mvo: I tweaked the build system to simplify what we need, I'll run a spread test if that works | 07:50 |
| zyga-ubuntu | mvo: I'll push this for reference but I want to re-do it so that we can import git history | 07:50 |
| zyga-ubuntu | mvo: we might be able to pull in fixes from squashfuse upstream this way | 07:51 |
| zyga-ubuntu | mvo: so far so good though | 07:51 |
| pstolowski | approved | 07:51 |
| zyga-ubuntu | mvo: we can also go through the code and simplify windows bits out | 07:51 |
| zyga-ubuntu | mvo: builds are ok, testing in spread | 08:17 |
| zyga-ubuntu | mvo: once this works I'll ask you to review and then let's see what to do about history, ok? | 08:19 |
| mvo | ok | 08:21 |
| zyga-ubuntu | mvo: https://github.com/zyga/snapd/tree/rfc/integrated-squashfuse | 08:21 |
| zyga-ubuntu | this is the code | 08:21 |
| zyga-ubuntu | mvo: and this is the new part essentially: https://github.com/zyga/snapd/commit/3545b115cb90e702779c43703f70db9e01b10cff | 08:22 |
| zyga-ubuntu | mvo: lxd test now running | 08:28 |
| zyga-ubuntu | fingers crossed | 08:28 |
| zyga-ubuntu | doh :) | 08:38 |
| zyga-ubuntu | silly mistake | 08:38 |
| zyga-ubuntu | fixed now, re-running tests | 08:38 |
| zyga-ubuntu | I didn't enable XZ | 08:38 |
| Chipaca | moin | 08:38 |
| zyga-ubuntu | Chipaca: hey | 08:40 |
| zyga-ubuntu | mvo: it works now, I think I need to expand this to cover more packaging | 08:51 |
| mvo | zyga-ubuntu: just cherry pick my bits from https://github.com/snapcore/snapd/pull/4030 | 08:56 |
| mup | PR #4030: many: add internal squashfuse copy as "snapfuse" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4030> | 08:56 |
| zyga-ubuntu | mvo: aha, thank you | 08:56 |
| mvo | zyga-ubuntu: I will revert 4049 back to the original state, lets see what niemeyer thinks about the two approaches as they have boths pros/cons | 08:57 |
| Tazmania | Hello, I have a Dell atom based mini PC came pre-installed with Ubuntu Core 16. I would like to know if it is possible to install cmake and domoticz packages on it? I am a newbie to Snappy, please pardon me. | 09:00 |
| mvo | zyga-ubuntu: but maybe/probably the govendor approach is doomed as it cannot statically link selectively via configure | 09:01 |
| zyga-ubuntu | mvo: fingers croessed | 09:03 |
| zyga-ubuntu | mvo: https://github.com/snapcore/snapd/pull/4051 | 09:03 |
| mup | PR #4051: many: add integrated snapfuse <Created by zyga> <https://github.com/snapcore/snapd/pull/4051> | 09:03 |
| mup | PR snapd#4051 opened: many: add integrated snapfuse <Created by zyga> <https://github.com/snapcore/snapd/pull/4051> | 09:03 |
| zyga-ubuntu | mvo: I'll break for shower/coffee as I'm still in my pijamas today | 09:03 |
| mvo | Tazmania: if you want to develop its probably easiest if you "snap install classic; classic" | 09:03 |
| mvo | Tazmania: eh, "sudo snap install --devmode --beta classic" that is | 09:04 |
| mvo | zyga-ubuntu: heh, thank you! | 09:04 |
| zyga-ubuntu | Tazmania: and please look at forum.snapcraft.io, lots of friendly people there and lots of questions answered already | 09:04 |
| Tazmania | What's the difference between classic and the pre-installed? | 09:04 |
| Tazmania | zyga-ubuntu: thanks. I will check the forum | 09:04 |
| mvo | zyga-ubuntu: did you add a patch to fix the sqfs_makedev() error ? | 09:04 |
| zyga-ubuntu | mvo: compare diffstat in 4030 and 4051 | 09:05 |
| zyga-ubuntu | automake is crazy | 09:05 |
| zyga-ubuntu | mvo: hmmmmm, I don't think I did | 09:05 |
| mvo | Tazmania: classic is a environment that makes it easy to develop using the classic tools | 09:05 |
| Tazmania | mvo: thanks | 09:05 |
| zyga-ubuntu | mvo: have a look at my branch please, let's see what we can cut from snapfuse/*.[ch] | 09:05 |
| mvo | zyga-ubuntu: interessting, I get a warning that is turned into an error here | 09:05 |
| zyga-ubuntu | mvo: hmm, spread passed for me, hmmm | 09:06 |
| mvo | zyga-ubuntu: cool | 09:06 |
| zyga-ubuntu | maybe I did but I didn't notice :) | 09:06 |
| zyga-ubuntu | anyway, afk for a moment | 09:06 |
| mvo | zyga-ubuntu: lets see what gustavo thinks, I personally would like to make snapfuse as much "imported" as possible and ideally not modify it but I see the advantages so lets see how gustavo feels about what approach should be taken | 09:07 |
| mvo | zyga-ubuntu: see you | 09:07 |
| zyga-ubuntu | mvo: shall we prepare an alt version that has working imported approach? | 09:14 |
| zyga-ubuntu | mvo: I mean, it might be even this code, we could just depend on a script that gets the debian .orig tarball | 09:15 |
| zyga-ubuntu | mvo: (via get-deps) | 09:15 |
| popey | diddledan: sorry for the delay, testing your corebird snap | 09:16 |
| mvo | zyga-ubuntu: lets talk after you had your shower, I'm not sure myself. | 09:18 |
| zyga-ubuntu | I'm back already | 09:19 |
| zyga-ubuntu | mvo: ok, I'll look at failing tests in one of my PRs and let's wait to see if 4051 is green | 09:20 |
| mvo | zyga-ubuntu: for when you are back - do you happen to know why none of our tests caught the typo https://github.com/snapcore/snapd/pull/3617/files#diff-ec8cacef522dbb27eeb9ceed25f03b22R249 ? I mean, we have a integration test for network-control, why does that not fail on invalid content? can we add that? | 09:37 |
| mup | PR #3617: interfaces/builtin: use udev tagging more broadly <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3617> | 09:37 |
| zyga-ubuntu | mvo: looking | 09:39 |
| zyga-ubuntu | aha, that typo | 09:39 |
| zyga-ubuntu | let me think | 09:39 |
| mvo | zyga-ubuntu: I'm breaking it on purpose now and run the spread test to see if our checks are insufficient | 09:39 |
| mvo | zyga-ubuntu: does udev not error when we write incorrect files? | 09:40 |
| zyga-ubuntu | mvo: are those tests checking tun devices? | 09:40 |
| zyga-ubuntu | mvo: I think the file was parsing OK, just not doing what we wanted | 09:40 |
| mvo | zyga-ubuntu: no, no checks for tun devices. hm, ok, if its valid syntax just the wrong one that is hard to test | 09:41 |
| zyga-ubuntu | mvo: maybe if the rules looks like `KERNEL=="foo", TAG+="...",\nKERNEL=="bar", TAG+="..."` the rule is just a no-op | 09:41 |
| zyga-ubuntu | mvo: as in, it will never match both "foo" and "bar" | 09:41 |
| mvo | zyga-ubuntu: there was an extra "," at the end of the line | 09:41 |
| zyga-ubuntu | I can test that theory but I need to get to the bottom of something failing in my branch first | 09:41 |
| mvo | (in this particular case) | 09:41 |
| zyga-ubuntu | mvo: right but , is a separator for udev expressions | 09:41 |
| mvo | zyga-ubuntu: sure, I can chase this | 09:42 |
| mvo | zyga-ubuntu: aha, ok | 09:42 |
| zyga-ubuntu | mvo: we could build a simple safeguard | 09:42 |
| zyga-ubuntu | mvo: add a new api to udev.Specification | 09:42 |
| zyga-ubuntu | mvo: that has less flexibility in it | 09:42 |
| zyga-ubuntu | mvo: we could then rewrite vast majority of udev rules to use that | 09:42 |
| zyga-ubuntu | mvo: and maybe keep {modem,network}-manager as the only uses of the more powerful, type-unchecked api | 09:43 |
| zyga-ubuntu | mvo: essentially there's no type checking anywhere there | 09:43 |
| zyga-ubuntu | mvo: we could also have a test that parses all the snippets | 09:43 |
| zyga-ubuntu | mvo: and ensures that some simple impossible conditions are not present | 09:44 |
| zyga-ubuntu | mvo: like tests that attr == "a" and attr == "b" at the same time | 09:44 |
| zyga-ubuntu | mvo: I did something similar-ish for apparmor rules earlier (I was fully parsing them, there's still a branch somewhere I can find) | 09:44 |
| mvo | zyga-ubuntu: ok, thank you. sounds all like some work | 09:44 |
| zyga-ubuntu | mvo: sorry, it's not apparmor, it was seccomp, | 09:46 |
| zyga-ubuntu | mvo: the branch starts at 87826dc09a7a43357500329032185544b53c5c91 | 09:46 |
| zyga-ubuntu | mvo: feature/typed-syscalls in my remote | 09:46 |
| zyga-ubuntu | mvo: that ensures that seccomp rules are well typed | 09:46 |
| zyga-ubuntu | mvo: udev rules are not too sopisticated, we could do something like that too | 09:47 |
| zyga-ubuntu | mvo: even if it's just for testing | 09:47 |
| * Chipaca realises the time and runs to make it to physio | 09:47 | |
| zyga-ubuntu | Chipaca: o/ | 09:47 |
| zyga-ubuntu | run slowly and safely man | 09:47 |
| * zyga-ubuntu fixed his other brnach | 09:49 | |
| mvo | pstolowski, zyga-ubuntu: related, the lxd-demo-server stopped because we had lxd as reserved for the OS, when that started to fail we changed something else, right? more strict checking in the interfaces code, does anyone remember details? | 09:52 |
| mvo | hey Chipaca | 09:52 |
| mvo | (sorry for the many questions, writing the retrospect right now) | 09:52 |
| zyga-ubuntu | mvo: I don't remember, let me look | 09:53 |
| pstolowski | mvo, there was a change recently (the week after the sprint) to that interface | 09:53 |
| skjensen | Hi Guys, I'm trying to build Ubuntu Core for Nvidia TX1 it's a arm64 bit system. I'm following this guide: https://wiki.ubuntu.com/ARM64/FoundationModel but the link to download ubuntu-core-13.10-core-arm64.tar.gz is broken. I have tried to find a more recent version of the core for arm64 but without luck.. | 09:54 |
| zyga-ubuntu | mvo: I only found 042f9d0085bf6fe0ff82345cc58804d9e21eb318 | 09:54 |
| skjensen | Does anyone know where I can find it, if it exist? | 09:54 |
| zyga-ubuntu | skjensen: ubuntu-core-13.10? | 09:54 |
| zyga-ubuntu | ogra_: ^ | 09:54 |
| skjensen | I would like ubuntu-core-16.04 | 09:54 |
| zyga-ubuntu | I think that's something for you | 09:54 |
| mvo | pstolowski: yes, we fixed the issue in that PR a week after the sprint. I wonder what commit/PR broke it though, it was reserved for the OS since forever afaik. | 09:55 |
| pstolowski | zyga-ubuntu, mvo yes, that's the change I meant | 09:55 |
| zyga-ubuntu | mvo: I think we just never tested that combination mvo | 09:55 |
| zyga-ubuntu | mvo: you added a test for this later | 09:55 |
| zyga-ubuntu | mvo: after the brekage occurred | 09:55 |
| mvo | zyga-ubuntu: stgraber reported lxd-demo-server used to work and started breaking with 2.28 | 09:55 |
| mvo | zyga-ubuntu, pstolowski ok, I chase that, thanks for your input! | 09:56 |
| zyga-ubuntu | skjensen: ogra is the person for that question, I think there is (or might be) a model/gadget/kernel for TX1 but I'll let him answer with authority | 09:56 |
| zyga-ubuntu | wow, incredible, I can actually write a new feature now | 09:56 |
| zyga-ubuntu | and it's 11:56 | 09:56 |
| ogra_ | skjensen, the old ubuntu-core has been enamed to "ubuntu-base", tarballs can be found at http://cdimage.ubuntu.com/ubuntu-base/ | 09:56 |
| ogra_ | *renamed | 09:56 |
| skjensen | Great thanks.. :) Is there one for the TX1? | 09:57 |
| zyga-ubuntu | mvo: I spoke too soon, the fuse stuff, no fuse on 14.04 | 09:58 |
| zyga-ubuntu | mvo: so packaging diverges | 09:58 |
| zyga-ubuntu | mvo: and this is now optional | 09:58 |
| zyga-ubuntu | mvo: meeh | 09:58 |
| zyga-ubuntu | skjensen: do you want classic ubuntu headless or the new snap-based ubuntu (aka ubuntu-core nowadays) | 09:59 |
| ogra_ | skjensen, if you want an actual snap based UbuntuCore install then you need to create a gadget snap and use ubuntu-image to build an image for it ... the jetson tk1 is supported in the llinux-generic-bbb kernel (by selecting the tegra124-jetson-tk1.dtb devicetree froom the gadget snap) | 09:59 |
| skjensen | I want the new snap-based ubuntu due to the new features. It's for a IoT deployment | 09:59 |
| ogra_ | skjensen, the -base tarballs are just root filesystems just pick the arm64 one | 10:00 |
| zyga-ubuntu | skjensen: I'd suggest you open a forum thread about TX1 core image | 10:01 |
| ogra_ | skjensen, aha ... https://ograblog.wordpress.com/2017/05/30/building-u-boot-gadget-snap-packages-from-source/ and https://ograblog.wordpress.com/2017/06/13/patching-u-boot-for-use-in-an-ubuntu-core-gadget-snap/ ae what you want then | 10:01 |
| kalikiana | clobrano: hey | 10:01 |
| zyga-ubuntu | skjensen: you should familiarize yourself with some snappy concepts (models, gadget snaps, kernel snaps) to make a proper set of files needed to support this | 10:01 |
| c-lobrano | kalikiana: hi | 10:01 |
| kalikiana | c-lobrano: You wanted to work on bug 1722650? | 10:02 |
| mup | Bug #1722650: snapcraft requires optional VERSION_ID in os-release <bitesize> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1722650> | 10:02 |
| zyga-ubuntu | skjensen: doing that on the forum is easier and many people can participate (across timezones) | 10:02 |
| ogra_ | skjensen, create that gadget, make it use tegra124-jetson-tk1.dtb and once you have that ping me again and we'll talk abut how you get yur own kernel build fom the linux-generic-bbb snap | 10:02 |
| zyga-ubuntu | ogra_: btw, do you have the TX1 or the TX2? | 10:02 |
| zyga-ubuntu | ogra_: are they decent machines? I was thinking about getting one simply because it has oodles of ram (for an arm board) | 10:02 |
| ogra_ | zyga-ubuntu, nope ... i stopped after tegra2 ... | 10:03 |
| c-lobrano | kalikiana: yes, but before pushing a change according to what you suggested, I'd like to see what kind of file snapcraft is looking for | 10:03 |
| zyga-ubuntu | ogra_: aha, thank you | 10:03 |
| ogra_ | they shoudl be in the relam of a dragonbard | 10:03 |
| skjensen | I got the TX1 and actually got a TK1 as well.. But we decided we needed the TX1 to run out software since it uses TensorFlow and that's not supported anymore on the TK1 | 10:03 |
| kalikiana | c-lobrano: Do you have a local checkout of snapcraft? | 10:03 |
| zyga-ubuntu | mvo: shall I change the snapfuse PR now or would you rather wait for gustavo's opinion first? | 10:03 |
| kalikiana | c-lobrano: You can have a look at the "libraries" folder | 10:03 |
| c-lobrano | kalikiana: yes, I've already branched the project for a previous PR | 10:04 |
| c-lobrano | *forked | 10:04 |
| skjensen | It's a work project, so I got the next 2 months to dive into the snap universe and get a proper version up and running on the TX1. Thanks for all the help to get started on this. I will let you know how I get on.. :) | 10:04 |
| mvo | zyga-ubuntu: either way is fine with me | 10:05 |
| zyga-ubuntu | skjensen: welcome aboard, the forum has a "docs" category with useful documentation | 10:05 |
| skjensen | Great :) | 10:06 |
| zyga-ubuntu | skjensen: there's also the "device" category for topics related to making and supporting new devices | 10:06 |
| zyga-ubuntu | https://forum.snapcraft.io/c/device | 10:06 |
| zyga-ubuntu | https://forum.snapcraft.io/c/doc | 10:07 |
| zyga-ubuntu | https://forum.snapcraft.io/t/the-gadget-snap/696 | 10:07 |
| ogra_ | skjensen, well, start with the gadget and for easiness i'd take the tk1 first ... the gadget between the two will only differ minimally so you can re-use it for tx1 with some minimal changes ... the difference between the tw is that you will need your own kernel for the tx1 so fr a start the tk1 will be easier ... | 10:07 |
| zyga-ubuntu | https://forum.snapcraft.io/t/the-kernel-snap/697 | 10:07 |
| ogra_ | skjensen, just folllow the blogposts i gave yu abve, they have a step by step guide and all links to alll docs yu need | 10:08 |
| skjensen | ogra_ thanks, I will get started on the TK1 to get some experience.. and then move onto the TX1 | 10:08 |
| ogra_ | iirc there was also some jetson work done initially by parrot ... not sure if they put that in github though | 10:09 |
| kalikiana | c-lobrano: Perfect. So if you see the "libraries" folder, there's a file "16.04" in there, which if you open it contains a lot of filenames. | 10:12 |
| kalikiana | That's the ones that get stripped from the snap | 10:12 |
| c-lobrano | kalikiana: oh, I see | 10:13 |
| skjensen | ogra_ super, and I can guarantee you my work will go up on github for everyone to use.. | 10:13 |
| ogra_ | \o/ | 10:13 |
| c-lobrano | kalikiana: so, if no VERSION_ID exists, there is no way to find "another equivalent" file, right? | 10:14 |
| kalikiana | c-lobrano: The code basically wants to know that it runs on Ubuntu 16.04 and do its thing. If VERSION_ID isn't there... it should probably be equivalent to a different version, like say 17.10, in which case there's no file | 10:16 |
| c-lobrano | kalikiana: perfect, so I can propose my PR | 10:21 |
| kalikiana | c-lobrano: Yeah. I think kyrofa made a good point there with regard to abstracting it, tho not sure it should be done in the same PR... unless you'd like to look into that as well? | 10:23 |
| ogra_ | mvo, you might want to mention https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1724088 in the changelog for the release | 10:26 |
| mup | Bug #1724088: All snap packages fail to start with 'udev_enumerate_scan failed' <snapd (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1724088> | 10:26 |
| c-lobrano | kalikiana: oh, I wasn't subscribed to the bug yet, and I missed kryofa's comment. What about doing two PR, one for the bug and one for the "new feature"? | 10:30 |
| mup | PR snapd#4052 opened: tests: check for invalid udev files during all tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/4052> | 10:36 |
| kalikiana | c-lobrano: Yeah, that's what I was thinking as well. The fix itself is straight-forward | 10:36 |
| c-lobrano | kalikiana: alright. I'm in the middle of ./runtest.sh unit, then I can push the PR | 10:37 |
| kalikiana | c-lobrano: Awesome. Thanks for working on it! | 10:43 |
| c-lobrano | kalikiana: yw :) | 10:44 |
| zyga-ubuntu | mvo: there's a typo in tihs: | 10:53 |
| zyga-ubuntu | 2017-10-12 Bureport from 16.04 users about udev_enumerate_scan failure not fixed until the machine is reported. This is unacceptable so we added cleanup code into snap-confine to cleanup the state that caused libudev to be erroring (releated to the udev device tagging that was incorrectly applied to nvidia devices) - PR#4042. | 10:53 |
| zyga-ubuntu | s/machine/machine is rebooted/ | 10:53 |
| zyga-ubuntu | mvo: otherwise great writeup, thank you! | 10:54 |
| * zyga-ubuntu goes to pick up his son from new school. will probably miss the standup in traffice, be back in two+ hours | 10:58 | |
| mup | PR snapcraft#1623 opened: Removed dependency on VERSION_ID in os-release <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1623> | 11:41 |
| kalikiana | c-lobrano: Could you add a unit test for your fix? Probably in snapcraft/tests/test_libraries.py | 12:06 |
| c-lobrano | kalikiana: sure | 12:06 |
| zyga-ubuntu | re, waiting for son in school | 12:07 |
| c-lobrano | kalikiana: just let me see how to do it :) | 12:16 |
| niemeyer | o | 12:26 |
| niemeyer | o/ | 12:26 |
| Chipaca | \o | 12:28 |
| sergiusens | o/ | 12:31 |
| Chipaca | /o/ | 12:35 |
| Chipaca | \o\ | 12:35 |
| niemeyer | \_o_/ | 12:35 |
| niemeyer | mvo: What's up with snapfuse? (Wondering about zyga's comment above) | 12:36 |
| niemeyer | (and about the new PR) | 12:36 |
| ogra_ | first rule of the snappy yoga club ... don't talkk about the snappy yoga club | 12:36 |
| niemeyer | ogra_: You just broke it | 12:38 |
| ogra_ | yeah, the evil in me ... :) | 12:38 |
| mvo | niemeyer: its mostly about details in how we should do it. I was trying to use "govendor fetch" to get it. however its really fighting govendor more than anything else. the alternative is to embedd it, zygas approach is to integrate it pretty close (including putting it into our make files instead of using the upstream makefiles). I was mostly curious about your suggested approach | 12:39 |
| mvo | ogra_: thanks for the pointer to the bug about udev_enum_failed | 12:40 |
| ogra_ | np | 12:40 |
| ackk | hi, could anyone kick a CI run on https://github.com/snapcore/snapd/pull/3916? I suspect there were some infrastructure issues on the previous run | 12:41 |
| mup | PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916> | 12:41 |
| niemeyer | mvo: What happened with govendor? I was hopeful as well | 12:42 |
| mvo | niemeyer: its still there in #4049, but open issues and I had to be quite creative to make it go getable (https://github.com/snapcore/squashfuse/commit/ed6f37bbee6537e0598aa7f4f5dafa379be0c73a) | 12:45 |
| mup | PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049> | 12:45 |
| kalikiana | c-lobrano: Feel free to pester me with questions as needed :-D | 12:46 |
| niemeyer | mvo: Oh, I see.. so govendor will still use go get | 12:46 |
| mvo | niemeyer: we can further explore this, we need to link some (or all) libs for snapfuse statically to ensure we don't add other hidden dependencies | 12:46 |
| c-lobrano | kalikiana: :D I'll do | 12:46 |
| mvo | niemeyer: yes, I could not make it just fetch my git tree, it was slightly confusing as you can add things and it will not err/warn but just silently ignore it if it does not look like a go repo | 12:47 |
| niemeyer | Hmmm | 12:48 |
| mvo | niemeyer: we can talk more in the standup, zygas PR is much much closer (and conceptually easier). the downside is that we need to track upstream | 12:50 |
| mvo | (closer) | 12:50 |
| niemeyer | mvo: If all we want is to get the tree and not compile, we might just drop a Go file somewhere | 12:50 |
| * kalikiana time for a break | 12:53 | |
| mvo | niemeyer: that is what I did, unfortuantely once there are C files in the tree it will try to compile them (it being go) | 12:53 |
| niemeyer | mvo: It won't try to compile any place that you don't explicitly get | 12:53 |
| mvo | niemeyer: so yeah, we can make it work its just a bit more hacky and we need to solve how to statically linki in that PR | 12:53 |
| niemeyer | mvo: e.g. if you create a directory and drop a println("hi") on a .go file on it, and get _that_ package path, it won't care about the rest | 12:53 |
| mvo | niemeyer: correct, but it will also only get that directory and leave parent dirs empty | 12:54 |
| niemeyer | mvo: No.. it fetches the whole repository | 12:54 |
| niemeyer | mvo: There's no way to tell git to fetch a subtree | 12:55 |
| mvo | niemeyer: you are right, this is what I see with go get too, I wonder why I had a different experience with govendor, I can try this again and understand the details | 12:57 |
| skjensen | ogra_ I'm trying to follow your beaglebone guide to build for the TK1, but I'm a bit unsure about the uboot.env.in file? Where did you get that from? | 12:58 |
| ogra_ | skjensen, you start with "printenv" in the uboot shell to get the default env ... then you need the load* scripts to load the right files and all the snappy_* and snap_* vars (and scripts) | 12:59 |
| * zyga-ubuntu is online but in super-noisy place | 13:01 | |
| ogra_ | and examples are at https://github.com/ogra1/beaglebone-gadget/blob/master/uboot.env.in ... or https://github.com/ogra1/pi3-gadget/blob/master/uboot.env.in | 13:01 |
| skjensen | okay, thanks.. | 13:03 |
| ogra_ | the essential bits are "loadfiles" and "snappy_boot" | 13:04 |
| skjensen | okay.. :) | 13:06 |
| c-lobrano | kalikiana: I'm using TestSystemLibsOnNewRelease as template, mocking get_os_release_info in order to return a dict without VERSION_ID, but somehow I still get the 16.04 list of .so, maybe you can spot my mistake http://paste.ubuntu.com/25759264/ | 13:12 |
| === ShalokShalom_ is now known as ShalokShalom | ||
| kalikiana | c-lobrano: _get_system_libs uses a global variable. Can you try unsetting it in the setup method? | 13:29 |
| kalikiana | ie. `_libraries = None` | 13:30 |
| kalikiana | it's set and checked at the top of the _get_system_libs function | 13:30 |
| c-lobrano | I see, but it doesn't seem to work | 13:38 |
| kalikiana | you tried it like that? | 13:40 |
| === JoshStrobl|AFK is now known as JoshStrobl | ||
| c-lobrano | yes, with global _libraries first | 13:42 |
| kalikiana | c-lobrano: Hmmm maybe you can mock.pantch _libraries? | 13:46 |
| kalikiana | And give it .return_value = None | 13:46 |
| c-lobrano | kalikiana: good idea, let me try | 13:46 |
| * c-lobrano haven't used unittest.mock much so far | 13:47 | |
| c-lobrano | kalikiana: it was easier than expected "libraries._libraries = None" | 13:55 |
| kalikiana | Oh, nice | 13:55 |
| c-lobrano | saint StackOverflow ;D | 13:55 |
| c-lobrano | kalikiana: weird, can't see the PR updated | 14:06 |
| kalikiana | c-lobrano: I don't see it either. Did you `git push origin bug-lp1722650` the branch? | 14:10 |
| c-lobrano | kalikiana: I did `git push -f` actually, but I can see it on my repo | 14:10 |
| c-lobrano | https://github.com/snapcore/snapcraft/compare/master...clobrano:bug-lp1722650 | 14:11 |
| kalikiana | Hmm. Even if you amended the commit it should have updated automatically | 14:12 |
| kalikiana | Or did you completely re-do the branch under the same name? | 14:13 |
| cachio_ | pstolowski, mvo I have the same issue with the pi3 using 2.28.5 | 14:15 |
| cachio_ | I try to creata the image by using the deb ubuntu-image | 14:16 |
| pstolowski | cachio_, i've just finished preparations, about to run the test | 14:16 |
| mvo | cachio_: did you and pstolowski figure out in what way the test differed between you? | 14:16 |
| kalikiana | btw sergiusens did you want to have a one on one today? You mentioned it the other day, but I have none anymore in my calendar since you removed it last time | 14:17 |
| cachio_ | mvo, a diff is the tool we used to create the image | 14:17 |
| pstolowski | mvo, i used ubuntu-image from the distro (not snap), however the version number is the same, so perhaps that's irrelevant | 14:18 |
| c-lobrano | kalikiana: just amended | 14:18 |
| kalikiana | c-lobrano: Hmm weird. It should just show up then | 14:18 |
| mvo | cachio_, pstolowski aha, thats very interessting | 14:18 |
| pstolowski | mvo, it's hard to compare the versions of other stuff, Sergio flashed his card already. this time we will generate beta images at the same time | 14:19 |
| mvo | pstolowski: \o/ | 14:19 |
| Chipaca | kalikiana, sergiusens, kyrofa, who's fielding questions along the lines of "why does a snap built with this snapcraft.yaml throw these library errors"? | 14:20 |
| * kyrofa runs | 14:20 | |
| kyrofa | Chipaca, hit me :) | 14:21 |
| kalikiana | haha | 14:21 |
| * Chipaca picks up a 15kg wrench | 14:21 | |
| zyga-ubuntu | Chipaca: are you going to mend the computer? | 14:21 |
| Chipaca | kyrofa: actually i'm asking on behalf of https://forum.snapcraft.io/t/how-do-i-create-an-opengles2-and-glfw3-snap/2488 | 14:21 |
| * zyga-ubuntu is in a bus, working like it's his office | 14:22 | |
| Chipaca | zyga-ubuntu: put pants on, man! | 14:22 |
| kyrofa | Chipaca, alright I'll take a look, thanks for the ping :) | 14:23 |
| zyga-ubuntu | Chipaca: oh my! | 14:24 |
| zyga-ubuntu | and I thought I just looked good | 14:24 |
| zyga-ubuntu | all the people staring | 14:24 |
| sergiusens | Chipaca the title doesn't make me feel it would be easy as the text below it makes it | 14:27 |
| c-lobrano | kalikiana: alright, changed commit message a bit, now github recognized the update :D | 14:27 |
| Chipaca | sergiusens: users gonna use | 14:27 |
| sergiusens | Chipaca isn't all the gl stuff supposed to be mirrored into the snap through the snapd mounts? | 14:28 |
| sergiusens | zyga-ubuntu ^ ? | 14:28 |
| Chipaca | was about to say, i think some magic is done, but ask zyga-ubuntu :-) | 14:28 |
| Chipaca | this might just be a "add the opengl interface" or something | 14:28 |
| * Chipaca no sabe | 14:28 | |
| kalikiana | c-lobrano: One note on the test data. How about using something other than Xenial where it's normal to have no VERSION_ID field? | 14:32 |
| kalikiana | Otherwise it's potentially confusing to someone reading the test | 14:32 |
| Chipaca | kalikiana: c-lobrano: you know about os-release-zoo? | 14:32 |
| kalikiana | Chipaca: What's that? | 14:33 |
| Chipaca | kalikiana: like an animal zoo, but of os-release files | 14:33 |
| Chipaca | kalikiana: https://github.com/zyga/os-release-zoo | 14:33 |
| kalikiana | Oh, neat | 14:34 |
| kalikiana | MAybe this one https://github.com/zyga/os-release-zoo/blob/master/elementary/elementary-0.4.txt works for this test | 14:34 |
| Chipaca | kalikiana: note that one is wrong | 14:35 |
| Chipaca | as in, it's what they shipped, but it's invalid | 14:35 |
| Chipaca | they have since fixed it (i think0 | 14:35 |
| Chipaca | ) | 14:35 |
| === anewman_ is now known as anewman | ||
| kalikiana | Ah, it has the invalid ID. There was even a snapcraft bug about it | 14:36 |
| Chipaca | :-) | 14:36 |
| * ikey sometimes thinks os-release needs an UPDATE_MECHANISM field to properly describe the core architecture | 14:37 | |
| Chipaca | ikey: also a SUCKS_LIKE field | 14:37 |
| Chipaca | IS_AT_LEAST_AS_BAD_AS=... | 14:37 |
| ikey | lol | 14:38 |
| c-lobrano | kalikiana: I think you're right. I'm not familiar with os-release-zoo | 14:42 |
| zyga-ubuntu | c-lobrano: hey | 14:42 |
| zyga-ubuntu | c-lobrano: github.com/zyga/os-release-zoo | 14:42 |
| pstolowski | cachio_, it failed for me with snap_mode not defined again, http://pastebin.ubuntu.com/25759787/ | 14:42 |
| pstolowski | mvo, ^ | 14:42 |
| c-lobrano | hey zyga-ubuntu, thank you, I'll look into it | 14:43 |
| pstolowski | cachio_, my versions: http://pastebin.ubuntu.com/25759794/ | 14:43 |
| pstolowski | cachio_, how about yours? | 14:44 |
| cachio_ | pstolowski, one min please | 14:45 |
| cachio_ | flasing the new one | 14:45 |
| cachio_ | pstolowski, did you use the ubuntu-image snap? | 14:48 |
| pstolowski | cachio_, yes | 14:48 |
| cachio_ | pstolowski, https://paste.ubuntu.com/25759837/ | 14:52 |
| cachio_ | this is mine | 14:52 |
| cachio_ | flashed with deb ubuntu image | 14:52 |
| cachio_ | the only diff is the rev for the core | 14:52 |
| cachio_ | pstolowski, I am gonna run the test now | 14:53 |
| elopio | sorry for not replying kyrofa, I spent too much time fixing my wifi yesterday | 14:54 |
| pstolowski | cachio_, why is it different? | 14:54 |
| ogra_ | cachio_, please check if there is actually any corruption by running fw_printenv manuallly after the test, we found yesterday that this actually works and there might be just an issue how fw_printenv is used in the test or a bug in fw_printenv itself but no actual corruption of uboot.env or the vfat ... | 14:55 |
| kyrofa | elopio, quite alright. Things working better today? | 14:55 |
| elopio | kyrofa: docker will speed things, we can go back to it. However, the problem we had was that nobody is developing in docker, so it was hard to reproduce the errors. | 14:55 |
| elopio | also, we can't install snaps. | 14:55 |
| ogra_ | cachio_, all manual runs of fw_printenv returned proper results yesterday even if the test failed | 14:55 |
| cachio_ | ogra_, ok | 14:55 |
| kyrofa | elopio, yeah I was mostly meaning for normal units/integrations | 14:55 |
| kyrofa | But if there are weird failures there, yeah that would explain it | 14:56 |
| elopio | kyrofa: if we publish a snap before running the integration tests, there will be no deps to install. | 14:56 |
| kyrofa | Very true | 14:56 |
| kyrofa | elopio, but again: talking about unit tests and stuff | 14:57 |
| elopio | kyrofa: I'm not worried about unit, but I have no problem moving those to docker. | 14:57 |
| kyrofa | elopio, yeah I really just mean as an overall speedup step | 14:57 |
| pstolowski | cachio_, please paste your error if it hppens again | 14:57 |
| elopio | kyrofa: we still have the docker scripts around, because I didn't get a chance to move the CLA to lxc. My plan was to have everything consistent in lxc, but we can go the other way, no big arguments from me. | 14:59 |
| cachio_ | pstolowski, it works when I flash with the deb }ubuntu-image | 15:00 |
| kyrofa | elopio, I have no strong feelings. We all know lxd better. I was just thinking from a speed perspective | 15:00 |
| cachio_ | did you run the test with the image flashed with the snap ubuntu-image? | 15:00 |
| kyrofa | Not sure it's worth it | 15:00 |
| cachio_ | mvo, when I use an image flashing with the deb ubuntu-image the tst pass, when I use the snap ubuntu-image the test fails | 15:01 |
| cachio_ | mvo, interesting | 15:02 |
| cachio_ | ogra_, also for you | 15:02 |
| elopio | kyrofa: would it make sense to explore having a persistent lxc container and caching it? | 15:02 |
| kyrofa | elopio, caching it... in lxc? | 15:02 |
| kyrofa | Ugh, in s3 I mean, sorry | 15:02 |
| kyrofa | Not awake yet | 15:02 |
| elopio | caching it in travis | 15:02 |
| kyrofa | How would that work? | 15:02 |
| ogra_ | cachio_, hmm, has the deb even been updated sinc ethe snap exists ? | 15:03 |
| ogra_ | also ... the deb requires you to use the foundations PPA for it to get the ext4libs version that make you not require sudo | 15:03 |
| ogra_ | though neither should have any influence here | 15:04 |
| cachio_ | I ran with sudo | 15:04 |
| kalikiana | elopio: Where would the container be created/ destroyed in that case? | 15:04 |
| cachio_ | ogra_, is it a problem? | 15:04 |
| ogra_ | well, it is a difference ... :) | 15:04 |
| mvo | cachio_: yay | 15:05 |
| ogra_ | the version differemce might/could be a prob though | 15:05 |
| mvo | cachio_: that is awesome news, we have a smoking gun now | 15:05 |
| pstolowski | mvo, cachio_ well, it doesn't match my results | 15:05 |
| mvo | cachio_: I bet its the embedded mtools (or whatever vfat tools) inside the snap then | 15:05 |
| mvo | pstolowski: what do you get? | 15:05 |
| pstolowski | mvo, http://pastebin.ubuntu.com/25759787/ | 15:06 |
| pstolowski | mvo, it's from a few moments ago, i flashed with ubuntu-image from the snap (yesterday I was using ubuntu-image from the deb) | 15:06 |
| ogra_ | pstolowski, ubuntu-image deb or snap ? (and did you use sudo or not) | 15:06 |
| ogra_ | aha | 15:07 |
| ogra_ | so a smoking red herring then :P not a gun ... | 15:07 |
| cachio_ | ogra_, I always used sudo | 15:07 |
| pstolowski | ogra_, yes I used sudo | 15:07 |
| ogra_ | wwith the snap you shouldnt need to ... | 15:07 |
| ogra_ | and with the deb, only if you dont use the PPA | 15:07 |
| pstolowski | ogra_, but no harm either way? | 15:08 |
| ogra_ | theoretically not | 15:08 |
| ogra_ | practically ... i dont know :) | 15:08 |
| mvo | pstolowski: well, its the EOF again, thats slightly different than the error from cachio_ | 15:09 |
| mvo | pstolowski: still interessting and something I would love to figure out why the connection is broken | 15:09 |
| * kalikiana going to step out for a bit, to find some food | 15:09 | |
| pstolowski | mvo, but first and foremost, it's snap_try_core and snap_mode not defined again, right? | 15:10 |
| mvo | pstolowski: it will get cleared after a successful boot, so its ok if you don't see it | 15:10 |
| mvo | pstolowski, cachio_ I need to interrupt your testing with 2.28.5 and push 2.28.1 with a wpa fix to beta now | 15:12 |
| cachio_ | mvo, np | 15:13 |
| cachio_ | should I validate it now? | 15:13 |
| kyrofa | Yikes... using github to update branches is not working | 15:15 |
| kyrofa | Something is broken here | 15:16 |
| mvo | cachio_: yes please, once its ready, I'm uploading right now | 15:16 |
| kyrofa | It actually does the merge, but doesn't update the PR or tests | 15:17 |
| cachio_ | mvo, I'll have lunch now in that case | 15:18 |
| mvo | cachio_: sure | 15:18 |
| mvo | cachio_: enjoy! | 15:18 |
| cachio_ | mvo, and I'll create the images with the deb ubuntu-image then :) | 15:18 |
| mvo | cachio_: \o/ | 15:19 |
| kyrofa | Meh. "We continue to investigate a queue backlog. You may experience that commits take longer than usual to appear in pull requests." | 15:21 |
| mup | PR snapcraft#1624 opened: kernel plugin: use latest stable core snap <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapcraft/pull/1624> | 15:26 |
| elopio | kyrofa, kalikiana: I don't know, just an idea that I would have to try. Maybe putting /var/snap/lxd in the cache, or something like that. | 15:27 |
| kyrofa | elopio, wait... I thought the cache required s3? | 15:28 |
| kyrofa | Maybe I'm mixing wires with other conversations we've had | 15:28 |
| elopio | kyrofa: you are talking about sharing files between stages. For that, they recommend not to use the cache, and use something external. | 15:30 |
| kyrofa | elopio, oh interesting. Wouldn't that be what we're doing if we cache lxd, though? | 15:30 |
| elopio | we want to share the snap between stages, it might be worth asking why they are recommending that. | 15:31 |
| elopio | yes. They also recommend not to cache images :) | 15:31 |
| elopio | but if there is no good reason, we can just ignore the recommendation. | 15:31 |
| kyrofa | Huh | 15:33 |
| ogra_ | ppisati, sergiusens ... what is this ? https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/kernel.py#L456 ... why was the kernel plugin not switched to download core ? | 15:41 |
| ogra_ | (ubuntu-core has not been built since severeal months, all initrd scripts in there are definitely massively outdated) | 15:41 |
| mvo | cachio_: new beta core ready for testing, this is a cve fix, so feel free to bump to candidate as soon as we get ok from CE and we should also push to stable as QA allows | 15:42 |
| abeato | ppisati, sergiusens FTR: https://github.com/snapcore/snapcraft/pull/1624 | 15:44 |
| mup | PR snapcraft#1624: kernel plugin: use latest stable core snap <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapcraft/pull/1624> | 15:44 |
| cwayne | mvo: cert tests are under way, we'll keep an eye out and let you know as soon as they're ready | 15:52 |
| mvo | cwayne: \o/ | 15:55 |
| mvo | cwayne: thank you, this is very important so I appreciate it | 15:55 |
| ppisati | ogra_: i don't know, maybe when the rename 's/ubuntu-core/core/' was done they forget to check every plugin? | 16:12 |
| ogra_ | heh, well, kernel is the only plugin that downloads core ... | 16:12 |
| ogra_ | i dont get how we didnt notice this though | 16:12 |
| ogra_ | doesnt it print "downloading ubuntu-core" somewhere when it does that ? | 16:13 |
| ppisati | uhm | 16:14 |
| ogra_ | it snt *that* bad given that all official kernel snaps re-pack the deb anyway ... but people building their own kernels miss the last fixes in the initrd scripts | 16:16 |
| kalikiana | elopio: Do you know if I can mock.patch for an entire module? I'm trying to patch check_open which is used in different files - and I don't want to have several mocks for all of them | 16:32 |
| elopio | kalikiana: yes, just use the path to the module they are all importing | 16:39 |
| kalikiana | elopio: That's what I tried... it's telling me the functions don't exist | 16:39 |
| kalikiana | elopio: This is how I'm specifying it `snapcraft.internal.lxd.sleep` | 16:49 |
| kalikiana | lxd is the folder containing __init__.py | 16:49 |
| elopio | kalikiana: are you importing snapcraft.internal.lxd in the test file? | 16:52 |
| kalikiana | elopio: No | 16:52 |
| kalikiana | elopio: even with that, I'm getting `AttributeError: <module 'snapcraft.internal.lxd' from '~/bau/snapcraft/snapcraft/internal/lxd/__init__.py'> does not have the attribute 'check_call'` | 16:54 |
| kalikiana | It seems to be looking in __init__.py, not inside the module where it's being used | 16:55 |
| kalikiana | elopio: I'm guessing I'd have to import those functions in __init__.py then, rather than the individual files | 16:57 |
| cachio_ | cwayne, are you already testing 2.28.5 with the wpa fix? | 17:10 |
| kalikiana | elopio: Well, doesn't seem like I can. I can't use functions from __init__.py in the other files | 17:10 |
| cwayne | cachio_: if that's the core in beta currently, yes | 17:11 |
| cachio_ | cwayne, perfect | 17:12 |
| cachio_ | please tell me once it is ready | 17:12 |
| cwayne | cachio_: thats rev 3242 right? | 17:12 |
| cachio_ | cwayne, 3247 | 17:14 |
| elopio | kalikiana: I'm confused, because you are talking about sleep, check_call and check_open. Not sure which one you are trying to mock. If it's sleep, just import time and mock.patch('time.sleep') | 17:14 |
| kalikiana | elopio: Yes. And right now all of these are imported individually | 17:15 |
| cwayne | cachio_: ah, were there two pushes to beta today? | 17:15 |
| cachio_ | cwayne, yes | 17:15 |
| cwayne | ok, it's ongoing | 17:15 |
| cachio_ | cwayne, the last is the valid one | 17:15 |
| cwayne | cachio_: ack, some systems were still running on 3241, we'll cancel and start up 3247 on those now | 17:20 |
| kyrofa | snappy-m-o, autopkgtest 1603 artful:amd64 xenial:arm64 xenial:armhf zesty:arm64 | 17:22 |
| snappy-m-o | kyrofa: I've just triggered your test. | 17:23 |
| kyrofa | You're the best | 17:23 |
| cachio_ | cwayne, great, thanks | 17:23 |
| mup | PR snapcraft#1625 opened: tests: use the snapcraft snap for integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1625> | 17:24 |
| === JoshStrobl is now known as JoshStrobl|AFK | ||
| ackk | uhm, https://travis-ci.org/snapcore/snapcraft/jobs/289097568 has a weird error | 17:31 |
| kalikiana | elopio: Alright, will see how far I get by not importing these by name. Already hit `open` not working. So that one I have to mock for the individual file, otherwise it silently fails | 17:32 |
| ackk | kyrofa, ^ beside that one, other tests on my PR are green | 17:32 |
| kyrofa | ackk, unfortunately, the other tests didn't even run due to that failure :P . I've poked it | 17:40 |
| ackk | kyrofa, thanks | 17:40 |
| kenvandine | nessita, i'm getting a 401 error trying to download a snap from the edge channel | 18:07 |
| kenvandine | - Download snap "gnome-taquin" (8) from channel "edge" (received an unexpected http response code (401) when trying to download https://api.snapcraft.io/api/v1/snaps/download/pyEMtK4uVBGIvCV2B1NHC1sb3c2bL7x6_8.snap) | 18:07 |
| kenvandine | nessita, is that something you can help with? | 18:07 |
| kenvandine | we saw this before with the same package, i released it to stable and it worked | 18:08 |
| kenvandine | but now there's a new revision in edge and seeing the same thing again | 18:08 |
| kenvandine | popey, ^^ it happened again, same package | 18:08 |
| * sergiusens is always annoyed by our unittests requiring hg, svn and bzr | 18:23 | |
| mup | PR snapcraft#1626 opened: lifecycle: split into its own package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1626> | 18:33 |
| nessita | kenvandine, checking | 18:38 |
| nessita | kenvandine, what arch? | 18:39 |
| kenvandine | amd64 | 18:39 |
| nessita | kenvandine, are you logged in? (is not a requirement but if you are is a different debug path) | 18:40 |
| kenvandine | nessita, yes and no :) | 18:40 |
| nessita | in other words, what command were you executing? | 18:40 |
| kenvandine | i've tried it both ways | 18:40 |
| kenvandine | sudo snap install --edge gnome-taquin | 18:40 |
| kenvandine | a wget of the url fails too | 18:41 |
| kenvandine | popey had tried that last time it happened | 18:41 |
| nessita | kenvandine, let me involve more relevant people then | 18:41 |
| kenvandine | cool | 18:41 |
| * kenvandine wasn't sure who to bug | 18:41 | |
| nessita | cprov, hi hi | 18:41 |
| nessita | cprov, so "sudo snap install --edge gnome-taquin" is failing with - Download snap "gnome-taquin" (8) from channel "edge" (received an unexpected http response code (401) when trying to download https://api.snapcraft.io/api/v1/snaps/download/pyEMtK4uVBGIvCV2B1NHC1sb3c2bL7x6_8.snap) | 18:41 |
| kenvandine | last time i released it to another channel and it was fine in the other channel | 18:42 |
| nessita | cprov, I've checked and the snap is public and released to edge for revision 8 | 18:42 |
| kenvandine | now that i rebuilt the snap in edge it happens again | 18:42 |
| popey | works for me | 18:42 |
| popey | i am logged into the store tho | 18:42 |
| nessita | popey, what snapd are you running? | 18:42 |
| kenvandine | oh right... you are special though :) | 18:42 |
| kenvandine | that's right | 18:42 |
| popey | 2.28.5 | 18:42 |
| popey | oh, also, I am special | 18:42 |
| kenvandine | doesn't work for my login and not logged in | 18:43 |
| kenvandine | popey, remember we debugged this before ;) | 18:43 |
| nessita | popey, so you are on beta for snapd? | 18:43 |
| kenvandine | nessita, we ruled out snapd versions last time | 18:43 |
| kenvandine | it was his login | 18:43 |
| kenvandine | if popey logs out it fails for him too | 18:43 |
| nessita | popey, you are a reviewer, so that may be giving you special access | 18:43 |
| kenvandine | right | 18:43 |
| popey | i am tracking beta for core, yes | 18:44 |
| popey | because reasons | 18:44 |
| popey | confirmed I get 401 from another (not logged in, snap 2.28.1) machine | 18:45 |
| mup | PR snapd#3954 closed: snap: introduce structured epochs <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3954> | 18:45 |
| cprov | nessita: yup, 401 comes from SCA, I will look in a bit | 18:46 |
| kenvandine | cprov, thx | 18:47 |
| nessita | cprov, if I login it works, and I'm guessing that's because I'm a reviewer, but I thought we killed all privileges for reviewers when downloading outside dashboard | 18:49 |
| === JoshStrobl|AFK is now known as JoshStrobl | ||
| cprov | nessita: right, works when I am logged in | 18:51 |
| kenvandine | i can download the snap via the browser | 18:53 |
| nessita | kenvandine, what do you mean? | 18:57 |
| nessita | kenvandine, from the dashboard site while logged in as you? | 18:57 |
| mup | PR snapcraft#1627 opened: lxd: split container classes into different files <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1627> | 18:57 |
| nessita | what's the link you used in the browser? | 18:57 |
| kenvandine | dashboard logged in | 18:58 |
| nessita | cprov, so the above indicates that only publishers and reviewers are being able to download, not other users | 18:59 |
| kenvandine | oh, actually i can install it when logged in | 19:01 |
| kenvandine | but i can't when not logged in | 19:01 |
| kyrofa | nessita, isn't that by design? | 19:02 |
| kenvandine | i can install from the stable channel when not logged in | 19:02 |
| kenvandine | but only for this snap | 19:02 |
| kenvandine | weird... scratch that... i can't install from stable either when not logged in | 19:04 |
| * kenvandine could have sworn i could | 19:04 | |
| nessita | kenvandine, but the issue was with edge, no? | 19:05 |
| kenvandine | was... but it exists with stable too it seems | 19:05 |
| kenvandine | when not logged in | 19:05 |
| kenvandine | nessita, i noticed there is a distribution blacklist | 19:05 |
| kenvandine | that lists like all the countries | 19:05 |
| * kenvandine hasn't seen that before | 19:06 | |
| nessita | gah did I miss checking for country restrictins? | 19:06 |
| kalikiana | elopio: I was successful with not importing by name in the end :-D You'll see the result in my new PR | 19:06 |
| kenvandine | nah, it says no restrictions | 19:07 |
| kalikiana | Now time to wrap up for today | 19:07 |
| kenvandine | nessita, if i edit that it gives me a huge list of course | 19:07 |
| kenvandine | to select form | 19:07 |
| kenvandine | from | 19:07 |
| nessita | kenvandine, I don't see any restrictions set | 19:07 |
| nessita | kenvandine, as in the whitelist and blacklist are not defined, so that means all countries can access | 19:07 |
| kenvandine | package is public too | 19:07 |
| kenvandine | yeah | 19:07 |
| cprov | nessita: snapident & revs data match what I see in dashboard (public, not country_black/white lists and released at least once) | 19:11 |
| nessita | cprov, so revision 8 is shown as published in the channel map? | 19:18 |
| cprov | nessita: yes, released | 2017-10-17 17:28:31.979241 | 19:20 |
| mup | Issue snapcraft#1628 opened: record lxc image used <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1628> | 19:24 |
| kyrofa | What the heck is wrong with Travis. We're getting all sorts of errors that we didn't get before | 19:46 |
| kyrofa | BlockingIOErrors, address space conflicts | 19:46 |
| kyrofa | kalikiana, elopio we're getting container-related autopkgtest failures: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-snapcraft-daily/artful/amd64/s/snapcraft/20171017_173440_d185c@/log.gz | 19:49 |
| kyrofa | It looks valid, the raw.idmap assertion looks wrong | 19:49 |
| kyrofa | At least, it's obviously different than what we expect | 19:49 |
| elopio | both 1000 0/both 1234 0 Hum, this seems related to the change kalikiana did for running with sudo | 19:51 |
| mup | PR snapcraft#1622 closed: schema: sync patterns with snapd <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1622> | 19:51 |
| sergiusens | elopio how about retriggering adt for snapcraft#1602 ? | 19:51 |
| mup | PR snapcraft#1602: tests: add the slow tag for ros snapd integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1602> | 19:51 |
| sergiusens | elopio and what I mean about error prone is that in setUp I change the value we can easily confuse the whole thing. The text should say something like "add it as a class attribute" | 19:52 |
| kyrofa | sergiusens, that's the one I'm whining about now. Doesn't look like a retrigger will succeed | 19:54 |
| kyrofa | Actually I'm whining about its prereq | 19:54 |
| sergiusens | kyrofa which one is the prereq? | 19:55 |
| kyrofa | elopio, note that xenial amd64 passed, and is the only amd64 I ran | 19:55 |
| kyrofa | sergiusens, snapcraft#1603 | 19:55 |
| mup | PR snapcraft#1603: tests: add /snap/bin to PATH in autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1603> | 19:55 |
| sergiusens | kyrofa the github side of it worked fine | 19:56 |
| sergiusens | kyrofa the adts of it all failed though | 19:56 |
| elopio | sergiusens: I updated the wording. Please let me know if it's better now. | 19:56 |
| kyrofa | sergiusens, indeed | 19:56 |
| kyrofa | elopio, oh wait... what. Maybe I lied. github is still weird right now, the amd64 run disappeared | 19:58 |
| kyrofa | Oh, no, it failed as well | 19:58 |
| kyrofa | I think that was an artifact from the previous run. This is really bad today | 19:58 |
| elopio | well, it's clear there's an issue in that test. It mocks getuid, and returns the wrong value. | 19:58 |
| kyrofa | elopio, and it looks like it fails everywhere | 19:59 |
| kyrofa | Obvious fix? Or would you like me to investigate? | 19:59 |
| kyrofa | I think we should focus on getting autopkgtests to pass until they do :P | 19:59 |
| elopio | kyrofa: obvious fix is to also patch SUDO_UID | 20:01 |
| kyrofa | elopio, wait... these are unit failures. Why aren't they failing on travis? | 20:06 |
| kyrofa | (or locally) | 20:06 |
| kyrofa | Because they run as root in autopkgtest? | 20:06 |
| elopio | because we don't run with SUDO maybe? | 20:08 |
| elopio | I don't like this test :/ | 20:08 |
| kyrofa | Ah, indeed, SUDO_UID I see what you're saying now | 20:09 |
| cwayne | cachio_: looks good so far, waiting on a few more devices | 20:09 |
| cachio_ | cwayne, great, here also looks promising | 20:10 |
| cachio_ | just known issues | 20:10 |
| kyrofa | sergiusens, pre/post stanzas: are you thinking we'll have those around stage/prime as well? | 20:20 |
| mup | PR snapcraft#1629 opened: lxd: fix the unit test for the ser id map <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1629> | 20:21 |
| elopio | what do you kyrofa? snapcraft#1629 | 20:21 |
| mup | PR snapcraft#1629: lxd: fix the unit test for the ser id map <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1629> | 20:21 |
| kyrofa | elopio, I'd prefer to see it testing that SUDO_UID actually takes precedence | 20:22 |
| kyrofa | elopio, i.e. make them different values | 20:22 |
| kyrofa | And have an "expected" in the scenario | 20:23 |
| kyrofa | Thoughts? | 20:23 |
| kyrofa | sergiusens, also, do you intend them to include a third stanza that replaces the plugin's? e.g. pre-pull, pull, and post-pull? | 20:25 |
| elopio | kyrofa: please refresh the diff and see if you like it better. | 20:27 |
| kyrofa | elopio, much better, but I'd also like to see a third case where they're both set and SUDO_UID is used instead of getuid | 20:28 |
| kyrofa | Thoughts? | 20:29 |
| kyrofa | I feel like that precedence is probably important behavior to preserve | 20:29 |
| elopio | you are right. | 20:33 |
| elopio | I don't like this test, so I was trying to not touch it a lot. But well, that's a small change. | 20:34 |
| kyrofa | Hahaha | 20:34 |
| kyrofa | Go wash your hands after | 20:34 |
| elopio | hum, no kyrofa, this third test would be a duplicate. On the first one, the env var is set, and os.getuid is not called. | 20:36 |
| kyrofa | elopio, are we testing for that? Or could the test also pass if it tried to call os.getuid first, got None, and fell back to SUDO_UID? | 20:37 |
| elopio | on the second one, the env var is not set, and os.getuid is called. This third test is the same as the first one. I just set the os.getuid return value as None, to make it clearer. But apparently, it's not :p | 20:37 |
| kyrofa | I suppose getting None from getuid would be odd | 20:38 |
| kyrofa | elopio, works for me | 20:38 |
| elopio | well, I can replace getuid None for a value. | 20:39 |
| kyrofa | elopio, doesn't matter too much. I agree with you | 20:39 |
| elopio | snappy-m-o autopkgtest 1629 xenial:amd64 | 21:08 |
| snappy-m-o | elopio: I've just triggered your test. | 21:08 |
| cwayne | cachio_: so the only change in this core is the krack fix right? | 22:13 |
| cachio_ | cwayne, there are few changes compared with 28.4 | 22:14 |
| cachio_ | but the diff with the previous 28.5 is just the fix | 22:14 |
| cwayne | cachio_: shouldn't we have done just 2.28.1+krack fix since that's what's in stable today? | 22:21 |
| cachio_ | cwayne, that was the original idea, but it was also needed to add some other important fixes that are included in the 2.28.5 such as the fix for machines with nvidia drivers | 22:22 |
| cachio_ | cwayne, so it was decided to go with the 2.28.5 | 22:22 |
| cachio_ | cwayne, so far everything working properly on my side | 22:23 |
| cachio_ | cwayne, how is it going in your side? | 22:23 |
| cwayne | cachio_: either way, it looks like we're having some issues with the last device (unrelated to core), so I think in interest of speediness, we can push 3247 to candidate | 22:24 |
| cwayne | everything looks pretty normal here, just waiting on that last device (been having problems with the hw lately) | 22:24 |
| cachio_ | cwayne, ok, which device is it? | 22:25 |
| elopio | snappy-m-o autopkgtest 1629 xenial:amd64 | 23:09 |
| snappy-m-o | elopio: I've just triggered your test. | 23:09 |
| mwhudson | how do you guys test that snap updates work correctly? | 23:37 |
| mwhudson | i have a bug where the snap being updated breaks things :/ | 23:38 |
| mwhudson | oh revert i guess | 23:38 |
| kyrofa | mwhudson, it depends on the snap. I use capistrano for Nextcloud | 23:44 |
| kyrofa | *sigh* I mean capybara. Man what is the deal today | 23:45 |
| kyrofa | mwhudson, and manual testing-- install the stable version, then test refreshing to candidate | 23:46 |
| mwhudson | whoa snap revert blew up in an exciting way | 23:49 |
| mwhudson | i think that's probably the overlayfs fun and games | 23:50 |
| kyrofa | mwhudson, overlayfs? Do I wanna know? | 23:58 |
| mwhudson | kyrofa: the snap i'm working on is subiquity, the server installer | 23:59 |
| mwhudson | it runs out of a livecd environment so everything is strange :) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!