mwhudsonsrc/gopkg.in/mgo.v2/bson/json.go:320:7: constant 9007199254740992 overflows int00:13
mwhudsonalso the arch=all build failed00:15
mupPR snapcraft#1851 opened: storeapi: add docstrings to _client <Created by daniellimws> <https://github.com/snapcore/snapcraft/pull/1851>00:44
mupPR snapcraft#1835 closed: Update _desktop.py <codein> <Created by Tanesh1701> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1835>05:50
zygagood morning!07:40
* zyga feels much better today, maybe the weather is changing07:41
mborzeckizyga: morning07:59
zygahey kalikiana, mvo08:05
mvohey zyga - good morning08:11
mborzeckimvo: morning08:17
mborzeckifinally openend a PR with diff output in go-check: https://github.com/go-check/check/pull/9908:18
mupPR go-check/check#99: many: return diff of stringified value when Equals/DeepEquals check fails <Created by bboozzoo> <https://github.com/go-check/check/pull/99>08:18
* zyga hugs mborzecki!08:19
mvomborzecki: hey, good morning! this looks great08:20
* zyga goes to reboot 08:31
mvomborzecki: curious, did you investigate using github.com/kr/pretty ? or is that inferior/unsuited for pr (iirc we talked about this briefly)09:10
mborzeckimvo: i tried it in hope i could drop difflib, but the Diff() that's in kr/pretty is not what i wanted09:22
mvomborzecki: thanks, was just curious09:28
pedronismvo: I'm getting errors preparing Fedora 26 all the time but the log is not clear what is failing09:31
pedronisit seems to fail installing our own built packages, but there's no error in the log09:33
mborzeckimvo: example output http://paste.ubuntu.com/26324546/ with this code: http://paste.ubuntu.com/26324547/09:35
pedronismvo: master is red in the same way09:36
pedronisdid we break something on fedora ?09:36
pedronismmh, it's fedora preparing just taking too long?09:37
mvopedronis: I don't know, I have not checked yet but noticed as well that something is not right09:38
pedronisno, it's failing after 239s that should be below the timeouts09:43
pedroniswe already have 25 and suse on manual :(09:44
* kalikiana need..more..coffee09:47
mvopedronis: I run spread against fedora now with -debug maybe that gives me a clue10:01
pedronisok, I'm turning it into manual in my branch for now but will make a PR that puts it back10:03
=== __chip__ is now known as Chipaca
Chipacamorning! is there something wrong with fedora 26 in linode? getting failed prepares10:11
mvoChipaca: yes, but its unclear what10:12
mvoChipaca: it seems like dnf -q ... fails but it does not tell why10:12
mvo(maybe because of the -q ?)10:12
Chipacai'll do a manual run and see10:12
mvoChipaca: I am in one right now, what I see is "dnf -q -y --refresh install glibc-static" apparently failed10:13
Chipacaah ok10:13
Chipacamvo: network/repo issues?10:14
mvoChipaca: I repeated the commmand manually and it worked :/10:14
mvoChipaca: also dnf history will not show me unsuccessful runs so I don't know why the previous one failed10:15
mvoChipaca: I guess we need to replace "dnf -q" with "quiet dnf" to get useful debug output10:15
Chipacamvo: +110:16
mvoit might be (wild guess) that the fedora repo is a bit overloaded due to the extra security updates pushing out for meltdown/spectre10:23
mupPR snapd#4444 opened: tests: use "quiet" helper instead of "dnf -q" to get errors on failures <Created by mvo5> <https://github.com/snapcore/snapd/pull/4444>10:24
mupPR snapd#4392 closed: many: refresh with appropriate creds <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4392>10:32
Chipacawell that doesn't tell me much10:32
pedronisChipaca: ?10:33
ChipacaError: Failed to synchronize cache for repo 'updates'10:33
Chipacais the entirety of dnf's output10:33
pedroniswe have seen it before though10:33
pedronisit's a clasic10:33
zygadarn, is there no way to have a mock variable for a recursive function?10:38
zygavar func := impl10:38
zygaand then call func inside impl (indirectly here)10:38
mvoChipaca: well, its much better than seeing nothing :)10:38
Chipacamvo: yeah10:38
Chipacazyga: ?10:39
Chipacamvo: not much >> nothing10:39
pedronisyou need a wrapper10:39
zygamvo: guess it's one more time to jump into OFTC10:39
mvoChipaca: and something that we can google for10:39
mvozyga: I'm in oftc, how does that help ;)?10:39
Chipacamvo: best answer i found so far is that we need to do 'dnf clean all' at the start10:40
Chipacamvo: i'm going to test that10:40
zygamvo: go to #linode and complain10:40
zygamvo: that their repo is periodically broken10:40
mvozyga: 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 fine10:40
zygayes, it is their internal mirror10:41
zygaas neal suspected is is probably failing while it syncs to the outer mirror10:41
zygabecause it is removing files before, not after rsync is done10:41
zygaso you can see partially broken mirror at that time10:41
mvomaybe time to update their mirror script then?10:42
mvoubuntu fixed this a long time ago (to be fair it  was a problem for a long time too)10:42
pedroniszyga: you are hitting an initialisation loop10:42
zygapedronis: yes10:43
zyga../../../go/src/github.com/snapcore/snapd/cmd/snap-update-ns/change.go:85: initialization loop:10:43
zyga... bunch of calls10:43
pedronisI recommend just being naive10:43
pedronishave a impl that calls implRec that calls itself or something10:43
pedronisunless you really need the partial mocking, in which a func init() might help10:46
pedronis*which case10:46
* zyga experiments10:48
Chipacamvo: part of the problem is that we do a dnf call per package, and any one of them can fail this way10:48
Chipacamvo: i'll see if i can resurface my branch that avoids this10:48
mvoChipaca: ok10:48
pedroniszyga: these works:  https://play.golang.org/p/uihgox8C_RU10:49
zygapedronis: thank you!10:50
zygayep, that works for me10:52
mupPR snapd#4445 opened: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>11:03
BjornT_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:10
zygaBjornT_: any denials?11:11
Chipacamvo: zyga: do you guys push core to staging, or is that somebody else?11:13
zygano idea about staging11:14
zyga(staging store I assume)11:14
mvoChipaca: staging store ? I'm not familiar with the workflow, cachio is11:15
ChipacaFacu: ^ so … the person that could do it is still on holidays i think11:17
FacuChipaca, ack, thanks11:17
ChipacaFacu: but when he gets back, let's make updating staging part of the release workflow11:17
ChipacaFacu: (remind me?)11:17
ChipacaFacu: (or talk to him! i ain't a manager :-p )11:17
FacuChipaca, :)11:18
BjornT_zyga: not that i can see. this is 'journalctl -xe': https://paste.ubuntu.com/26325079/11:19
mvoChipaca: fun! pr#444411:19
mvo(its just a number but still fun)11:19
pedronismvo: you probably want to merge master into pr#4444 and remove the manual I just added to spread.yaml11:21
Chipacamvo: #4445 is more fun :-p11:23
mupPR #4445: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>11:23
Chipacamvo: why isnt 4445 even allocating a fedora? :-/11:25
mvoChipaca: yeah, was just reviewing this one11:26
Chipacamvo: the review of that one gets a lot easier if you add ?w=1 to the url11:28
Chipaca('ignore whitespace')11:28
zygaBjornT_: that doesn't ring any bells, sorry :/11:33
pedronisChipaca: I turned fedora to manual in my PR to be able to land it fwiw11:36
mupPR snapcraft#1811 closed: Add type hints cli/assertions.py module <codein> <Created by m4sk1n> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1811>11:37
mupPR snapcraft#1851 closed: storeapi: add docstrings to _client <codein> <Created by daniellimws> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1851>11:37
Chipacapedronis: o\11:37
Chipacapedronis: that would explain the lack of fedora in 4445 :-)11:37
pedronisChipaca: you and mvo probably need to turn it on again on your PRs11:37
* pedronis lunch11:37
mvopedronis: ohhh, ok11:38
mupBug #1741463 opened: Failure to install maas snap in a bionic container <Snappy:New> <https://launchpad.net/bugs/1741463>11:47
BjornT_zyga: ok, i filed a bug about it: ^^^11:48
mupPR snapd#4446 opened: snap: use stdout instead of stderr for "fetching" message <Created by mvo5> <https://github.com/snapcore/snapd/pull/4446>11:49
zygaBjornT_: thanks11:50
ackkhi, does anyone know what could be causing this error: https://paste.ubuntu.com/ ?11:52
Chipacaackk: #174146311:52
mupBug #1741463: Failure to install maas snap in a bionic container <Snappy:New> <https://launchpad.net/bugs/1741463>11:52
ackkChipaca, this is a different error, though?11:53
Chipacaackk: ah, perhaps11:54
ackkthis is in a bionic container, and the snap was built on bionic11:56
Chipacaackk: that error looks like the maas snap has been built on the wrong libc11:56
Chipacaackk: do not build snaps on non-xenial unless you really know why you're doing it11:56
Chipacaackk: your snap is now trying to use bionic libc, which isn't available to it11:56
Chipacabah, not sure if this is your snap -- the maas snap, i mean11:56
ackkChipaca, isn't there a bionic-based core image?11:57
Chipacaackk: no11:57
Chipacaackk: there will be, once 18.04 is out11:57
ackkChipaca, not even a daily build?11:58
zygaackk: no, because lots of stuff is missing, we want to make some things different, not just refreshed11:58
zygaackk: I think you will see 18.04 base snaps sooner but not meant for booting11:59
zygain fact mvo did some work on that in December11:59
Chipacaackk: when we get it working it'll be a Big Deal and announced in all the usual ways12:00
ackkI see12:00
Chipacaackk: you're welcome to work on a 18.04 base if you want to thuogh12:00
ackkChipaca, how do I install it?12:00
Chipacaackk: sorry, by 'work on' i meant 'create one'12:00
ackkah :)12:00
Chipacaackk: why do you need 18.04 libc?12:01
Chipacaackk: doesn't maas work on pre-18.04?12:01
ackkChipaca, yes, but master just switched to bionic, so we're now building stuff on bionic12:01
zygaChipaca: there is a very premature one12:02
Chipacaackk: snapd does not yet support that; I'd disrecommend doing so until we do12:02
zygasnapcore/base-18 AFAIR12:02
zygabut super early stuff12:02
Chipacazyga: not a public snap fwiw12:03
zygapublic just not done12:03
zygait's on github ;)12:03
Chipacazyga: ah :-)12:03
Chipacastill, not supported, and i wouldn't recommend it at all12:04
Chipacaunless you really want to work on _that_ and not the thing you're working on12:04
ackkok, thanks for the info12:04
Chipacaif it were easy it'd be done :-D12:04
mvoackk: we have some code for base-18, if you don't mind that things break I can push what we have to edge12:05
mvoackk: is our WIP branch https://github.com/snapcore/base-1812:05
mvoaha, zyga said it already, sorry for the noise12:05
ackkmvo, so, if you push that base to edge, installing a bionic-built snap should work, right?12:15
zygahow do you build that bionic-based snap?12:15
zygasnapcraft probably cant because there's no real base 18 yet12:15
zygaso ... ?12:15
ackkit does build12:16
zygaon bionic itself12:16
zygabut then it looks at the core snap to resolve libs and whatnot12:16
zygaand there's no base 18 to do that12:16
zygaso something is wrong at the build stage already12:16
ackkzyga, where does it look for the core snap?12:18
zygaackk: to resolve libs and dependencies12:18
zygaackk: kalikiana would know more12:18
ackkzyga, no I mean where does it look it up12:18
ackklocally or does it download it ?12:18
zygaackk: it downloads core snap AFAIK12:19
zygabut I really don't know12:19
mvoackk: 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:26
ackkah nice12:27
mvoackk: 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 now12:27
ackkzyga, fwiw it seems snapcraft doesn't really look the base snap up. I had typo'd the base: entry, but the snap built anyway12:37
kalikianaackk: Snapcraft looks at /snap/core/current12:37
kalikianaAnd it must be installed12:37
kalikianaackk: are you building a classic snap?12:38
ackkkalikiana, but it doesn't fail if it isn't?12:38
ackkkalikiana, no12:38
zygakalikiana: base-18 based snap12:38
ackkso, the first time I built it, I didn't have the core snap installed12:38
ackkstill, the build succeded12:38
ackkactually, that's not true12:39
ackkit was installed12:39
ackk$ sudo snap try --devmode build/dev-snap/prime/12:39
ackkerror: cannot perform the following tasks:12:39
ackk- Mount snap "maas" (unset) (cannot find required base "base-18")12:39
ackkkalikiana, ^ with base: base-1812:39
ackk(and the base installed)12:39
ackkhttps://paste.ubuntu.com/26325400/ for reference12:40
ackkhttps://git.launchpad.net/~ack/maas/tree/snap/snapcraft.yaml?h=snap-bionic is my snapcraft.yaml12:41
kalikianaackk: 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 aware12:44
kalikianaThat is, in Snapcraft - `snap try` is not part of Snapcraft12:45
ackkright, I guess that's more a question for mvo :)12:45
Chipacaackk: that's weird, bases work for sure12:45
ackkChipaca, do they require any flag at installation? I justwent with snap install --dangerous12:46
Chipacaackk: that base isn't a base! that's the problem12:48
Chipacaackk: note it doesn't say 'base' in the Notes column12:48
Chipacaackk: remove it, make sure it's type:base, try again12:48
Chipacaackk: you can try bases, also12:49
ackkChipaca, so that's a problem with the base build?12:50
ackkmvo, ^12:51
ackkChipaca, wdym "you can try bases, also"12:51
Chipacaackk: 'snap try' works for bases12:52
Chipacaackk: so you can unsquash the .snap, tweak it, and don't need to repack it12:52
Chipacaackk: or you can mount it by hand somewhere, bind mount a tweaked snap.yaml, and try it there, for even less io work12:52
Chipacabut that's getting weird :-)12:53
zygaChipaca: snap-confine _may_ have issues with base snaps that are in try mode12:55
zygaChipaca: especially the new invalidate stale base snap code12:55
Chipacazyga: this worked for me at some point fwiw12:55
Chipacazyga: you broke my netscape snap /o\12:55
zygayes, it's just that specific aspect that may fail12:55
Chipacazyga: (jk, i broke it myself before you got to it)12:56
zygaI blame weather, it's still not good IMO12:56
ackkChipaca, would it be possible to kick another build of the base with the metadata fixed?12:57
mvoackk: oh, so you ahve base-18 installed and it still complains? hmm, what snapd version13:01
ackkmvo, 2.30 (bionic)13:01
mvoackk: strange, I have a look after my meeting (in a meeting right now)13:01
Chipacapedronis: http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html might be relevant13:03
ackkmvo, ok got a different error now, after changing the base snap adding "type: base": https://paste.ubuntu.com/26325613/13:24
* kalikiana going to head out for lunch13:26
mvoackk: 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:30
ogra_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 partition13:31
Chipacamvo: #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
mupPR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>13:31
mvoackk: hm, thats an interessting error, out of curiosity does it help if you add a "type: app" to the mass snap ?13:31
mvoChipaca: oh, indeed, let me look at it again, iirc its long13:32
Chipacamvo: +729-113:32
Chipacathe followup is shorter but hairier13:32
ogra_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
Chipacamvo: #4445's fedora thing just passed (the test overall failed because of a timeout downloading core...)13:33
mupPR #4445: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>13:33
mupPR snapd#4447 opened: tests: fix test whoami, share successful_login.exp <Created by pedronis> <https://github.com/snapcore/snapd/pull/4447>13:39
pedronisChipaca: what you asked in the other PR  ^13:39
mvoChipaca: nice13:42
mvoChipaca: well, not that it fails but the fact that fedora didn't13:42
* Chipaca hugs pedronis 13:44
Chipacamvo: 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 it13:45
mvoChipaca: +113:45
mupPR core#68 opened: hooks: fix shellcheck complains <Created by mvo5> <https://github.com/snapcore/core/pull/68>13:48
mborzeckizyga: blog-post-january :)13:51
mvoresolutions for the new year ;)13:52
mborzeckilooking at your blog, you've published something on Jan 02, 03, 04 :)13:52
zygamborzecki: ah, yes, :)13:52
mborzeckizyga-daily :)13:52
zygamvo: just feeling bad about being useless this week, at least I can blog13:52
mvozyga: just kidding, I think thats great13:53
Chipaca- 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
mborzeckiagree with mvo, very nice read13:53
zygathanks, I'm trying to find the right balance of length/tech that can be casual to read yet useful13:54
ackkmvo, lemme try13:54
mupPR core#69 opened: hooks: add 28-command-not-found.chroot to create c-n-f handler <Created by mvo5> <https://github.com/snapcore/core/pull/69>13:58
mvoChipaca: for you -^ :)13:58
ackkmvo, no difference14:01
Chipacamvo: is that the right way? what creates command_not_found_handler given /usr/lib/command-not-found?14:03
mvoackk: can you `snap remove maas` (if it is already installed?)14:03
ackkmvo, it's not14:03
mvoackk: ok, let me look at the code14:04
ackkalthough there's a leftover symlink in /var/lib/snapd/snaps/maas_x1.snap14:04
ackk(this is something I noticed before, if snap try fails14:04
mvoChipaca: there is /etc/bash.bashrc which creates this14:04
mvoackk: oh, does it help if you remove that (wild guess)14:04
mvoChipaca: i.e. its part of the default bash in ubuntu14:04
ackkmvo, no, I mean I remove it everytime otherwise snap try doesn't work the next time14:04
ackkbut then it still fails14:04
ackkI think that link should be cleaned up on failures14:05
mvoChipaca: so we could do it differently and modify /etc/bash.bashrc to call snap advise-command directly14:05
Chipacamvo: this seems fine to me14:05
mvoackk: yeah, sounds like something we want to fix, could you write a bugrport or forum post with reproduce instructions please?14:05
mvoackk: I look at the code now, could you pastebin your snapcraft.yaml (or /msg it to me if its private)14:06
ackkmvo, https://git.launchpad.net/~ack/maas/tree/snap/snapcraft.yaml?h=snap-bionic14:07
ackkmvo, bugs go in LP, right?14:08
mvoackk: yeah14:08
* mborzecki is off to pick up the kids14:08
ackkmvo, https://bugs.launchpad.net/snappy/+bug/174148614:10
mupBug #1741486: failed snap try leaves snap symlink around <Snappy:New> <https://launchpad.net/bugs/1741486>14:10
mupBug #1741486 opened: failed snap try leaves snap symlink around <Snappy:New> <https://launchpad.net/bugs/1741486>14:12
* zyga-ubuntu tries to unfreeze his desktop14:12
mvoackk: ta14:14
BjornT_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 thought14:17
mupBug #1741463: Failure to install maas snap in a container <Snappy:New> <https://launchpad.net/bugs/1741463>14:17
mvoackk: 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:17
* mvo tries to build the maas snap to `snap try` it14:18
ackkmvo, ah yeah I haven't committed that, I tried locally14:18
mvoackk: thats fine14:19
mvoackk: I mean, did it propagate into prime/ (the type: app) setting?14:19
* ackk checks14:19
ackk$ grep type build/dev-snap/prime/meta/snap.yaml14:19
ackktype: app14:19
ackkmvo, ^14:19
ackkI have seen that error before but I can't remember what was missing14:20
mupPR snapd#4447 closed: tests: fix test whoami, share successful_login.exp <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4447>14:20
ackkmvo, btw, can you add "type: base" in base-18?14:21
mvoackk: I'm not sure I can without breaking the LP builds14:22
mvoackk: but I will try14:22
zyga-ubuntuBjornT_: what was the host of the LXD container?14:22
mvoackk: I am running `snapcraft` now for the maas snap checkout. but it seems like it is taking a long time to pull all the deps14:23
ackkyeah it does14:23
jdstrandniemeyer: 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
zyga-ubuntujdstrand: note, gustavo is back next week14:24
jdstrandniemeyer: oh, I forgot you were on holiday. answer next week in backscroll and I'll see it at some point14:25
jdstrandzyga-ubuntu: thanks14:25
BjornT_zyga-ubuntu: the host is xenial14:25
zyga-ubuntuBjornT_: thanks, I can try on xenial vm tomorrow/monday14:28
ackkmvo, so, if I make my bionic container privileged I get a different error:14:29
ackk- Run configure hook of "maas" snap if present (run hook "configure": cannot perform operation: mount --rbind /snap /snap: Permission denied14:29
ackkin xenial I used to have security.privileged=true14:29
BjornT_zyga-ubuntu: cool, thanks14:29
zyga-ubuntuackk: privileged containers == borken snapd14:33
zyga-ubuntutotally unsuportable configuration14:33
ackkit did work in xenial14:33
ackkI mean, with xenial containers14:33
ackki've been using it for months :)14:33
mvoackk: the remount might be interessting for zyga14:33
mvohe replied already14:33
zyga-ubuntuackk: by accident14:33
zyga-ubuntuackk: in such container the host and guest share apparmor namespace14:34
zyga-ubuntuackk: and nothing works sensibly14:34
zyga-ubuntuackk: what-reloaded-last takes control14:34
zyga-ubuntuackk: it's not supported but not actively detected by snapd14:34
ackkI'm back to not-privileged14:34
zyga-ubuntuackk: it cannot ever work reliably, in the case where host==guest it can also break in some cases when packages don't match exactly14:34
mborzeckiwrapping it up for today, have a great weekend14:45
mvoackk: when I run "snapcraft" from the git pull I get https://paste.ubuntu.com/26326002/ and I don't have a dir for trying AFAICT14:46
ackkmvo, which branch are you using?14:47
ackkmvo, the snap-bionic one?14:47
mvoackk: ah, maybe that is the problem, I might be on master, let me check14:51
ackkmvo, that branch should fix the issue14:51
ackkmvo, right, checkout snap-bionic :)14:51
mvoackk: *cough* thanks14:52
mvoackk: thanks, I can reproduce the failure (not exactly the same though) - I need to think a bit but this may well be something that requires a couple of days to fix as the base-18 work is still very much WIP14:57
ackkmvo, cool, thanks14:57
ackkmvo, fwiw I get the same error with both snap try and snap install14:57
mvoackk: (i.e. the issue is that no snapd/snap/snapctl/snap-exec is available inside base-18 currently, i.e. we need to mount that from snap-confine into the right places yet iirc)14:58
ackkmvo, I see14:58
* mvo ponders a bit14:59
zyga-ubuntumvo: good observation, I was thinking that we need a version of the inside-ns tools that are linked statically and available14:59
zyga-ubuntumvo: I would not reuse the regular ones as there's no guartee those would work (snap-confine, snap-update-ns)15:00
zyga-ubuntu(snapctl perhaps)15:00
mvozyga-ubuntu: +1 on that15:00
zyga-ubuntumvo: alternatively a new novel way of using them from within the core snap ns15:00
zyga-ubuntumvo: but this is problematic15:00
mvoChipaca: btw, do you have an opinion on lp 1737197 ? you worked in this area recently15:00
zyga-ubuntumvo: (because /run/snapd/ns)15:00
zyga-ubuntuso, my destkop is in weird state15:01
zyga-ubuntuall the software works15:01
zyga-ubuntuGUI updates15:01
zyga-ubuntumouse moves15:01
zyga-ubuntubut, input is broken, nothing gets passed to apps15:01
mvozyga-ubuntu: right, we should brainstorm about this monday15:01
zyga-ubuntumvo: sounds good15:01
mvozyga-ubuntu: sounds like something is grabing your input ?15:01
zyga-ubuntuI can ssh in and despite some high ram usage (not even swapping though)15:01
zyga-ubuntunothing seems wrong15:01
zyga-ubuntumaybe gnome-shell15:01
zyga-ubuntuI'm reluctant to kill it15:02
mvozyga-ubuntu: that causes havoc :)15:02
zyga-ubuntuI'll keep it asis for now, let some software running finish15:02
mvozyga-ubuntu: in the old days, ctl-alt-f2 and then back to X helped with these15:02
zyga-ubuntuI did that, I can go back to gnome login manager15:02
zyga-ubuntuand login as myself15:02
zyga-ubuntubut then it is stuck again15:02
zyga-ubuntu(weird, right?)15:02
zyga-ubuntu(by login I mean unlock the same session)15:03
* mvo nods15:03
Chipacazyga-ubuntu: could it be the thing where your input is grabbed by the console?15:04
Chipacaor was that the other way around15:05
Chipacasomething about ^C in the terminal killing the session maybe15:05
zyga-ubuntuChipaca: console as in other vt?15:05
zyga-ubuntuI only run irssi, vim and a few man pages there15:05
zyga-ubuntuand no other vt is used15:05
zyga-ubuntuI think that was fixed a while ago (by now)15:06
zyga-ubuntubut weirdly, nothing has focus15:06
zyga-ubuntuand I cannot click to focus15:06
zyga-ubuntuor alt-tab to focus15:06
ackkmvo, FTR I get the same error if "snap try" a maas snap built on xenial15:10
ackk(which of course doens't use base-18)15:10
mvoackk: hm, hm, I wonder if something funny happend to your /var/lib/snapd/state.json - can you install anything or is it realy just maas that is unhappy?15:11
ackkmvo, I do have other snaps installed15:11
mvoackk: (careful with sharing the content of that file, it contains e.g. macaaron data which is sensitive)15:11
mvoackk: right, I mean, can you install other new snaps?15:11
ackktrying now15:11
ackksnap install hello-world worked15:12
mvoackk: ok, so its not that15:12
ackkmvo, no, also I can install the stable maas snap in bionic15:14
ackk(from the store)15:14
Chipacamvo: answered in 173719715:17
mvoChipaca: ta15:20
* mvo steps out for some minutes15:20
ackkmvo, not sure if I mentioned it before, but I'm doing all of this in a bionic container15:33
* Chipaca is >this< close to giving up on this fedora malarkey15:52
naccChipaca: good use of malarkey15:53
ackkwhat's the proper way of fixing a failed snap removal inside a container?16:16
mupPR snapd#4446 closed: snap: use stdout instead of stderr for "fetching" message <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4446>16:22
mupPR snapd#4435 closed: snap: do not leak internal network errors to the user <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4435>16:24
mupPR snapd#4434 closed: tests/main/confinement-classic: enable the test on Fedora <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4434>16:26
mvojdstrand: not sure how busy you are (super busy I guess) - if there is a spare cycle, a review for pr 4073 would be nice, only the security aspects of course. it should address the issues you outlined16:28
mupPR #4073: snap: add io.snapcraft.Settings to `snap userd` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4073>16:28
ackkmvo, fwiw https://paste.ubuntu.com/26326503/ is what I see from snapd debug16:29
mvoackk: thanks, interessting. it looks like the type="" is just a secondary error after "2018/01/05 16:26:21.967261 task.go:303: DEBUG: 2018-01-05T16:26:21Z ERROR cannot find installed snap "maas" at revision x1" but this one is also puzzling16:34
ackkmvo, could it have to do with --devmode?16:37
ackkISTR hitting this error before, but I can't remember how I got past it16:38
mvoackk: not sure, sorry, I setup a proper bionic env now to test fully (so far I only build the snap under bionic but not tested it there)16:40
ackkkalikiana, if I don't specify a base: in my snap, but include all shared libs that binaries need manually, will snapcraft still look up stuff from the core snap?16:55
ackkkalikiana, (just wondering if I could not use a base and include everything so that the snap then works on bionic)16:56
slangasekogra_: hum, it's certainly meant to be possible to define the location of writable in a multi-volume image, and have it correctly populated; so if you are seeing something different, it's perhaps a bug in un-exercised code; can you reach out to sil2100?16:56
ogra_slangasek, yeah, i would have pinged him first but he seemed to be off16:56
ogra_slangasek, oh, fun ... looking at gadget-yml.rst in the u-image source has:16:58
ogra_XXX: how do we know which volume the writable partition is supposed to be16:58
ogra_placed on?16:58
ogra_so obviously a missing feature16:58
ogra_i guess we need something like a "has-writable: true" option for the volumes that triggers writable to be created there16:59
kalikianaackk: Not quite sure I grok the question. If you include all the libs that won't change how Snapcraft operates... but there will be no need to use anything from the core snap17:00
slangasekogra_: uh, the design that we documented is that you spell out in your yaml which image gets the writable partition17:01
ogra_slangasek, yeah, seems that lacks implementation yet17:01
ackkkalikiana, I'm wondering what is snapcraft looking at the core snap for17:02
ogra_i suspect nobody needed that yet17:02
kalikianaackk: For classic snaps it needs to link against what's in core17:04
ackkkalikiana, this is not a classic snap17:04
slangasekogra_: we certainly don't need any 'has-writable: true'.  what does your yaml look like?  Did you set role: system-data?17:05
ogra_slangasek, ah ... no, i didnt ... this (with customer info removed) is my yaml https://paste.ubuntu.com/26325509/17:06
slangasekogra_: 'role: system-data', documented in https://forum.snapcraft.io/t/the-gadget-snap/69617:06
ogra_i'll try with role17:06
kalikianaackk: Hmmm I can't think of anything else right now - kyrofa, any idea?17:07
ogra_oh, wow ... that tellys you you can use an implicit fs label "or writable" ... our initrd wouldnt be happy about any other label17:07
ackkkalikiana, basically to workaround https://paste.ubuntu.com/26325221/17:07
ackkI'm wondering if we could manually include the libs we need from bionic17:08
ogra_slangasek, thanks ! i think that will do it ... i didnt read the forum post but looked at the shipped docs in the source tree ... i guess they need some updating (or just a pointer to the forum)17:09
jdstrandmvo: it's already high in the trello queue already. probably won't happen today though17:11
mvojdstrand: thanks, no worries!17:11
* kalikiana wrapping up for the day/ week, tho probably idling on IRC for a little while17:18
mvoackk: with the following PR https://github.com/snapcore/base-18/pull/24 I get to https://paste.ubuntu.com/26326893/ - I suspect that maas is doing a chown to something that is not root in the configure hook? this is currently not supported unfortunately17:29
mupPR base-18#24: hooks: fixes to make it usable as a real base snap <Created by mvo5> <https://github.com/snapcore/base-18/pull/24>17:29
mvoackk: I will also try to build with type: base, I hope lp/snapcraft support this now. sorry for this bumpy ride17:31
mvoackk: fwiw, the pastebin above is all using bionic17:32
mupPR snapd#4448 opened: Add rules for Media API to the BlueZ D-Bus policy <Created by lhartung> <https://github.com/snapcore/snapd/pull/4448>17:34
ackkmvo, np, we're all breaking new ground :)17:35
mvoackk: I requested a new build for base-18 but looks like the builds are very slow/busy right now (schedule in ~3h)17:35
ackkmvo, can you paste the link to the built images again?17:36
Chipacamvo: do i have your +1 for #444517:37
mupPR #4445: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>17:37
ackkmvo, ah, yes https://paste.ubuntu.com/17:37
=== [-asc-] is now known as [asc]
ackkmvo, but that used to work before?17:37
ackkmvo, can you try commenting those out (I don't have the updated base image here)17:38
mvoChipaca: yes17:38
mupPR snapd#4445 closed: tests: make less calls to the package manager <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4445>17:38
* mvo hugs Chipaca 17:39
ackkmvo, I meant https://paste.ubuntu.com/26326974/17:50
blake_rackk: here17:56
blake_rack: here17:57
ackkblake_r, mvo was asking about those chown in the configure hook17:57
ackkmvo, does snapd now support running as different users?17:57
blake_rthat is because squid will not allow you to run as root17:57
blake_rso we spawn it with nobody:nobody17:58
blake_rwe have the sample problem with postgres17:58
ackkmvo, ^17:58
ackkblake_r, how do you actually spawn it as nobody? you can't really "su" right?18:00
ackkblake_r, maybe maas should be a classic snap :)18:00
blake_rsupervisord runs it18:00
blake_rackk: no!18:00
ackkactually it probably can't18:00
ackkbecause other distros, right?18:01
blake_rit needs to go to strict18:01
blake_rjust have not got that far18:01
ackkwhich it probably can without too much work18:01
ackkbut, digressing :)18:01
blake_ryeah probably need some interfaces, but maybe its close18:01
blake_rlook at snap/conf/supervisord.conf.template18:02
blake_ralso we do some wierd stuff with sudo to use initdb for postgres18:02
blake_rsrc/maascli/snappy.py also changes to run as nobody to perform the `maas init` command that initialized the database18:05
ackkmvo, is that still suported? ^ running as nobody18:10
mvoackk: aha, thanks. I will try devmode then if that is a known thing18:56
mvoackk: and progress! it now fails with an error that it can't find /usr/share/distro-info/ubuntu.csv, not sure we can do much about this18:57
mvoackk: so this is all with my updated base-18 that still has a "starts in 3h estimate "18:58
ackkmvo, I see, where can I get those builds once they're done?18:58
Saviqhi all, is installing a local snap getting stuck at "copy snap data" (when the snap barely has any data outside of $SNAP_COMMON) a known issue? it's stuck at aborting that change now18:58
ackkmvo, so you commented out the chmod?18:58
mvoackk: I used --devode19:01
mvoackk: here https://code.launchpad.net/~mvo/+snap/base-1819:01
ackkmvo, oh so with devmode the chown works?19:03
mvoackk: correct19:06
mvoackk: I was trying to install it as a strict snap, that failed19:06
blake_rmvo: ah yeah doesn't work in strict19:06
ackkmvo, is there support in snaps now to run stuff as different users?19:06
blake_rmvo: does snappy support users yet?19:07
mvoackk: so the next stumbling block is this ubuntu.csv19:07
mvoblake_r: sorry, not yet :/19:07
blake_rmvo: I can fix that ubuntu.csv19:07
mvoblake_r: cool, thank you!19:07
blake_rmvo: we can't go to strict until thats done, timeline on users?19:07
mvoblake_r: if its trivial (the ubuntu.csv fix) then please share the diff then I can try again with the fix19:08
mvoblake_r: no timeline yet, I expect this to be a topic in cape town though19:08
blake_rmvo: okay19:08
ackkplease make sudo work in snaps! :)19:08
blake_rmvo: http://paste.ubuntu.com/26327405/19:11
blake_rmvo: can't really test, but that should work19:12
mvoblake_r: ta19:12
mvoblake_r: unfortunately your diff is not enough, it appears that the distro_info python module looks into /usr/share/distro-info but this data is now located in $SNAP/usr/share/distro-info19:25
mvoblake_r: and looking at distro_info.py it appears to be hardcoded. we will soon have "layout" to remap bits of the filesystem dynamically. that will be an elegant way to fix this19:27
mvoblake_r: fixing distro_info to look at a env for its datadir is also trivial of course, probably something to talk about on monday (getting late here in my TZ :)19:28
blake_rmvo: okay we can look at it money, go enjoy your evening19:31
mvoblake_r: alternatively we *could* add distro-info to base-18, but I would prefer to keep it as tiny as possible (though distro-info is tiny so maybe a worthwhile tradeoff)19:31
ackkmvo, blake_r those .csv come from the distro-info part19:31
mvoackk: yeah, except that the python code hard-codes /usr/share/distro-info it seems19:32
blake_rmvo: it would be nice to be in the base19:32
mvoackk: and in the snap that is not the location19:32
ackkactually, used to19:32
blake_rmaybe that is why it worked on xenial19:32
blake_ras we didn't have this issue19:32
mvoblake_r: its in the range of <90kB so not too bad19:33
mvoblake_r: correct19:33
mvoblake_r: I checked, its there in the xenial based core we have today19:33
blake_ryeah placing it in the base would be helpful19:33
ackkblake_r, so we could probably kill that part altogether if it's in core19:33
blake_rprobably need the python piece, but not the csv19:35
mvoblake_r, ackk with the disto-info added to base-18 and my other PRs merged for base-18 I can install maas with --devmode now in bionic19:39
mvoand the snap.maas.supervisor.service is up and running19:39
blake_rmvo: can you try `maas init`19:39
blake_rsudo maas init19:39
mvoI used the defaults and it is now at "initializing database"19:40
mvohow long should I wait for "init database"?19:41
blake_ronce its done19:41
mvofwiw https://github.com/snapcore/base-18/pull/2619:41
mupPR base-18#26: hooks: also install the disto-info package in base-18 <Created by mvo5> <https://github.com/snapcore/base-18/pull/26>19:41
blake_rshouldn't take to long19:41
blake_runless its stuck or something19:42
mvo(this is a single core bionic vm with just 1gb ram, it is still at init)19:42
blake_rah then it might take a few19:42
mvostrace shows its in futex(... FUTEX_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME...)19:43
mvoI will leave it run for a bit and report back19:43
blake_rif it finishes run `sudo maas status` to get the status of the services inside the snap19:44
blake_rsome should be off but none should be fatal19:44
ackkmvo, \o/19:53
ackkmvo, once it's all built, could that be pushed to edge?19:54
mvoackk: yes, I think at this point thats fine20:01
mvoackk: may take a bit, the one estimate just jumped from 3h to 8h20:02
mvoackk, blake_r: unfortunately still at init database, I will call it a day. lets look at this again monday. have a good weekend20:03
mupPR snapcraft#1842 closed: lxd: Change "Terminating" message to debug level <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1842>20:08
blake_rmvo: have a good weekend, thanks for the help20:08
kyrofaelopio, are you around? And have you ever used circle CI before?21:05
maninaliftI have just installed Ubuntu Server 17.10 with snappy and set up the nextcloud snap - GREAT - really easy (which is a relief after giving up on setting up nextcloud in NixOS)21:57
elopiokyrofa I am, and I have not. Just read the guides21:57
kyrofaelopio, okay good, keep it that way. You can be the guinea pig for the tutorial I'm writing, I don't remember exactly what it looks like for new users21:58
maninalift...however I'm not sure the best way to set up different services under different subdomains21:59
wililupyI want to add an environment variable to my application launcher. Would it be easier just to write my own wrapper or is this something that I can have set inside the snap?21:59
maninalifte..g.    cloud.mydomain.com for nextcloud21:59
maninaliftand chat.mydomain.com for rocketchat22:00
maninaliftif I were setting up a web-server without the snappy container stuff I'd put an nginx instance in front  to proxy to different services22:02
maninaliftbut I wondered whether there is a particular way I should be doing this that fits with snappy22:04
maninaliftthere is a clear focus on giving a really simple setup exerience and I thought there might be something that "just works" when I setup multiple services without my having to manually configure the proxy22:05
maninalift...thanks for any help22:05
Chipacawililupy: you can declare environemtn in the yaml22:07
Chipacawililupy: whether it's enough for what you need  i don't know22:08
Chipacamaninalift: sounds like a question for the forum tbh22:08
Chipacamaninalift: if you could open a new topic on https://forum.snapcraft.io/ that'd be great22:09
wililupyChipaca: are there examples of this on snapcraft.io?22:10
Chipacawililupy: let me check22:10
elopiokyrofa: good, I'll just stay ignorant 😃22:10
mcphailmaninalift: I know setting up namevirtualhosts still requires doing things the old way and then proxying. I've asked about this recently22:11
wililupyideally, I would like to use 'snap set' to configure which configuration file to use for the device since the variable is read by the applicaation and the config file tells what port does what and how many ports there are on the device.22:11
maninaliftChipaca: OK, thanks will do22:11
Chipacawililupy: i'm not very good at finding these things, but https://forum.snapcraft.io/t/declaratively-defining-environment-variables/17522:12
Chipacawililupy: that does sound like the sort of thing the config hook was made for, yes22:13
Chipacawililupy: note 2.30 gives you the ability to stop/start services from hooks22:13
wililupyThanks Chipaca, that is what I was looking for. Do you have a good place I can read up on the "inner workings" of snap set command?22:16
Chipacawililupy: 'snap set' triggers the config hook; look that up -- i think kyrofa explained it in detail22:17
Chipacawililupy: https://kyrofa.com/posts/snap-configuration-the-configure-hook ?22:17
Chipacamaybe :-p22:17
wililupyChipaca: Cool. I check that out.22:17
kyrofaChipaca, yeah, it's discussed there, certainly22:18
=== genii is now known as barista
=== barista is now known as genii

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!