[00:06] Why could std::system in my app fail with "Bad system call" when apparmor is in enforce mode? [00:06] Oh yeah, totally missed one fact. [00:08] What is the right way to run another app from within same snap package if they require different plugs? [00:09] I guess my attempt to make std::system on game server fail because server require network-bind while client that launching it doesn't have such permission. [00:13] Yeah that's was it. [00:54] PR snapcraft#1414 closed: cmake plugin: call the cmake using build dir as source [04:48] good morning [06:21] mvo: hello [06:21] mvo: I'm going to walk kids to school one more time today [06:21] mvo: but I left you some interesting topics on the forum [06:21] mvo: I can also give you a shell on the ppc box in case you get curious to try [06:22] mvo: I'll talk to you soon [06:22] PR snapcraft#1538 opened: tests: update the store failure tests [06:23] zyga-solus: thanks, see you [06:26] PR snapd#3885 opened: tests: improve the listing test to not fail for e.g. 2.28~rc2 [06:36] PR snapd#3886 opened: tests: make TestCmdWatch more robust [06:45] jamesh: hey, I think your polkit PR is good to go if we rename the name from "manage-snaps" to just "manage" for now. [07:20] re [07:21] mvo: did you see the ppc situation? [07:25] zyga-solus: yes, "funny" [07:25] mvo: what are your thoughts on that? [07:25] zyga-solus: I think we can trivially get a powerpc snap build, we need to ask for it though, I can not enable it [07:25] mvo: I tried to build master but got a lot of errors on get-deps [07:25] zyga-solus: but I personally think we should kill it [07:26] mvo: if you want I can give you a shell on the box [07:26] mvo: yes, I agree [07:26] zyga-solus: oh, really? [07:26] mvo: but I'm afraid we cannot kill it in xenial yet :/ [07:26] mvo: sure, one sec [07:26] brace yourself for irony [07:26] # github.com/kardianos/govendor/vendor/golang.org/x/sys/unix [07:26] ../../kardianos/govendor/vendor/golang.org/x/sys/unix/dirent.go:16:5: error: reference to undefined name ‘isBigEndian’ [07:26] if isBigEndian { [07:26] (there's 1000s of errors) [07:26] there are* 1000s of errors [07:26] this is just one [07:27] I think that x/sys/unix is broken on ppc somehow [07:29] zyga-solus: hm, strange, I mean, the debs build [07:29] zyga-solus: and we reverted to dependencies that do not require x/sys/unix iirc [07:33] zyga-solus: quick review on 3881 would be great, that should fix builds on arm/ppc [07:33] great, let me look [07:43] o/ [07:45] hi, I'm hitting https://bugs.launchpad.net/snapd/+bug/1691999, does anyone know what could be causing it? [07:45] Bug #1691999: Snap removal hangs inside LXD container [07:49] ackk: hey, I think I know [07:50] ackk: it's a known issue, there's no fix yet I'm afraid [07:50] zyga-solus, uh? [07:50] ackk: there's a bug report with extra details... [07:50] does that mean snaps inside lxd won't work? [07:50] it works but that part is broken [07:51] https://bugs.launchpad.net/snapd/+bug/1712930 [07:51] Bug #1712930: snap-confine: mounts happen in the wrong order [07:51] zyga-solus, can you please mark my bug as duplicate ? [07:51] sure, which one? [07:51] ah [07:51] the one I just pasted [07:52] done [07:53] zyga-solus, thanks [07:53] zyga-solus, unrelated, does snapd keep all old revisions of a snap when it gets updated or is there a limit? [07:53] I noticed I have 3 versions of core installed [07:55] that's normal, snapd keeps three revisions of each snap around [07:55] ah cool, thanks [07:59] zyga-solus: master is failing on powerpc with new failure modes, its a bit of a whack-a-mole [08:00] ppisati, so we'll need another kernel snap rebuild later today, seems the shellcheck stuff that was added to the initrd completely breaks resizing on all GPT devices by adding qutes in "unusual places" ... i'll try to fix that today and will ping you once something is ready (i had to soll back the dragonboard kernel by 7 revisions in all channels to get it back working) [08:01] ogra_: ah! i saw some movement in the kernel snap store [08:01] ogra_: np, just tell me if you need anything [08:01] yeah,. sorry, cachio was desparate since he needed to get core tested [08:02] ogra_: that means it affects all images, right? [08:02] hmm, just had snapmgrTestSuite.TestInstallWithoutCoreTwoSnapsWithFailureRunThrough fail at random [08:02] it was a bad combo ... 6 versions had the brioken fixrtc and the latest one with the fixed fixrtc had the broken shellcheck stuff [08:02] ouch [08:02] ppisati, only the opnes with GPT table ... [08:02] ogra_: ok [08:03] which means well ... only dragonboard or x86 on real devices [08:03] and the latter doesnt get tested at all [08:03] (x86 always only gets tested with qemu and there we dont esize) [08:06] zyga-solus, pong ... :P ... what should i start to build ? [08:06] youch, that test takes 15s+ even when it passes [08:07] mvo, as i said yesterday already, we have never built on powerpc, only ppc64el ... whats the reason fr suddenly starting to support it ? [08:08] ogra_: sec, on the phone === JoshStrobl is now known as JoshStrobl|zzz [08:10] ogra_: if we make the "not support it" official we could stop spending time of fixing tests etc [08:10] ogra_: thats where this comes from [08:14] mvo, it has alwaysd been official [08:15] mvo, we always had 6 arches since day one ... powerrpc hasnt been one of them [08:15] ogra_: also in the sense that the distro knows that a broken powerpc build does not block a sru? [08:15] i never dealt with the distro srus ... but i know that we never have built core or ubuntu cre or the tarballs for powerpc [08:16] on request of mark initially IIRC [08:16] the only power arch we ever supported was ppc64el [08:17] pedronis: http://pastebin.ubuntu.com/25488612/ might be of interest to you (happens every ~100 runs, here) [08:17] we have 4 arches we build images for (2xarm, 2xx86) and 2 arches we onyl build core for (s390x and ppc64el) [08:17] and we never built for any other arches ... [08:18] if you want to get powerpc working all of a sudden that will likely take a lot more work to get a proper core [08:22] re [08:22] * zyga-solus spent too much time on the phone and needs to spend more time with administrativa, sorry [08:23] mvo: tests need tweaking [08:23] mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170907_220303_c073c@/log.gz [08:23] mvo: listing tests now fails on the ~rc2 [08:24] zyga-solus: check the open PRs ;) [08:24] mvo: aha :) [08:24] PR snapd#3887 opened: snapstate: auto-install missing base snaps [08:24] sorry about that :) [08:25] no worries [08:25] Chipaca: ? it cannot fail that way on 3881 [08:26] pedronis: this is off master [08:26] or, yesterday evening's master at least [08:26] Chipaca: well we made 3881 related to that [08:27] 3881 is a combination of PRs [08:27] to try to make that test saner [08:27] at this point we are more interested if it fails on 3881 [08:27] not master [08:30] pedronis: ah ok [08:30] pedronis: i was just running tests on snapstate for the revert work and kept on tripping that one up [08:30] try 3881 please [08:32] zyga-solus: why do you appreciate full sentences in comments ? that rule is mentioned in effective go for doc comments [08:32] pedronis: as in, rebase on it and carry on doing my thing? [08:33] Chipaca: are you trolling again ? :) [08:33] I don't if you can carry [08:33] it might not fix things for you [08:33] pedronis: no! i came across that panic by doing my thing on master, do you want me to rebase on 3881 and carry on (and let you know if i see the error again), or do you want me to actively pursue the bug? [08:34] which bug? [08:34] the panic [08:34] pedronis: do you think 1715824 might be something I could add to the store? it seems pretty trivial and I would love to see it getting done asap [08:34] Chipaca: panic in snapstate_test.go:77 ? that is fixed with 3881 [08:34] Chipaca: that panic is probably the test taking to long for you [08:34] ok, so no need for me to try it; i can just ignore it [08:35] Chipaca: I asked it to try, if you hit the bug you tell us [08:35] Chipaca: sorry, it sounded like it was blocking your work [08:35] ah! no [08:36] this is a little gem from my work: [08:36] s.testRevertTasksFullFlags(flags, flags, flags, flags, c) [08:36] * Chipaca grins and carries on [08:41] * zyga-solus_ goes to fix the test suite on golang 1.9 [08:42] davidcalle, wheer in the world is the configure hook described in our docs (i'm searching my ass off, there doesnt even seem to be a mention anywhere) [08:42] mvo: sorry, I missed your message. I'll go ahead and change the polkit action ID. Do you want me to squash the commits too? [08:42] jamesh: we'll just squash merged usually [08:42] *merge [08:45] ogra_: hey, two places for now. https://docs.ubuntu.com/core/en/guides/build-device/config-hooks and https://snapcraft.io/docs/build-snaps/hooks which are being unified + install and remove hooks under the latter. Funny you are asking that right now, because I've spent the week debugging install hooks with pstolowski for this exact purpose [08:45] jamesh: thanks, what pedronis said, we will sqush merge and then I can cherry pick for 2.28 [08:45] ogra_: btw, are you happy with how the two pi images are described on https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 [08:46] davidcalle, perfect ... i hope we can get rid of it eventually :) [08:46] Heh [08:48] the expectation, if you have a snap installed in devmode, is that revert with no devmode would leave you still in devmode, right? [08:48] i.e. snap install foo --devmode; snap refresh --edge foo --devmode; sanp revert foo -> is foo installed in devmode? [08:49] I suppose, but it's a bit of an open question, I mean I have seen it argued differently for other flags at points [08:50] sounds something to clarify with Gustavo once for all when he is back [08:50] now change --devmode to --classic [08:50] :-) [08:50] yea, I have heard incosistent thing about this over time [08:50] I'm not surprised we do random things [08:51] Chipaca: how do you remove --devmode again? [08:51] I shall comment in the forum topic [08:51] pedronis: --jailmode [08:51] I'm looking at the snapcraft source code (specifically the snapcraft.yaml schema), I can't find any reference to the socket activation options (socket, listen-stream). am I looking in the wrong place? [08:51] that's a flag too though? [08:52] pedronis: the refresh itself without --devmode will drop the flag [08:52] Chipaca: how does one get back to all false flags ? [08:52] pedronis: but that doesn't work for jailmode, for example [08:52] Chipaca: ah, refresh is flag dropping? but we want to change that area when we allow devmode refreshes [08:52] only for devmode [08:52] is it dropping [08:52] but see, we are changing that [08:52] what a mess [08:53] :-) [08:53] we need a table [08:53] * Chipaca writes a table [08:53] thanks [08:53] I'm keenly intrested because --ignore-validation shall become sticky and then there are similar questions [08:53] how do you drop it? [08:53] ackk, i think that doesnt exist anymore ... nowadays you just use the network and network-bind interfaces and let your app just do what it needs [08:53] do we need a 2nd flag [08:53] etc [08:53] ackk, these optins in snapcraft.yaml were a 15.04 thing [08:54] ogra_, oh, I saw them mentioned on the website doc [08:54] that might be a bug (not sure) [08:54] Chipaca: see jocave's comment at the end of this bug: https://bugs.launchpad.net/plano/+bug/1710552 [08:54] ogra_, so, what about https://bugs.launchpad.net/snapd/+bug/1612440 ? [08:54] Bug #1612440: Full systemd socket activation support [08:55] Chipaca: I mean, we need a table but hopefully users don't need to consult it [08:55] ogra_, (I was looking at adding the missing keys since we need it for lxd) [08:55] right, the table is for us [08:55] for the coding [08:56] ackk, well, that report is from 2016, not sure these keywords mentioned exist anymore ... you'd have to ask the snapcraft guys on rocket.ubuntu.com (in the #snapcraft channel) === zyga-solus_ is now known as zyga-solus [08:57] ogra_, no I mean, how could we solve that issue (not about the keys specifically), lxd would need socket activation so that the daemon is not started if it's not used [08:57] ackk, note that there was a massive change between 15.04 and 16, where many things got dropped and re-done from scratch, this might be among them ... [08:58] this could be among them ... (read: old implementation was dropped, new one doesnt exist yet) [08:58] I see [08:58] talk to the snapcraft guys [08:59] and perhaps open a topic on the forum (see channel topic for the link) to get wider coverage [08:59] mvo: is the error in tests/main/listing fixed now? because of ~rc2 [09:00] i know that for general socket usage we switched over to the network-bind interface ... but i'm not sure that covers socket activation [09:01] ugh, arch doesn't have "shadow" group anymore [09:01] pedronis: there is a open PR with the fix [09:02] ah [09:04] PR snapd#3888 opened: osutil: adjust StreamCommand tests for golang 1.9 [09:08] mvo: so 3881 has passed travis but has failed many of the other because of the ~rc2 [09:09] mvo: do we just merge it? merge the rc2 fix and run it again? [09:15] pedronis: I can just merge it, maybe thats the bets [09:18] PR snapd#3881 closed: snapstate: give snapmgrTestSuite.settle() more time to settle [09:19] pedronis: best even (sorry, typo) [09:27] Chipaca: look like 3835 just needs a second review and is good to go… [09:28] ogra_: hi, is there any way to debug why splash is not showing? I am seeing uboot first now. Then nothing new shows up until my snap takes over. I've done git diff against your branch and there does not appear anything different in the build process pr snapcraft. So merge looks correct. But no splash :-( [09:28] sborovkov, even with my pre-built snap ? [09:28] (or if you use my default png in your tree) [09:30] * ogra_ needs to go afk for like 20-30min ... brb [09:37] mvo: I tweaked 3888 [09:37] force pushed for easier cherry picking [09:38] zyga-solus: aha, nice [09:38] zyga-solus: small comment maybe why we have the "|" in the regexp [09:38] mvo: and a push to tweak the package description as per #3882 [09:38] PR #3882: debian: improve package description [09:38] ok [09:38] zyga-solus: and feel free to force push [09:38] Chipaca: \o/ [09:39] zyga-solus: could yo finish your review of #3835? [09:39] PR #3835: packaging: bring down the delta between 14.04 and 16.04 [09:39] zyga-solus: thanks a lot! [09:39] done [09:39] looks like travis is currently slow in giving us jobs :/ [09:39] mvo: yes [09:39] mvo: :/ [09:39] also yesterday [09:39] yeah [09:39] must be Friday [09:40] it was Thursday [09:40] mvo it has been slow for us too [09:40] we should probably try to merge a bunch [09:40] before adding more [09:40] mvo: I'm struggling with cmd/snap-seccomp tests, unfortunately it seems that the only user/group we can rely on is "0/root" [09:40] mvo: shadow is not even present on arch and various other users/groups have random values [09:41] zyga-solus: isn't adm also defined in the FHS or somewhere? but yeah, passwd is a mess [09:41] mvo: yes but there's no fixed value [09:42] in any case, I can distro-patch for arch for now [09:42] and ponder without rush [09:42] I need to break for taxes now [09:43] mvo: is the snapctl get change in 2.28 ? [09:44] or only edge? [09:44] pedronis: what change is that? [09:44] pstolowski's PR [09:47] PR snapcraft#1538 closed: tests: update the store failure tests [09:47] pedronis: you mean 3642? that is master [09:47] pedronis: do we need it for 2.28? [09:48] ogra_: yeah I tried with default png as well, does not work. Where can I get prebuilt snap? I can try it I guess [09:49] mvo: no, but it might have broke stuff [09:49] indirectly [09:49] in which case we might have had a regression [09:49] but is not yet in 2.28 [09:50] anyway [09:51] ok [09:53] travis is very non helpful [09:53] ogra_: ah, right in the bug. Going to try it [09:54] mvo: see internal [09:55] Chipaca: hey, perhaps interesting: https://github.com/posener/complete [09:55] pedronis: that rule == the rule to use full sentences or not to use them? [10:03] zyga-suse: yes, just curious, as far as I know our non doc comments are all over the place [10:10] re [10:10] zyga-suse: as I said I see it as strict rule for doc comments [10:10] ogra_: alright, it works with your prebuilt snap. thought it does not scale good [10:12] well, i assume you want to use a smaller png anyway :) [10:12] sborovkov, so to debug this ... attach serial to your pi ... add "break=premount" to the end of the line in cmdline.txt ... then boot and you should get a shell prompt where you then can run /bin/psplash manually and such [10:13] i.e. inside the initrd [10:14] ogra_: that's how it looks like btw https://www.dropbox.com/s/2fbdrd8wg4coudj/photo_2017-09-08_13-13-06.jpg?dl=0 [10:14] sborovkov, heh, you are on a *eally* low resolution :) [10:14] *really [10:15] ogra_: ehh, I don't have working serial at the moment. Ordered one from aliexpress recently. For some reason they sent me USB stick lol. Viktor has it, so may be he will debug it. I will try to figure out what else can be different in our snaps [10:15] yeah it does not detect that my monitor is 1080p, I have to manuallt adjust hdmi_group and hdmi_mode [10:15] sborovkov, might be that we need to adjust the psplash patch for you to actually default to a lower res ... [10:16] oh, you guys actually tinker with config.txt settings for hdmi [10:16] ogra_: the thing though is that Rpi zero has lower resolution [10:16] that might inded have some influence on what info the framebuffer device gives to psplash [10:16] oh! [10:16] interesting [10:17] that's what I have in config.txt [10:17] one sec [10:17] oour default pi gadgets dont set anything in that regard [10:17] https://hastebin.com/higumepuqa.makefile [10:18] framebuffer_height=0 [10:18] framebuffer_width=0 [10:18] framebuffer_ignore_alpha=1 [10:18] i need fb_ignore_alpha for sure though [10:18] the png is clearly using an alpha channel ... [10:18] well, and make your own guess about width and height :) [10:19] qt apps have horrible banding if it's not set [10:19] alpha is not necessary for us anyway I guess [10:19] so height and width [10:19] sure, but if there is an alpha channel in the png it will be used i guess [10:19] so when doing your own splash, try to have an alpha-less png [10:20] but i'D start with the width/height fist ... [10:20] *first [10:20] try dropping them in your own build and see if that changes something [10:20] yup that's what I am trying now [10:20] hmm, also ... hdmi_mode=0 ... [10:20] that might alsoo be a prob [10:22] hmm [10:22] I can comment that out as well [10:22] try the width/height standallone first [10:22] that might already solve it [10:22] ok [10:23] Chipaca: can you look at #3886 I think it's reasonable but not great (it tests less) [10:23] PR #3886: tests: make TestCmdWatch more robust [10:23] if niot we can move ove the other options ... (and then think about hoow to modify psplash to work with your setup) [10:24] pedronis: not right now, sorry [10:24] * ogra_ wonders if he'll need a new kbd soon ... seems to swallow some chars and others are duplicated even when i only press the key once [10:24] too much state [10:24] later [10:25] * ogra_ notes that cherry switches dont seem to be what they used to be ... [10:25] mvo: do we share limits with spread-cron? is it scheduling too much: https://travis-ci.org/snapcore/spread-cron/builds [10:33] pedronis I wonder if we are hit by this given we are in the same org... [10:34] there is a shared pool of travis runners at the project/repo level, not sure if there is also tie in to the org === ShalokShalom_ is now known as ShalokShalom [10:46] PR snapd#3889 opened: interfaces: mount host system fonts in desktop interface [10:50] pedronis: that sounds likely actually - we are the same org [10:52] ogra_: hmm, no, just commenting out those changes did not help. I am also getting warning about misaligned buffer address right after "reading psplash.img", not sure if that's relevant though [10:53] sborovkov, that is a "normal" discepancy between uboot and the kernels FAT implementations ... nothing to worry about [10:53] sborovkov, so try dropping more from config.txt [10:53] i'd move on with the hdmi_mode [10:56] * zyga-solus lunch [10:59] * ogra_ sighs ... [11:00] i wishh i'd understand why zyga-solus's overzealous quoting broke resize fo GPT's [11:12] ok, i'm stopping for lunch [11:12] * ogra_ cries [11:12] https://docs.google.com/spreadsheets/d/1jw-hsAK1ymUfpnI7MD7ML7CQcwq0KSBvGw_gf6_TmYM/edit <- if you want to have fun [11:13] where "fun" means "gouge your frontal lobe out with a blunt weapon" [11:13] (there's a forum post in the works to explain that sheet) [11:13] (i know how to fix it but i dont know why it breaks at all in the first place ) [11:13] :( [11:21] I'm trying to get a heisenbug resolved. the program runs normally when using either strace or gdb, but fails as soon as I try it normally [11:22] ogra_: this is your fault. I'm working on ring [11:22] :-p [11:22] just package it with strace in the snap and add strace to the wrapper script :P [11:22] lol [11:22] diddledan, i fear we have to wait for working dbus activation [11:22] I think that's not quite the right way to do things :-p [11:22] i... might have actually shipped something that ran under strace, once [11:23] * Chipaca was young and needed the money [11:23] Chipaca, how good is your shell-quoting-fu ? [11:23] ogra_: 7 [11:23] mmh, travis has this on their status page: Build delays due to GitHub outage [11:23] damn, I'm only 6 [11:24] github?? dead??! [11:24] https://www.youtube.com/watch?v=kLzC3nPhUEM [11:24] ogra_: enough to know that "$PATH:${GOBIN:-${GOPATH%%:*}/bin}" is valid sh, but not enough to know not to use it [11:24] Chipaca, when zyga-solus added shellchek he also added a lot of quoting to our resize script http://paste.ubuntu.com/25489386/ ... as you can see in line 28 there is "$resizeopts" [11:25] mhmm [11:25] Chipaca, in case of gpt's resizeopts is unset while for mbr's we have resizeopts="-f" [11:25] yes [11:25] and [11:25] that's a bug [11:25] probably [11:26] now ... when trying to resize a gpt devices it ends up like: [11:26] because, i imagine, resize2fs does not know what to do with an empty argument [11:26] resize2fs 1.42.13 (17-May-2015) [11:26] open: No such file or directory while opening [11:26] and i dont get why [11:26] ogra_: try this: resize2fs "" [11:26] but it isnt an empty argument [11:26] hmm [11:26] ogra@localhost:~$ resize2fs "" /dev/mmcblk1p9 [11:26] resize2fs 1.42.13 (17-May-2015) [11:26] open: No such file or directory while opening [11:26] ogra@localhost:~$ [11:27] wow [11:27] * Chipaca bows [11:27] but that looks rather like a bug in resize2fs [11:27] why? it's literally being passed an empty string as an argument [11:27] it's perfectly valid to error out on that [11:27] why would it interpret "" ass an arg [11:27] I agree, let them fix it :-p [11:27] ogra_: it's not "interpreting", it's being given that as an arg [11:28] but it isnt even an empty string ... it is a string of zero lenght [11:28] you're explicitly giving it an empty argument [11:28] that's who the shell works [11:28] s/who/how/ [11:28] ogra_: what is the difference between an empty string and a string of zero length? [11:29] i'd expect the latter to be filtered when parsing args [11:29] that's not how things works [11:29] usually [11:29]