[00:13] src/gopkg.in/mgo.v2/bson/json.go:320:7: constant 9007199254740992 overflows int [00:13] grumble [00:15] also the arch=all build failed [00:44] PR snapcraft#1851 opened: storeapi: add docstrings to _client [05:50] PR snapcraft#1835 closed: Update _desktop.py [06:08] morning [07:40] good morning! [07:41] * zyga feels much better today, maybe the weather is changing [07:59] zyga: morning [07:59] o/ [07:59] morning [08:05] hey kalikiana, mvo [08:11] hey zyga - good morning [08:17] mvo: morning [08:18] finally openend a PR with diff output in go-check: https://github.com/go-check/check/pull/99 [08:18] PR go-check/check#99: many: return diff of stringified value when Equals/DeepEquals check fails [08:19] ohhh [08:19] * zyga hugs mborzecki! [08:20] mborzecki: hey, good morning! this looks great [08:31] * zyga goes to reboot [09:10] mborzecki: curious, did you investigate using github.com/kr/pretty ? or is that inferior/unsuited for pr (iirc we talked about this briefly) [09:22] mvo: i tried it in hope i could drop difflib, but the Diff() that's in kr/pretty is not what i wanted [09:28] mborzecki: thanks, was just curious [09:31] mvo: I'm getting errors preparing Fedora 26 all the time but the log is not clear what is failing [09:31] https://travis-ci.org/snapcore/snapd/builds/325038662?utm_source=github_status&utm_medium=notification [09:33] it seems to fail installing our own built packages, but there's no error in the log [09:35] mvo: example output http://paste.ubuntu.com/26324546/ with this code: http://paste.ubuntu.com/26324547/ [09:36] mvo: master is red in the same way [09:36] did we break something on fedora ? [09:37] mmh, it's fedora preparing just taking too long? [09:38] pedronis: I don't know, I have not checked yet but noticed as well that something is not right [09:43] no, it's failing after 239s that should be below the timeouts [09:44] we already have 25 and suse on manual :( [09:47] * kalikiana need..more..coffee [10:01] pedronis: I run spread against fedora now with -debug maybe that gives me a clue [10:03] ok, I'm turning it into manual in my branch for now but will make a PR that puts it back === __chip__ is now known as Chipaca [10:11] morning! is there something wrong with fedora 26 in linode? getting failed prepares [10:12] Chipaca: yes, but its unclear what [10:12] :-( [10:12] Chipaca: it seems like dnf -q ... fails but it does not tell why [10:12] (maybe because of the -q ?) [10:12] i'll do a manual run and see [10:13] Chipaca: I am in one right now, what I see is "dnf -q -y --refresh install glibc-static" apparently failed [10:13] ah ok [10:14] mvo: network/repo issues? [10:14] Chipaca: I repeated the commmand manually and it worked :/ [10:15] Chipaca: also dnf history will not show me unsuccessful runs so I don't know why the previous one failed [10:15] Chipaca: I guess we need to replace "dnf -q" with "quiet dnf" to get useful debug output [10:16] mvo: +1 [10:23] it might be (wild guess) that the fedora repo is a bit overloaded due to the extra security updates pushing out for meltdown/spectre [10:24] PR snapd#4444 opened: tests: use "quiet" helper instead of "dnf -q" to get errors on failures [10:32] PR snapd#4392 closed: many: refresh with appropriate creds [10:32] well that doesn't tell me much [10:33] Chipaca: ? [10:33] Error: Failed to synchronize cache for repo 'updates' [10:33] is the entirety of dnf's output [10:33] we have seen it before though [10:33] it's a clasic [10:33] classic [10:38] darn, is there no way to have a mock variable for a recursive function? [10:38] var func := impl [10:38] and then call func inside impl (indirectly here) [10:38] Chipaca: well, its much better than seeing nothing :) [10:38] mvo: yeah [10:39] zyga: ? [10:39] mvo: not much >> nothing [10:39] you need a wrapper [10:39] mvo: guess it's one more time to jump into OFTC [10:39] Chipaca: and something that we can google for [10:39] zyga: I'm in oftc, how does that help ;)? [10:40] mvo: best answer i found so far is that we need to do 'dnf clean all' at the start [10:40] meh [10:40] mvo: i'm going to test that [10:40] mvo: go to #linode and complain [10:40] mvo: that their repo is periodically broken [10:40] zyga: oh? it could be their mirror? fwiw, it seems like it is not always broken, I just have a run that seems to be doing fine [10:41] yes, it is their internal mirror [10:41] as neal suspected is is probably failing while it syncs to the outer mirror [10:41] because it is removing files before, not after rsync is done [10:41] so you can see partially broken mirror at that time [10:42] maybe time to update their mirror script then? [10:42] ubuntu fixed this a long time ago (to be fair it was a problem for a long time too) [10:42] zyga: you are hitting an initialisation loop [10:43] pedronis: yes [10:43] ../../../go/src/github.com/snapcore/snapd/cmd/snap-update-ns/change.go:85: initialization loop: [10:43] ... bunch of calls [10:43] I recommend just being naive [10:43] have a impl that calls implRec that calls itself or something [10:46] unless you really need the partial mocking, in which a func init() might help [10:46] *which case [10:48] * zyga experiments [10:48] mvo: part of the problem is that we do a dnf call per package, and any one of them can fail this way [10:48] mvo: i'll see if i can resurface my branch that avoids this [10:48] Chipaca: ok [10:49] zyga: these works: https://play.golang.org/p/uihgox8C_RU [10:50] pedronis: thank you! [10:52] yep, that works for me [11:03] PR snapd#4445 opened: tests: make less calls to the package manager [11:10] i get an error when trying to install the maas snap in a bionic container. any ideas on what's wrong? https://paste.ubuntu.com/26325056/ [11:11] BjornT_: any denials? [11:13] mvo: zyga: do you guys push core to staging, or is that somebody else? [11:14] no idea about staging [11:14] (staging store I assume) [11:15] Chipaca: staging store ? I'm not familiar with the workflow, cachio is [11:16] ah [11:17] Facu: ^ so … the person that could do it is still on holidays i think [11:17] Chipaca, ack, thanks [11:17] Facu: but when he gets back, let's make updating staging part of the release workflow [11:17] Facu: (remind me?) [11:17] Facu: (or talk to him! i ain't a manager :-p ) [11:18] Chipaca, :) [11:19] zyga: not that i can see. this is 'journalctl -xe': https://paste.ubuntu.com/26325079/ [11:19] Chipaca: fun! pr#4444 [11:19] (its just a number but still fun) [11:21] mvo: you probably want to merge master into pr#4444 and remove the manual I just added to spread.yaml [11:23] mvo: #4445 is more fun :-p [11:23] PR #4445: tests: make less calls to the package manager [11:25] mvo: why isnt 4445 even allocating a fedora? :-/ [11:26] Chipaca: yeah, was just reviewing this one [11:28] mvo: the review of that one gets a lot easier if you add ?w=1 to the url [11:28] ('ignore whitespace') [11:33] BjornT_: that doesn't ring any bells, sorry :/ [11:36] Chipaca: I turned fedora to manual in my PR to be able to land it fwiw [11:37] PR snapcraft#1811 closed: Add type hints cli/assertions.py module [11:37] PR snapcraft#1851 closed: storeapi: add docstrings to _client [11:37] pedronis: o\ [11:37] pedronis: that would explain the lack of fedora in 4445 :-) [11:37] Chipaca: you and mvo probably need to turn it on again on your PRs [11:37] * pedronis lunch [11:38] pedronis: ohhh, ok [11:47] Bug #1741463 opened: Failure to install maas snap in a bionic container [11:48] zyga: ok, i filed a bug about it: ^^^ [11:49] PR snapd#4446 opened: snap: use stdout instead of stderr for "fetching" message [11:50] BjornT_: thanks [11:52] hi, does anyone know what could be causing this error: https://paste.ubuntu.com/ ? [11:52] err [11:52] https://paste.ubuntu.com/26325221/ [11:52] ackk: #1741463 [11:52] Bug #1741463: Failure to install maas snap in a bionic container [11:53] Chipaca, this is a different error, though? [11:54] ackk: ah, perhaps [11:56] this is in a bionic container, and the snap was built on bionic [11:56] ackk: that error looks like the maas snap has been built on the wrong libc [11:56] ackk: do not build snaps on non-xenial unless you really know why you're doing it [11:56] ackk: your snap is now trying to use bionic libc, which isn't available to it [11:56] bah, not sure if this is your snap -- the maas snap, i mean [11:57] Chipaca, isn't there a bionic-based core image? [11:57] ackk: no [11:57] ackk: there will be, once 18.04 is out [11:58] Chipaca, not even a daily build? [11:58] ackk: no, because lots of stuff is missing, we want to make some things different, not just refreshed [11:59] ackk: I think you will see 18.04 base snaps sooner but not meant for booting [11:59] in fact mvo did some work on that in December [12:00] ackk: when we get it working it'll be a Big Deal and announced in all the usual ways [12:00] I see [12:00] ackk: you're welcome to work on a 18.04 base if you want to thuogh [12:00] Chipaca, how do I install it? [12:00] ackk: sorry, by 'work on' i meant 'create one' [12:00] ah :) [12:01] ackk: why do you need 18.04 libc? [12:01] ackk: doesn't maas work on pre-18.04? [12:01] Chipaca, yes, but master just switched to bionic, so we're now building stuff on bionic [12:02] Chipaca: there is a very premature one [12:02] ackk: snapd does not yet support that; I'd disrecommend doing so until we do [12:02] snapcore/base-18 AFAIR [12:02] but super early stuff [12:03] zyga: not a public snap fwiw [12:03] public just not done [12:03] it's on github ;) [12:03] zyga: ah :-) [12:03] https://github.com/snapcore/base-18 [12:03] right [12:04] still, not supported, and i wouldn't recommend it at all [12:04] yes [12:04] agreed [12:04] unless you really want to work on _that_ and not the thing you're working on [12:04] ok, thanks for the info [12:04] totally [12:04] if it were easy it'd be done :-D [12:05] ackk: we have some code for base-18, if you don't mind that things break I can push what we have to edge [12:05] ackk: is our WIP branch https://github.com/snapcore/base-18 [12:05] aha, zyga said it already, sorry for the noise [12:15] mvo, so, if you push that base to edge, installing a bionic-built snap should work, right? [12:15] well [12:15] how do you build that bionic-based snap? [12:15] snapcraft probably cant because there's no real base 18 yet [12:15] so ... ? [12:16] it does build [12:16] on bionic itself [12:16] yes [12:16] but then it looks at the core snap to resolve libs and whatnot [12:16] and there's no base 18 to do that [12:16] so something is wrong at the build stage already [12:18] zyga, where does it look for the core snap? [12:18] ackk: to resolve libs and dependencies [12:18] ackk: kalikiana would know more [12:18] zyga, no I mean where does it look it up [12:18] locally or does it download it ? [12:19] ackk: it downloads core snap AFAIK [12:19] but I really don't know [12:26] ackk: you will need to add "base: base-18" in your snap and install it manually beforehand. you can try that now via "https://code.launchpad.net/~mvo/+snap/base-18/+build/113575/+files/base-18_very-unstable_amd64.snap" [12:27] ah nice [12:27] thanks [12:27] ackk: my hints cover the snapd side, snapcraft I'm not sure, but if it already builds inside a bionic env thats probably "fine"(ish) for now [12:37] zyga, fwiw it seems snapcraft doesn't really look the base snap up. I had typo'd the base: entry, but the snap built anyway [12:37] ackk: Snapcraft looks at /snap/core/current [12:37] And it must be installed [12:38] ackk: are you building a classic snap? [12:38] kalikiana, but it doesn't fail if it isn't? [12:38] kalikiana, no [12:38] kalikiana: base-18 based snap [12:38] so, the first time I built it, I didn't have the core snap installed [12:38] still, the build succeded [12:39] actually, that's not true [12:39] it was installed [12:39] $ sudo snap try --devmode build/dev-snap/prime/ [12:39] error: cannot perform the following tasks: [12:39] - Mount snap "maas" (unset) (cannot find required base "base-18") [12:39] kalikiana, ^ with base: base-18 [12:39] (and the base installed) [12:40] https://paste.ubuntu.com/26325400/ for reference [12:41] https://git.launchpad.net/~ack/maas/tree/snap/snapcraft.yaml?h=snap-bionic is my snapcraft.yaml [12:44] ackk: I'm afraid I don't know if this is expected to work. There's no code (yet) handling the base as far as I'm aware [12:45] That is, in Snapcraft - `snap try` is not part of Snapcraft [12:45] right, I guess that's more a question for mvo :) [12:45] ackk: that's weird, bases work for sure [12:46] Chipaca, do they require any flag at installation? I justwent with snap install --dangerous [12:48] ackk: that base isn't a base! that's the problem [12:48] ackk: note it doesn't say 'base' in the Notes column [12:48] ackk: remove it, make sure it's type:base, try again [12:49] ackk: you can try bases, also [12:50] Chipaca, so that's a problem with the base build? [12:51] mvo, ^ [12:51] Chipaca, wdym "you can try bases, also" [12:52] ackk: 'snap try' works for bases [12:52] ackk: so you can unsquash the .snap, tweak it, and don't need to repack it [12:52] oh [12:52] ok [12:52] ackk: or you can mount it by hand somewhere, bind mount a tweaked snap.yaml, and try it there, for even less io work [12:53] but that's getting weird :-) [12:53] frankensnap [12:55] Chipaca: snap-confine _may_ have issues with base snaps that are in try mode [12:55] Chipaca: especially the new invalidate stale base snap code [12:55] zyga: this worked for me at some point fwiw [12:55] zyga: you broke my netscape snap /o\ [12:55] yes, it's just that specific aspect that may fail [12:56] zyga: (jk, i broke it myself before you got to it) [12:56] I blame weather, it's still not good IMO [12:57] Chipaca, would it be possible to kick another build of the base with the metadata fixed? [13:01] ackk: oh, so you ahve base-18 installed and it still complains? hmm, what snapd version [13:01] mvo, 2.30 (bionic) [13:01] ackk: strange, I have a look after my meeting (in a meeting right now) [13:03] pedronis: http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html might be relevant [13:24] mvo, ok got a different error now, after changing the base snap adding "type: base": https://paste.ubuntu.com/26325613/ [13:26] * kalikiana going to head out for lunch [13:30] ackk: aha, right. iirc there is a problem with the snap build when if it is set to type: base (sorry that I did not remember that earlier) [13:31] slangasek, i have a slight ubuntu-image problem ... trying to build a multi-volume image like https://paste.ubuntu.com/26325509/ (u-boot lives in /dev/mtd on that device while the rootfs is on mmc so i need two flashable img files), i end up without a writable partition [13:31] mvo: #4394 might be an easy one for you to re-review (and it's green, has one other +1, and is blocking a followup) [13:31] PR #4394: snap: give the snap.Container interface a Walk method [13:31] ackk: hm, thats an interessting error, out of curiosity does it help if you add a "type: app" to the mass snap ? [13:32] Chipaca: oh, indeed, let me look at it again, iirc its long [13:32] mvo: +729-1 [13:32] the followup is shorter but hairier [13:33] slangasek, is there any way to tell u-image where to put writable (definiing it in the structure just gives me an empty ext4 partition, the rootfs doesnt get copied) [13:33] mvo: #4445's fedora thing just passed (the test overall failed because of a timeout downloading core...) [13:33] PR #4445: tests: make less calls to the package manager [13:39] PR snapd#4447 opened: tests: fix test whoami, share successful_login.exp [13:39] Chipaca: what you asked in the other PR ^ [13:42] Chipaca: nice [13:42] Chipaca: well, not that it fails but the fact that fedora didn't [13:44] * Chipaca hugs pedronis [13:45] mvo: if 4445 passes and we agree to land it, i'll merge it into 4442 and add a rename from advice-command to advise-command to it [13:45] Chipaca: +1 [13:48] PR core#68 opened: hooks: fix shellcheck complains [13:51] zyga: blog-post-january :) [13:51] hmm? [13:52] resolutions for the new year ;) [13:52] looking at your blog, you've published something on Jan 02, 03, 04 :) [13:52] mborzecki: ah, yes, :) [13:52] zyga-daily :) [13:52] mvo: just feeling bad about being useless this week, at least I can blog [13:53] zyga: just kidding, I think thats great [13:53] - Fetch and check assertions for snap "test-snapd-tools" (5) (Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/16/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw?max-format=2: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)) [13:53] :-( [13:53] agree with mvo, very nice read [13:54] thanks, I'm trying to find the right balance of length/tech that can be casual to read yet useful [13:54] mvo, lemme try [13:58] PR core#69 opened: hooks: add 28-command-not-found.chroot to create c-n-f handler [13:58] Chipaca: for you -^ :) [14:01] mvo, no difference [14:03] mvo: is that the right way? what creates command_not_found_handler given /usr/lib/command-not-found? [14:03] ackk: can you `snap remove maas` (if it is already installed?) [14:03] mvo, it's not [14:04] ackk: ok, let me look at the code [14:04] although there's a leftover symlink in /var/lib/snapd/snaps/maas_x1.snap [14:04] (this is something I noticed before, if snap try fails [14:04] Chipaca: there is /etc/bash.bashrc which creates this [14:04] ackk: oh, does it help if you remove that (wild guess) [14:04] Chipaca: i.e. its part of the default bash in ubuntu [14:04] mvo, no, I mean I remove it everytime otherwise snap try doesn't work the next time [14:04] but then it still fails [14:05] I think that link should be cleaned up on failures [14:05] Chipaca: so we could do it differently and modify /etc/bash.bashrc to call snap advise-command directly [14:05] mvo: this seems fine to me [14:05] ackk: yeah, sounds like something we want to fix, could you write a bugrport or forum post with reproduce instructions please? [14:06] ackk: I look at the code now, could you pastebin your snapcraft.yaml (or /msg it to me if its private) [14:07] mvo, https://git.launchpad.net/~ack/maas/tree/snap/snapcraft.yaml?h=snap-bionic [14:08] mvo, bugs go in LP, right? [14:08] ackk: yeah [14:08] * mborzecki is off to pick up the kids [14:10] mvo, https://bugs.launchpad.net/snappy/+bug/1741486 [14:10] Bug #1741486: failed snap try leaves snap symlink around [14:12] Bug #1741486 opened: failed snap try leaves snap symlink around [14:12] * zyga-ubuntu tries to unfreeze his desktop [14:14] ackk: ta [14:17] zyga-ubuntu: do you think you could give bug 1741463 some priority. turns out it happens in xenial containers as well, so a bit more severe than i thought [14:17] Bug #1741463: Failure to install maas snap in a container [14:17] ackk: hm, if you `grep "type:" build/dev-snap/prime/meta/snap.yaml - does that show "type: app"? the only thing I can see is that "type" is missing (which is a snap try bug that it does not DTRT if it is missing, I'm just curious about if this maybe a workaround for you) [14:18] * mvo tries to build the maas snap to `snap try` it [14:18] mvo, ah yeah I haven't committed that, I tried locally [14:19] ackk: thats fine [14:19] ackk: I mean, did it propagate into prime/ (the type: app) setting? [14:19] * ackk checks [14:19] $ grep type build/dev-snap/prime/meta/snap.yaml [14:19] type: app [14:19] mvo, ^ [14:20] I have seen that error before but I can't remember what was missing [14:20] PR snapd#4447 closed: tests: fix test whoami, share successful_login.exp [14:21] mvo, btw, can you add "type: base" in base-18? [14:22] ackk: I'm not sure I can without breaking the LP builds [14:22] ackk: but I will try [14:22] oh [14:22] ok [14:22] BjornT_: what was the host of the LXD container? [14:23] ackk: I am running `snapcraft` now for the maas snap checkout. but it seems like it is taking a long time to pull all the deps [14:23] yeah it does [14:24] niemeyer: hi! I noticed when looking at https://forum.snapcraft.io/t/fonts-fail-to-load-when-desktop-plug-added/3414/3 that if I click '...' I no longer see a checkbox for marking it as a solution. I can normally do this. Is this intentional? [14:24] jdstrand: note, gustavo is back next week [14:25] niemeyer: oh, I forgot you were on holiday. answer next week in backscroll and I'll see it at some point [14:25] zyga-ubuntu: thanks [14:25] zyga-ubuntu: the host is xenial [14:28] BjornT_: thanks, I can try on xenial vm tomorrow/monday [14:29] mvo, so, if I make my bionic container privileged I get a different error: [14:29] - Run configure hook of "maas" snap if present (run hook "configure": cannot perform operation: mount --rbind /snap /snap: Permission denied [14:29] in xenial I used to have security.privileged=true [14:29] zyga-ubuntu: cool, thanks [14:33] ackk: privileged containers == borken snapd [14:33] totally unsuportable configuration [14:33] it did work in xenial [14:33] I mean, with xenial containers [14:33] i've been using it for months :) [14:33] ackk: the remount might be interessting for zyga [14:33] heh [14:33] he replied already [14:33] ackk: by accident [14:34] ackk: in such container the host and guest share apparmor namespace [14:34] ackk: and nothing works sensibly [14:34] ackk: what-reloaded-last takes control [14:34] ackk: it's not supported but not actively detected by snapd [14:34] ok [14:34] I'm back to not-privileged [14:34] ackk: it cannot ever work reliably, in the case where host==guest it can also break in some cases when packages don't match exactly [14:45]