| SXX | Why could std::system in my app fail with "Bad system call" when apparmor is in enforce mode? | 00:06 |
|---|---|---|
| SXX | Oh yeah, totally missed one fact. | 00:06 |
| SXX | What is the right way to run another app from within same snap package if they require different plugs? | 00:08 |
| SXX | 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:09 |
| SXX | Yeah that's was it. | 00:13 |
| mup | PR snapcraft#1414 closed: cmake plugin: call the cmake using build dir as source <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1414> | 00:54 |
| zyga-solus | good morning | 04:48 |
| zyga-solus | mvo: hello | 06:21 |
| zyga-solus | mvo: I'm going to walk kids to school one more time today | 06:21 |
| zyga-solus | mvo: but I left you some interesting topics on the forum | 06:21 |
| zyga-solus | mvo: I can also give you a shell on the ppc box in case you get curious to try | 06:21 |
| zyga-solus | mvo: I'll talk to you soon | 06:22 |
| mup | PR snapcraft#1538 opened: tests: update the store failure tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1538> | 06:22 |
| mvo | zyga-solus: thanks, see you | 06:23 |
| mup | PR snapd#3885 opened: tests: improve the listing test to not fail for e.g. 2.28~rc2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3885> | 06:26 |
| mup | PR snapd#3886 opened: tests: make TestCmdWatch more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/3886> | 06:36 |
| mvo | jamesh: hey, I think your polkit PR is good to go if we rename the name from "manage-snaps" to just "manage" for now. | 06:45 |
| zyga-solus | re | 07:20 |
| zyga-solus | mvo: did you see the ppc situation? | 07:21 |
| mvo | zyga-solus: yes, "funny" | 07:25 |
| zyga-solus | mvo: what are your thoughts on that? | 07:25 |
| mvo | 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 |
| zyga-solus | mvo: I tried to build master but got a lot of errors on get-deps | 07:25 |
| mvo | zyga-solus: but I personally think we should kill it | 07:25 |
| zyga-solus | mvo: if you want I can give you a shell on the box | 07:26 |
| zyga-solus | mvo: yes, I agree | 07:26 |
| mvo | zyga-solus: oh, really? | 07:26 |
| zyga-solus | mvo: but I'm afraid we cannot kill it in xenial yet :/ | 07:26 |
| zyga-solus | mvo: sure, one sec | 07:26 |
| zyga-solus | brace yourself for irony | 07:26 |
| zyga-solus | # github.com/kardianos/govendor/vendor/golang.org/x/sys/unix | 07:26 |
| zyga-solus | ../../kardianos/govendor/vendor/golang.org/x/sys/unix/dirent.go:16:5: error: reference to undefined name ‘isBigEndian’ | 07:26 |
| zyga-solus | if isBigEndian { | 07:26 |
| zyga-solus | (there's 1000s of errors) | 07:26 |
| zyga-solus | there are* 1000s of errors | 07:26 |
| zyga-solus | this is just one | 07:26 |
| zyga-solus | I think that x/sys/unix is broken on ppc somehow | 07:27 |
| mvo | zyga-solus: hm, strange, I mean, the debs build | 07:29 |
| mvo | zyga-solus: and we reverted to dependencies that do not require x/sys/unix iirc | 07:29 |
| mvo | zyga-solus: quick review on 3881 would be great, that should fix builds on arm/ppc | 07:33 |
| zyga-solus | great, let me look | 07:33 |
| Chipaca | o/ | 07:43 |
| ackk | hi, I'm hitting https://bugs.launchpad.net/snapd/+bug/1691999, does anyone know what could be causing it? | 07:45 |
| mup | Bug #1691999: Snap removal hangs inside LXD container <snapd:New> <https://launchpad.net/bugs/1691999> | 07:45 |
| zyga-solus | ackk: hey, I think I know | 07:49 |
| zyga-solus | ackk: it's a known issue, there's no fix yet I'm afraid | 07:50 |
| ackk | zyga-solus, uh? | 07:50 |
| zyga-solus | ackk: there's a bug report with extra details... | 07:50 |
| ackk | does that mean snaps inside lxd won't work? | 07:50 |
| zyga-solus | it works but that part is broken | 07:50 |
| zyga-solus | https://bugs.launchpad.net/snapd/+bug/1712930 | 07:51 |
| mup | Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:In Progress by zyga> <https://launchpad.net/bugs/1712930> | 07:51 |
| ackk | zyga-solus, can you please mark my bug as duplicate ? | 07:51 |
| zyga-solus | sure, which one? | 07:51 |
| zyga-solus | ah | 07:51 |
| ackk | the one I just pasted | 07:51 |
| zyga-solus | done | 07:52 |
| ackk | zyga-solus, thanks | 07:53 |
| ackk | zyga-solus, unrelated, does snapd keep all old revisions of a snap when it gets updated or is there a limit? | 07:53 |
| ackk | I noticed I have 3 versions of core installed | 07:53 |
| zyga-solus | that's normal, snapd keeps three revisions of each snap around | 07:55 |
| ackk | ah cool, thanks | 07:55 |
| mvo | zyga-solus: master is failing on powerpc with new failure modes, its a bit of a whack-a-mole | 07:59 |
| ogra_ | 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:00 |
| ppisati | ogra_: ah! i saw some movement in the kernel snap store | 08:01 |
| ppisati | ogra_: np, just tell me if you need anything | 08:01 |
| ogra_ | yeah,. sorry, cachio was desparate since he needed to get core tested | 08:01 |
| ppisati | ogra_: that means it affects all images, right? | 08:02 |
| Chipaca | hmm, just had snapmgrTestSuite.TestInstallWithoutCoreTwoSnapsWithFailureRunThrough fail at random | 08:02 |
| ogra_ | 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 |
| ppisati | ouch | 08:02 |
| ogra_ | ppisati, only the opnes with GPT table ... | 08:02 |
| ppisati | ogra_: ok | 08:02 |
| ogra_ | which means well ... only dragonboard or x86 on real devices | 08:03 |
| ogra_ | and the latter doesnt get tested at all | 08:03 |
| ogra_ | (x86 always only gets tested with qemu and there we dont esize) | 08:03 |
| ogra_ | zyga-solus, pong ... :P ... what should i start to build ? | 08:06 |
| Chipaca | youch, that test takes 15s+ even when it passes | 08:06 |
| ogra_ | mvo, as i said yesterday already, we have never built on powerpc, only ppc64el ... whats the reason fr suddenly starting to support it ? | 08:07 |
| zyga-solus | ogra_: sec, on the phone | 08:08 |
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| mvo | ogra_: if we make the "not support it" official we could stop spending time of fixing tests etc | 08:10 |
| mvo | ogra_: thats where this comes from | 08:10 |
| ogra_ | mvo, it has alwaysd been official | 08:14 |
| ogra_ | mvo, we always had 6 arches since day one ... powerrpc hasnt been one of them | 08:15 |
| mvo | ogra_: also in the sense that the distro knows that a broken powerpc build does not block a sru? | 08:15 |
| ogra_ | 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:15 |
| ogra_ | on request of mark initially IIRC | 08:16 |
| ogra_ | the only power arch we ever supported was ppc64el | 08:16 |
| Chipaca | pedronis: http://pastebin.ubuntu.com/25488612/ might be of interest to you (happens every ~100 runs, here) | 08:17 |
| ogra_ | we have 4 arches we build images for (2xarm, 2xx86) and 2 arches we onyl build core for (s390x and ppc64el) | 08:17 |
| ogra_ | and we never built for any other arches ... | 08:17 |
| ogra_ | 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:18 |
| zyga-solus | re | 08:22 |
| * zyga-solus spent too much time on the phone and needs to spend more time with administrativa, sorry | 08:22 | |
| zyga-solus | mvo: tests need tweaking | 08:23 |
| zyga-solus | 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 |
| zyga-solus | mvo: listing tests now fails on the ~rc2 | 08:23 |
| mvo | zyga-solus: check the open PRs ;) | 08:24 |
| zyga-solus | mvo: aha :) | 08:24 |
| mup | PR snapd#3887 opened: snapstate: auto-install missing base snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3887> | 08:24 |
| zyga-solus | sorry about that :) | 08:24 |
| mvo | no worries | 08:25 |
| pedronis | Chipaca: ? it cannot fail that way on 3881 | 08:25 |
| Chipaca | pedronis: this is off master | 08:26 |
| Chipaca | or, yesterday evening's master at least | 08:26 |
| pedronis | Chipaca: well we made 3881 related to that | 08:26 |
| pedronis | 3881 is a combination of PRs | 08:27 |
| pedronis | to try to make that test saner | 08:27 |
| pedronis | at this point we are more interested if it fails on 3881 | 08:27 |
| pedronis | not master | 08:27 |
| Chipaca | pedronis: ah ok | 08:30 |
| Chipaca | pedronis: i was just running tests on snapstate for the revert work and kept on tripping that one up | 08:30 |
| pedronis | try 3881 please | 08:30 |
| pedronis | zyga-solus: why do you appreciate full sentences in comments ? that rule is mentioned in effective go for doc comments | 08:32 |
| Chipaca | pedronis: as in, rebase on it and carry on doing my thing? | 08:32 |
| pedronis | Chipaca: are you trolling again ? :) | 08:33 |
| pedronis | I don't if you can carry | 08:33 |
| pedronis | it might not fix things for you | 08:33 |
| Chipaca | 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:33 |
| pedronis | which bug? | 08:34 |
| Chipaca | the panic | 08:34 |
| mvo | 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 |
| mvo | Chipaca: panic in snapstate_test.go:77 ? that is fixed with 3881 | 08:34 |
| pedronis | Chipaca: that panic is probably the test taking to long for you | 08:34 |
| Chipaca | ok, so no need for me to try it; i can just ignore it | 08:34 |
| pedronis | Chipaca: I asked it to try, if you hit the bug you tell us | 08:35 |
| pedronis | Chipaca: sorry, it sounded like it was blocking your work | 08:35 |
| Chipaca | ah! no | 08:35 |
| Chipaca | this is a little gem from my work: | 08:36 |
| Chipaca | s.testRevertTasksFullFlags(flags, flags, flags, flags, c) | 08:36 |
| * Chipaca grins and carries on | 08:36 | |
| * zyga-solus_ goes to fix the test suite on golang 1.9 | 08:41 | |
| ogra_ | 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 |
| jamesh | 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 |
| pedronis | jamesh: we'll just squash merged usually | 08:42 |
| pedronis | *merge | 08:42 |
| davidcalle | 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 |
| mvo | jamesh: thanks, what pedronis said, we will sqush merge and then I can cherry pick for 2.28 | 08:45 |
| davidcalle | 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:45 |
| ogra_ | davidcalle, perfect ... i hope we can get rid of it eventually :) | 08:46 |
| davidcalle | Heh | 08:46 |
| Chipaca | 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 |
| Chipaca | i.e. snap install foo --devmode; snap refresh --edge foo --devmode; sanp revert foo -> is foo installed in devmode? | 08:48 |
| pedronis | 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:49 |
| pedronis | sounds something to clarify with Gustavo once for all when he is back | 08:50 |
| Chipaca | now change --devmode to --classic | 08:50 |
| Chipaca | :-) | 08:50 |
| pedronis | yea, I have heard incosistent thing about this over time | 08:50 |
| pedronis | I'm not surprised we do random things | 08:50 |
| pedronis | Chipaca: how do you remove --devmode again? | 08:51 |
| Chipaca | I shall comment in the forum topic | 08:51 |
| Chipaca | pedronis: --jailmode | 08:51 |
| ackk | 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 |
| pedronis | that's a flag too though? | 08:51 |
| Chipaca | pedronis: the refresh itself without --devmode will drop the flag | 08:52 |
| pedronis | Chipaca: how does one get back to all false flags ? | 08:52 |
| Chipaca | pedronis: but that doesn't work for jailmode, for example | 08:52 |
| pedronis | Chipaca: ah, refresh is flag dropping? but we want to change that area when we allow devmode refreshes | 08:52 |
| Chipaca | only for devmode | 08:52 |
| Chipaca | is it dropping | 08:52 |
| pedronis | but see, we are changing that | 08:52 |
| pedronis | what a mess | 08:52 |
| Chipaca | :-) | 08:53 |
| Chipaca | we need a table | 08:53 |
| * Chipaca writes a table | 08:53 | |
| pedronis | thanks | 08:53 |
| pedronis | I'm keenly intrested because --ignore-validation shall become sticky and then there are similar questions | 08:53 |
| pedronis | how do you drop it? | 08:53 |
| ogra_ | 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 |
| pedronis | do we need a 2nd flag | 08:53 |
| pedronis | etc | 08:53 |
| ogra_ | ackk, these optins in snapcraft.yaml were a 15.04 thing | 08:53 |
| ackk | ogra_, oh, I saw them mentioned on the website doc | 08:54 |
| ogra_ | that might be a bug (not sure) | 08:54 |
| pedronis | Chipaca: see jocave's comment at the end of this bug: https://bugs.launchpad.net/plano/+bug/1710552 | 08:54 |
| ackk | ogra_, so, what about https://bugs.launchpad.net/snapd/+bug/1612440 ? | 08:54 |
| mup | Bug #1612440: Full systemd socket activation support <lxd> <Snapcraft:New> <snapd:Confirmed> <https://launchpad.net/bugs/1612440> | 08:54 |
| pedronis | Chipaca: I mean, we need a table but hopefully users don't need to consult it | 08:55 |
| ackk | ogra_, (I was looking at adding the missing keys since we need it for lxd) | 08:55 |
| Chipaca | right, the table is for us | 08:55 |
| Chipaca | for the coding | 08:55 |
| ogra_ | 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) | 08:56 |
| === zyga-solus_ is now known as zyga-solus | ||
| ackk | 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 |
| ogra_ | 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:57 |
| ogra_ | this could be among them ... (read: old implementation was dropped, new one doesnt exist yet) | 08:58 |
| ackk | I see | 08:58 |
| ogra_ | talk to the snapcraft guys | 08:58 |
| ogra_ | and perhaps open a topic on the forum (see channel topic for the link) to get wider coverage | 08:59 |
| pedronis | mvo: is the error in tests/main/listing fixed now? because of ~rc2 | 08:59 |
| ogra_ | 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:00 |
| zyga-solus | ugh, arch doesn't have "shadow" group anymore | 09:01 |
| mvo | pedronis: there is a open PR with the fix | 09:01 |
| pedronis | ah | 09:02 |
| mup | PR snapd#3888 opened: osutil: adjust StreamCommand tests for golang 1.9 <Created by zyga> <https://github.com/snapcore/snapd/pull/3888> | 09:04 |
| pedronis | mvo: so 3881 has passed travis but has failed many of the other because of the ~rc2 | 09:08 |
| pedronis | mvo: do we just merge it? merge the rc2 fix and run it again? | 09:09 |
| mvo | pedronis: I can just merge it, maybe thats the bets | 09:15 |
| mup | PR snapd#3881 closed: snapstate: give snapmgrTestSuite.settle() more time to settle <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3881> | 09:18 |
| mvo | pedronis: best even (sorry, typo) | 09:19 |
| mvo | Chipaca: look like 3835 just needs a second review and is good to go… | 09:27 |
| sborovkov | 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 |
| ogra_ | sborovkov, even with my pre-built snap ? | 09:28 |
| ogra_ | (or if you use my default png in your tree) | 09:28 |
| * ogra_ needs to go afk for like 20-30min ... brb | 09:30 | |
| zyga-solus | mvo: I tweaked 3888 | 09:37 |
| zyga-solus | force pushed for easier cherry picking | 09:37 |
| mvo | zyga-solus: aha, nice | 09:38 |
| mvo | zyga-solus: small comment maybe why we have the "|" in the regexp | 09:38 |
| Chipaca | mvo: and a push to tweak the package description as per #3882 | 09:38 |
| mup | PR #3882: debian: improve package description <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3882> | 09:38 |
| zyga-solus | ok | 09:38 |
| mvo | zyga-solus: and feel free to force push | 09:38 |
| mvo | Chipaca: \o/ | 09:38 |
| Chipaca | zyga-solus: could yo finish your review of #3835? | 09:39 |
| mup | PR #3835: packaging: bring down the delta between 14.04 and 16.04 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3835> | 09:39 |
| mvo | zyga-solus: thanks a lot! | 09:39 |
| zyga-solus | done | 09:39 |
| mvo | looks like travis is currently slow in giving us jobs :/ | 09:39 |
| zyga-solus | mvo: yes | 09:39 |
| zyga-solus | mvo: :/ | 09:39 |
| pedronis | also yesterday | 09:39 |
| mvo | yeah | 09:39 |
| zyga-solus | must be Friday | 09:39 |
| pedronis | it was Thursday | 09:40 |
| sergiusens | mvo it has been slow for us too | 09:40 |
| pedronis | we should probably try to merge a bunch | 09:40 |
| pedronis | before adding more | 09:40 |
| zyga-solus | 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 |
| zyga-solus | mvo: shadow is not even present on arch and various other users/groups have random values | 09:40 |
| mvo | zyga-solus: isn't adm also defined in the FHS or somewhere? but yeah, passwd is a mess | 09:41 |
| zyga-solus | mvo: yes but there's no fixed value | 09:41 |
| zyga-solus | in any case, I can distro-patch for arch for now | 09:42 |
| zyga-solus | and ponder without rush | 09:42 |
| zyga-solus | I need to break for taxes now | 09:42 |
| pedronis | mvo: is the snapctl get change in 2.28 ? | 09:43 |
| pedronis | or only edge? | 09:44 |
| mvo | pedronis: what change is that? | 09:44 |
| pedronis | pstolowski's PR | 09:44 |
| mup | PR snapcraft#1538 closed: tests: update the store failure tests <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1538> | 09:47 |
| mvo | pedronis: you mean 3642? that is master | 09:47 |
| mvo | pedronis: do we need it for 2.28? | 09:47 |
| sborovkov | 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:48 |
| pedronis | mvo: no, but it might have broke stuff | 09:49 |
| pedronis | indirectly | 09:49 |
| pedronis | in which case we might have had a regression | 09:49 |
| pedronis | but is not yet in 2.28 | 09:49 |
| pedronis | anyway | 09:50 |
| mvo | ok | 09:51 |
| pedronis | travis is very non helpful | 09:53 |
| sborovkov | ogra_: ah, right in the bug. Going to try it | 09:53 |
| pedronis | mvo: see internal | 09:54 |
| zyga-suse | Chipaca: hey, perhaps interesting: https://github.com/posener/complete | 09:55 |
| zyga-suse | pedronis: that rule == the rule to use full sentences or not to use them? | 09:55 |
| pedronis | zyga-suse: yes, just curious, as far as I know our non doc comments are all over the place | 10:03 |
| ogra_ | re | 10:10 |
| pedronis | zyga-suse: as I said I see it as strict rule for doc comments | 10:10 |
| sborovkov | ogra_: alright, it works with your prebuilt snap. thought it does not scale good | 10:10 |
| ogra_ | well, i assume you want to use a smaller png anyway :) | 10:12 |
| ogra_ | 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:12 |
| ogra_ | i.e. inside the initrd | 10:13 |
| sborovkov | 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 |
| ogra_ | sborovkov, heh, you are on a *eally* low resolution :) | 10:14 |
| ogra_ | *really | 10:14 |
| sborovkov | 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 |
| sborovkov | yeah it does not detect that my monitor is 1080p, I have to manuallt adjust hdmi_group and hdmi_mode | 10:15 |
| ogra_ | sborovkov, might be that we need to adjust the psplash patch for you to actually default to a lower res ... | 10:15 |
| ogra_ | oh, you guys actually tinker with config.txt settings for hdmi | 10:16 |
| sborovkov | ogra_: the thing though is that Rpi zero has lower resolution | 10:16 |
| ogra_ | that might inded have some influence on what info the framebuffer device gives to psplash | 10:16 |
| sborovkov | oh! | 10:16 |
| sborovkov | interesting | 10:16 |
| sborovkov | that's what I have in config.txt | 10:17 |
| sborovkov | one sec | 10:17 |
| ogra_ | oour default pi gadgets dont set anything in that regard | 10:17 |
| sborovkov | https://hastebin.com/higumepuqa.makefile | 10:17 |
| ogra_ | framebuffer_height=0 | 10:18 |
| ogra_ | framebuffer_width=0 | 10:18 |
| ogra_ | framebuffer_ignore_alpha=1 | 10:18 |
| sborovkov | i need fb_ignore_alpha for sure though | 10:18 |
| ogra_ | the png is clearly using an alpha channel ... | 10:18 |
| ogra_ | well, and make your own guess about width and height :) | 10:18 |
| sborovkov | qt apps have horrible banding if it's not set | 10:19 |
| sborovkov | alpha is not necessary for us anyway I guess | 10:19 |
| sborovkov | so height and width | 10:19 |
| ogra_ | sure, but if there is an alpha channel in the png it will be used i guess | 10:19 |
| ogra_ | so when doing your own splash, try to have an alpha-less png | 10:19 |
| ogra_ | but i'D start with the width/height fist ... | 10:20 |
| ogra_ | *first | 10:20 |
| ogra_ | try dropping them in your own build and see if that changes something | 10:20 |
| sborovkov | yup that's what I am trying now | 10:20 |
| ogra_ | hmm, also ... hdmi_mode=0 ... | 10:20 |
| ogra_ | that might alsoo be a prob | 10:20 |
| sborovkov | hmm | 10:22 |
| sborovkov | I can comment that out as well | 10:22 |
| ogra_ | try the width/height standallone first | 10:22 |
| ogra_ | that might already solve it | 10:22 |
| sborovkov | ok | 10:22 |
| pedronis | Chipaca: can you look at #3886 I think it's reasonable but not great (it tests less) | 10:23 |
| mup | PR #3886: tests: make TestCmdWatch more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/3886> | 10:23 |
| ogra_ | if niot we can move ove the other options ... (and then think about hoow to modify psplash to work with your setup) | 10:23 |
| Chipaca | 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 | |
| Chipaca | too much state | 10:24 |
| Chipaca | later | 10:24 |
| * ogra_ notes that cherry switches dont seem to be what they used to be ... | 10:25 | |
| pedronis | mvo: do we share limits with spread-cron? is it scheduling too much: https://travis-ci.org/snapcore/spread-cron/builds | 10:25 |
| sergiusens | pedronis I wonder if we are hit by this given we are in the same org... | 10:33 |
| sergiusens | there is a shared pool of travis runners at the project/repo level, not sure if there is also tie in to the org | 10:34 |
| === ShalokShalom_ is now known as ShalokShalom | ||
| mup | PR snapd#3889 opened: interfaces: mount host system fonts in desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3889> | 10:46 |
| mvo | pedronis: that sounds likely actually - we are the same org | 10:50 |
| sborovkov | 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:52 |
| ogra_ | sborovkov, that is a "normal" discepancy between uboot and the kernels FAT implementations ... nothing to worry about | 10:53 |
| ogra_ | sborovkov, so try dropping more from config.txt | 10:53 |
| ogra_ | i'd move on with the hdmi_mode | 10:53 |
| * zyga-solus lunch | 10:56 | |
| * ogra_ sighs ... | 10:59 | |
| ogra_ | i wishh i'd understand why zyga-solus's overzealous quoting broke resize fo GPT's | 11:00 |
| Chipaca | ok, i'm stopping for lunch | 11:12 |
| * ogra_ cries | 11:12 | |
| Chipaca | https://docs.google.com/spreadsheets/d/1jw-hsAK1ymUfpnI7MD7ML7CQcwq0KSBvGw_gf6_TmYM/edit <- if you want to have fun | 11:12 |
| Chipaca | where "fun" means "gouge your frontal lobe out with a blunt weapon" | 11:13 |
| Chipaca | (there's a forum post in the works to explain that sheet) | 11:13 |
| ogra_ | (i know how to fix it but i dont know why it breaks at all in the first place ) | 11:13 |
| ogra_ | :( | 11:13 |
| diddledan | 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:21 |
| diddledan | ogra_: this is your fault. I'm working on ring | 11:22 |
| diddledan | :-p | 11:22 |
| ogra_ | just package it with strace in the snap and add strace to the wrapper script :P | 11:22 |
| diddledan | lol | 11:22 |
| ogra_ | diddledan, i fear we have to wait for working dbus activation | 11:22 |
| diddledan | I think that's not quite the right way to do things :-p | 11:22 |
| Chipaca | i... might have actually shipped something that ran under strace, once | 11:22 |
| * Chipaca was young and needed the money | 11:23 | |
| ogra_ | Chipaca, how good is your shell-quoting-fu ? | 11:23 |
| Chipaca | ogra_: 7 | 11:23 |
| pedronis | mmh, travis has this on their status page: Build delays due to GitHub outage | 11:23 |
| diddledan | damn, I'm only 6 | 11:23 |
| diddledan | github?? dead??! | 11:24 |
| diddledan | https://www.youtube.com/watch?v=kLzC3nPhUEM | 11:24 |
| Chipaca | ogra_: enough to know that "$PATH:${GOBIN:-${GOPATH%%:*}/bin}" is valid sh, but not enough to know not to use it | 11:24 |
| ogra_ | 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:24 |
| Chipaca | mhmm | 11:25 |
| ogra_ | Chipaca, in case of gpt's resizeopts is unset while for mbr's we have resizeopts="-f" | 11:25 |
| Chipaca | yes | 11:25 |
| Chipaca | and | 11:25 |
| Chipaca | that's a bug | 11:25 |
| Chipaca | probably | 11:25 |
| ogra_ | now ... when trying to resize a gpt devices it ends up like: | 11:26 |
| Chipaca | because, i imagine, resize2fs does not know what to do with an empty argument | 11:26 |
| ogra_ | resize2fs 1.42.13 (17-May-2015) | 11:26 |
| ogra_ | open: No such file or directory while opening | 11:26 |
| ogra_ | and i dont get why | 11:26 |
| Chipaca | ogra_: try this: resize2fs "" | 11:26 |
| ogra_ | but it isnt an empty argument | 11:26 |
| ogra_ | hmm | 11:26 |
| ogra_ | ogra@localhost:~$ resize2fs "" /dev/mmcblk1p9 | 11:26 |
| ogra_ | resize2fs 1.42.13 (17-May-2015) | 11:26 |
| ogra_ | open: No such file or directory while opening | 11:26 |
| ogra_ | ogra@localhost:~$ | 11:26 |
| ogra_ | wow | 11:27 |
| * Chipaca bows | 11:27 | |
| ogra_ | but that looks rather like a bug in resize2fs | 11:27 |
| Chipaca | why? it's literally being passed an empty string as an argument | 11:27 |
| Chipaca | it's perfectly valid to error out on that | 11:27 |
| ogra_ | why would it interpret "" ass an arg | 11:27 |
| diddledan | I agree, let them fix it :-p | 11:27 |
| Chipaca | ogra_: it's not "interpreting", it's being given that as an arg | 11:27 |
| ogra_ | but it isnt even an empty string ... it is a string of zero lenght | 11:28 |
| Chipaca | you're explicitly giving it an empty argument | 11:28 |
| pedronis | that's who the shell works | 11:28 |
| pedronis | s/who/how/ | 11:28 |
| Chipaca | ogra_: what is the difference between an empty string and a string of zero length? | 11:28 |
| ogra_ | i'd expect the latter to be filtered when parsing args | 11:29 |
| pedronis | that's not how things works | 11:29 |
| pedronis | usually | 11:29 |
| diddledan | you need to conditionally include it: https://paste.ubuntu.com/25489423/ | 11:29 |
| ogra_ | if i'd add " " i'ÄD agree it is an empty string | 11:29 |
| pedronis | that's not an empty string | 11:29 |
| pedronis | it's a 1-space string | 11:29 |
| Chipaca | ogra_: " " is not an empty string ! :-) | 11:29 |
| Chipaca | anyhow! | 11:29 |
| Chipaca | let's move on to how to fix it, yes? | 11:30 |
| ogra_ | diddledan, i need/want to add -p anyway for both resize cases (to get better logs), so the fix is clear | 11:30 |
| ogra_ | diddledan, my prob is that i dont understand the behaviour | 11:30 |
| diddledan | "" is an empty string - which means it is, in C-style "\0" | 11:30 |
| diddledan | i.e. it includes a null termination | 11:31 |
| ogra_ | Chipaca, http://paste.ubuntu.com/25489429/ is my fix ... | 11:31 |
| Chipaca | ogra_: try this: for i in "" "" ""; do printf "%q\n" "$i"; done | 11:31 |
| pedronis | or try rm "" | 11:31 |
| pedronis | it all works the same | 11:31 |
| Chipaca | mhmm | 11:31 |
| ogra_ | yeah, you guys are right .. | 11:32 |
| diddledan | putting quotes on a bash commandline, even with no contents is saying "I want an argument here". If it didn't explicitly create empty arguments then you can't check that a variable is "empty" | 11:33 |
| ogra_ | (i never use quotes for args ... but shellcheck freaks out if you dont) | 11:33 |
| ogra_ | (so i never had to bother with that) | 11:33 |
| pedronis | that's why quoting is not always the right thing | 11:33 |
| Chipaca | ogra_: that's ok, everybody has blind spots | 11:33 |
| ogra_ | tell that to shellcheck :P | 11:33 |
| ogra_ | if there is a $ it wants a quote :) | 11:33 |
| Chipaca | ogra_: you _can_ tell that to shellcheck! | 11:34 |
| ogra_ | i know | 11:34 |
| ogra_ | anyway, i want more verbosity anyway for the logs, so just adding -p for the gpt case is fine | 11:34 |
| Chipaca | ok :-) | 11:34 |
| pedronis | I'm still not sure what adding -p means | 11:34 |
| pedronis | depending it might not solve the problem | 11:34 |
| Chipaca | progress, probably | 11:34 |
| ogra_ | print all actions | 11:34 |
| pedronis | or create new ones | 11:34 |
| ogra_ | it does | 11:35 |
| Chipaca | ummm | 11:35 |
| Chipaca | ogra_: that does not work either! | 11:35 |
| ogra_ | i tested it already | 11:35 |
| pedronis | Chipaca: not what it means to resize2fs, more how it's getting added | 11:35 |
| Chipaca | because there is no option "f -p" | 11:35 |
| ogra_ | bah, crap | 11:35 |
| Chipaca | ogra_: you want "-fp" | 11:35 |
| ogra_ | (i didntz test on mb indeed) | 11:35 |
| pedronis | you cannot quote multiple args together | 11:35 |
| ogra_ | *mb | 11:35 |
| ogra_ | BAH | 11:36 |
| ogra_ | *mbrr | 11:36 |
| pedronis | there are various approaches, it all depends | 11:36 |
| * Chipaca hugs ogra_ | 11:36 | |
| * Chipaca steals ogra_'s wallet | 11:36 | |
| * ogra_ needs a new kbd ... sniff | 11:36 | |
| ogra_ | this kbd isnt a year old yet ... but l and o are producing double presses and r is ignored every now and then | 11:37 |
| Chipaca | ogra_: take the peanut shells out from under the keys | 11:37 |
| pedronis | that's also why "$*" and "$@" are not the same | 11:37 |
| ogra_ | yeah, that i know | 11:37 |
| Chipaca | is the magic expansion of "$@" a bashism, or is that posix? | 11:38 |
| pedronis | so quoting solves some issues, creates other | 11:38 |
| ogra_ | thats poosix afaik | 11:38 |
| Chipaca | and if it's posix, does that mean other shells also have arrays? | 11:38 |
| Chipaca | because arrays would solve the whole thing :) | 11:38 |
| ogra_ | only for args i think | 11:38 |
| Chipaca | bah humbug | 11:38 |
| Chipaca | this is why people use eval | 11:39 |
| ogra_ | mvo, oh, btw ... https://github.com/snapcore/core-build/pull/17 is waiting for your approval (that was the one i was holding back yesterday) | 11:41 |
| mup | PR core-build#17: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17> | 11:41 |
| ogra_ | (i'd like to land that one before the resize fix) | 11:41 |
| pedronis | Chipaca: ogra_: is this bash or something else? | 11:48 |
| ogra_ | pedronis, posix (ash) | 11:48 |
| mvo | ogra_: one question, then good to go. is the resize fix up as well? and what was it? do we need a new release for that? | 11:48 |
| ogra_ | mvo, i'm not sure what channel kernel snaps use to obtain the initrd, if it is stable then yes | 11:49 |
| ogra_ | mvo, i thin Chipaca needs to answer your question on thhe PR ... afaik the dir is empty in the squashfs initially | 11:50 |
| Chipaca | me what? | 11:50 |
| zyga-suse | ogra_: hmm? GPT? quoting? | 11:50 |
| ogra_ | zyga-suse, yep | 11:51 |
| zyga-suse | what did I do? | 11:51 |
| ogra_ | fix is pending, all fine | 11:51 |
| mup | PR snapd#3885 closed: tests: improve the listing test to not fail for e.g. 2.28~rc2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3885> | 11:51 |
| zyga-suse | aha, thank you ! | 11:51 |
| ogra_ | zyga-suse, http://paste.ubuntu.com/25489461/ line 29 ... | 11:51 |
| * mvo grumbles about the amount of travis slots we get | 11:52 | |
| ogra_ | zyga-suse, in GPTs the resizeopts var is unset ... the quoting turns it into an empty arg though | 11:52 |
| ogra_ | Chipaca, https://github.com/snapcore/core-build/pull/17 | 11:52 |
| mup | PR core-build#17: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17> | 11:52 |
| jdstrand | zyga-suse: in snap-seccomp, today there are 3 users/groups we care about: root, daemon and shadow. root and daemon are supposed to exist everywhere based on the LSB. shadow is not guaranteed to exist | 11:52 |
| cjwatson | "" around $ is an excellent heuristic, but you need to use judgement. doesn't shellcheck have a way to override it? | 11:52 |
| zyga-suse | jdstrand: in addition the values of shadow and daemon are not constant | 11:53 |
| mup | PR snapd#3886 closed: tests: make TestCmdWatch more robust <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3886> | 11:53 |
| ogra_ | cjwatson, it does ... but i want the var set in the other case too so it is fine | 11:53 |
| jdstrand | zyga-suse: if 'daemon' is not '1', then we need to use FindGid() for it like we do with shadow in main_test.go | 11:53 |
| ogra_ | cjwatson, my prob was that i didnt understand the fact that "" becoomes an empty arg that gets actually parsed | 11:53 |
| zyga-suse | jdstrand: yes, I think that's a simple fix | 11:53 |
| jdstrand | zyga-suse: if shadow isn't present at all, what is the group for /etc/shadow on arch? | 11:54 |
| cjwatson | if you spend any time working with shell I strongly recommend spending some time understanding how argument handling actually works | 11:54 |
| zyga-suse | jdstrand: root.root | 11:54 |
| zyga-suse | jdstrand: well, root to answer your question | 11:54 |
| jdstrand | well, that's goofy | 11:54 |
| ogra_ | cjwatson, well, before we added shellcheck everywhere i didnt even have the idea to quote in that place | 11:54 |
| cjwatson | yeah but this is quite basic stuff :) | 11:54 |
| * zyga-suse recalls that "someone is wrong on the internet" thing | 11:54 | |
| cjwatson | specifically with relation to the underlying libc's argv handling | 11:55 |
| jdstrand | zyga-suse: ok, so then on arch, in template.go, we make 'shadow' distro-specific | 11:55 |
| jdstrand | zyga-suse: let me put that another way | 11:55 |
| zyga-suse | jdstrand: I'd just use something else, like bin or daemon | 11:55 |
| jdstrand | zyga-suse: I figured that some distros would use a different group for /etc/shadow | 11:55 |
| * zyga-suse listens | 11:55 | |
| cjwatson | shellcheck is absolutely right about this quoting policy in general | 11:56 |
| mup | PR snapcraft#1539 opened: nodejs plugin: expose hidden bin path when using yarn <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1539> | 11:56 |
| jdstrand | zyga-suse: sorry, interfaces/builtin/account_control.go | 11:56 |
| zyga-suse | jdstrand: aha, I see, that part needs to get smarter | 11:57 |
| zyga-suse | jdstrand: what happens if we add two seccomp arg filtering rules? | 11:58 |
| jdstrand | zyga-suse: so, in account_control.go, I figured instead of hard coding 'g:shadow' in the accountControlConnecctedPlugSecComp, we do: 'g:%s', default to 'shadow' and then have a distro mapping for arch to set it to 'root' | 11:58 |
| zyga-suse | jdstrand: yeah, that's doable | 11:58 |
| zyga-suse | ugly but necessary | 11:58 |
| jdstrand | zyga-suse: it isn't ugly | 11:58 |
| zyga-suse | well, ugly as in "it's ugly we need this" | 11:58 |
| jdstrand | zyga-suse: it is what is needed to handle cross-distro | 11:58 |
| jdstrand | well, yes, it would be nice if 'shadow' was standardized, sure | 11:59 |
| zyga-suse | I'll make that patch and once it lands upstream I'll put it into 2.27.6 | 11:59 |
| ogra_ | cjwatson, well, i think using allags="-a -b -c"; command $allargs... is not actually uncommon | 11:59 |
| jdstrand | we're going to see more and more of this sort of thing when cross-distro becomes strict | 11:59 |
| jdstrand | some things we can just add to the policy (oh, /etc/foo is /etc/foo.d on this distro, just allow both), but sometimes we'll want something like this | 12:00 |
| cjwatson | ogra_: Sure, but it's an exception compared to general use of $-expansions | 12:00 |
| ogra_ | indeed | 12:01 |
| pedronis | that where eval is useful sometimes | 12:01 |
| pedronis | it reparses | 12:01 |
| ogra_ | yep | 12:01 |
| cjwatson | IME once you get to that point it's time to rewrite in a language that lets you control the argument list explicitly | 12:01 |
| cjwatson | (and I've written a *lot* of shell - I'm not against its use in principle) | 12:01 |
| jdstrand | zyga-suse: in cmd/snap-seccomp/main_test.go, you'll want to either make the g:shadow tests conditional on 'is !arch', or on 'is ubuntu|debian' or turn the mapping into a function (eg, shadowGroup() exported as ShadowGroup()) | 12:02 |
| jdstrand | zyga-suse: the latter seems best | 12:02 |
| zyga-suse | jdstrand: I agree | 12:02 |
| pedronis | well shellcheck recommendation basically are based on everything coming from the outside | 12:02 |
| zyga-suse | jdstrand: I tried several simpler things but went nowhere and realized this needs to be really dynamic | 12:02 |
| jdstrand | zyga-suse: with those small changes, you should be all set | 12:02 |
| * zyga-suse is a bit sleepy today and nervous about doing taxes for the first time in $eons | 12:03 | |
| ogra_ | is spain tax-free country ? | 12:03 |
| zyga-suse | ogra_: I'm back in Poland now | 12:03 |
| jdstrand | zyga-suse: sorry I wasn't awake when you started on this-- I knew we'd have to do something like this (I think I mentioned it in the PR, but maybe not) | 12:03 |
| zyga-suse | ogra_: managing my own business | 12:03 |
| ogra_ | zyga-suse, yeah, but didnt you do taxes in spain ? | 12:03 |
| zyga-suse | ogra_: yes but I now have to do them in two places | 12:04 |
| pedronis | mvo: are you going to revisit #3865 ? | 12:04 |
| mup | PR #3865: many: provide systemd.MockSystemctl() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3865> | 12:04 |
| zyga-suse | ogra_: my monthly taxes are now in Poland | 12:04 |
| ogra_ | ouch | 12:04 |
| zyga-suse | ogra_: and my yearly taxing will be done in Spain, this one time | 12:04 |
| zyga-suse | ogra_: then next year just here | 12:04 |
| ogra_ | oh my | 12:04 |
| pedronis | double taxes are not fun | 12:04 |
| zyga-suse | not double in the typical word, I only get taxed once | 12:04 |
| * ogra_ guesses you could pay someone doing them for you | 12:04 | |
| zyga-suse | but I must complete the yearly cycle in Spain | 12:05 |
| zyga-suse | as I'm a spanish resident despite being here now | 12:05 |
| zyga-suse | it's decided by the number of days per year one inhabits a given country | 12:05 |
| mvo | ogra_: if you are still unclear about the "why" of the behaviour it might be useful to look at: $ strace -e trace=execve true $a ; strace -e trace=execve true "$a" that might be useful | 12:05 |
| zyga-suse | ogra_: it's not like most people know and I wanted to learn how this works a little bit | 12:05 |
| jdstrand | zyga-suse: I don't think we want to overengineer today cause we don't know for sure what we are going to see as more and more distros go partial/strict, so what I just outlined imo should be all we do now. but, maybe we can have in the back of our mind how to handle this if there are a lot | 12:05 |
| mvo | pedronis: I though I did, let me look at this again | 12:05 |
| ogra_ | mvo, no, i'm fine | 12:05 |
| zyga-suse | jdstrand: I need something basic for now so that unit tests on arch pass again | 12:06 |
| zyga-suse | jdstrand: there's been a wave of updates there | 12:06 |
| ogra_ | mvo, just waiting for an answer from Chipaca on the PR and then i'll prepare the resize one | 12:06 |
| pedronis | mvo: there are a few small comments by me and a conflict | 12:06 |
| zyga-suse | jdstrand: golang 1.9, pulseaudio 11, tons of stuff | 12:06 |
| Chipaca | ogra_: on which pr? | 12:06 |
| ogra_ | (and roll up the deb and do a core ebuild etc etc) | 12:06 |
| mvo | pedronis: yeah, sorry for this, either I forgot to push or I was dreaming that I already fixed it. on it now | 12:06 |
| ogra_ | <ogra_> Chipaca, https://github.com/snapcore/core-build/pull/17 | 12:06 |
| mup | PR core-build#17: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17> | 12:06 |
| jdstrand | zyga-suse: eg, do we want to have the dynamic stuff defined in the interfaces themselves, or do we want to have a distro.go file (or something) which is a one stop shop for these things (eg, it would have shadowGroup() and the mapping, and any other functions like shadowGroup() and their mappings) | 12:07 |
| jdstrand | zyga-suse: fun! | 12:07 |
| zyga-suse | jdstrand: I think distro go is nicer and mirrors our approach for packages in spread tests (also centralized) | 12:07 |
| zyga-suse | jdstrand: though I wonder if we should just stat files in specific modules | 12:07 |
| zyga-suse | jdstrand: and not build and maintain large tables | 12:07 |
| zyga-suse | jdstrand: I'll start small, just to fix unit tests | 12:07 |
| zyga-suse | jdstrand: I'll re-think this when I look at the interface problem | 12:08 |
| Chipaca | ogra_: like so? | 12:08 |
| ogra_ | ?? | 12:08 |
| zyga-suse | jdstrand: note that especially for arch where things move all the time and it might be root.shadow before I land this ;) | 12:08 |
| ogra_ | ah, GH is slow updating | 12:08 |
| jdstrand | zyga-suse: for pulseaudio, I suspect that would just be additional rules (that is what we would do in abstractions/audio, for example) | 12:08 |
| zyga-suse | jdstrand: I need to see what changed first, note that arch doesn't support apparmor yet so not everything is broken | 12:09 |
| zyga-suse | darn, I just realized why I'm sleepy | 12:09 |
| zyga-suse | I was so sleepy I made ... chocolate milk instead of coffee | 12:09 |
| jdstrand | zyga-suse: stat would certainly be the most dynamic, but I'm not sure I care for that | 12:09 |
| zyga-suse | jdstrand: care as in you'd rather not see it or you don't mind seeing it but there's no urgency? | 12:10 |
| jdstrand | zyga-suse: if arch is changing that much, we could perhaps add multiple rules, or try rules in order if range in shadow, root, foo, bar, then stat to see if it matches | 12:10 |
| jdstrand | maybe that could work... | 12:10 |
| zyga-suse | jdstrand: is the seccomp bytecode generator smart to combine rules? | 12:11 |
| zyga-suse | jdstrand: and if so, what is the join function, AND or OR? | 12:11 |
| jdstrand | zyga-suse: I don't think there is any urgency for all of this extra discussion. I suggest doing what we siad (shadowGroup()) and be done with it. the more we see, the more info we'll have to see where we want to go | 12:11 |
| zyga-suse | jdstrand: say we allow chown root; chown shadow | 12:11 |
| zyga-suse | jdstrand: how does that behave/combine | 12:12 |
| * zyga-suse nods on jdstrand's point about urgency | 12:12 | |
| jdstrand | zyga-suse: think of it more like a list to match against | 12:12 |
| zyga-suse | aha, so OR? | 12:12 |
| pedronis | sounds like we need the system key stuff mvo was working on | 12:13 |
| pedronis | to do that though | 12:13 |
| jdstrand | I don't think it is implemented as a join function but if you want to think of it as OR, then ok | 12:13 |
| ogra_ | Chipaca, followup question ... | 12:14 |
| zyga-suse | pedronis: yes, that's a possiblility | 12:14 |
| ogra_ | (on the P) | 12:14 |
| ogra_ | *PR | 12:14 |
| mvo | pedronis: I can resurrect this work | 12:14 |
| jdstrand | zyga-suse: because it is a list to match against, we have to be careful with '-' in the policy | 12:15 |
| jdstrand | zyga-suse: eg chown - u:root - | 12:15 |
| jdstrand | zyga-suse: that would allow chown to any group | 12:16 |
| zyga-suse | right | 12:17 |
| zyga-suse | essentially * swallowing "root" | 12:17 |
| jdstrand | '-' can be thought of a glob, yes | 12:18 |
| jdstrand | but, all that comes as part of PR review | 12:18 |
| jdstrand | just don't use '-' for arch and we'll be fine :) | 12:18 |
| ogra_ | mvo, is the explanation on the PR fine with you ? | 12:19 |
| jdstrand | zyga-suse: curious, what uid/gid is daemon in arch? in solus? in suse? | 12:20 |
| zyga-suse | jdstrand: so... (not sure if those are constants or just particular values on my machines) | 12:20 |
| * jdstrand was under the impression it was '1' everywhere, but the LSB doesn't actually seen to define the uid/gid | 12:20 | |
| jdstrand | seem* | 12:20 |
| mvo | ogra_: fine with me | 12:21 |
| * ogra_ merges | 12:21 | |
| mup | PR core-build#17 closed: switch /etc/systemd/system to "synced" mode <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/17> | 12:22 |
| jdstrand | zyga-suse: I see now that only root is defined to be '0', so we'll want daemon_uid := FindUser('daemon') and daemon_gid := FindGroup('daemon') in main_test.go | 12:23 |
| jdstrand | zyga-suse: is that and shadowGroup() something you want me to do or are you on it? | 12:24 |
| zyga-suse | jdstrand: daemon, on openSUSE is 2, on solus is 6 and on arch it is 2 | 12:25 |
| zyga-suse | jdstrand: sorry, arch took a while to boot | 12:25 |
| zyga-suse | jdstrand: and on fedora... | 12:25 |
| jdstrand | interesting | 12:25 |
| zyga-suse | jdstrand: yeah, I'd really welcome some standardization but then again, data migration is a pain | 12:26 |
| pedronis | mvo: github says the conflict is still there | 12:28 |
| mup | PR core-build#18 opened: fix resize for GPT, be more verbose for logging <Created by ogra1> <https://github.com/snapcore/core-build/pull/18> | 12:28 |
| mvo | pedronis: oops, one sec | 12:28 |
| ogra_ | mvo, ^^^ the resize fix | 12:28 |
| mvo | ogra_: heh, like how this is fixed | 12:29 |
| ogra_ | ;) | 12:29 |
| mvo | pedronis: fwiw, the fact that we don't get travis slots also means we only get very slow updates into the edge ppa :/ spread-cron will only push there after master got a travis run that is green and because that takes hours currently those updates also take hours | 12:30 |
| mup | PR snapd#3890 opened: overlord: use overlord.Mock in more tests, make sure we check the outcome of Settle <Created by pedronis> <https://github.com/snapcore/snapd/pull/3890> | 12:32 |
| ogra_ | zyga-suse, mind to sign off https://github.com/snapcore/core-build/pull/18 ? | 12:33 |
| mup | PR core-build#18: fix resize for GPT, be more verbose for logging <Created by ogra1> <https://github.com/snapcore/core-build/pull/18> | 12:33 |
| pedronis | mvo: :/ | 12:33 |
| zyga-suse | ogra_: what is '-p' being passed to? what does it do? | 12:34 |
| mup | PR snapd#3891 opened: daemon: reach for Overlord.Loop less thanks to overlord.Mock <Created by pedronis> <https://github.com/snapcore/snapd/pull/3891> | 12:35 |
| ogra_ | zyga-suse, http://paste.ubuntu.com/25489461/ it makes resize2fs print all actions to the log (called "progress" in the manpage, but its not actually a progress indicator when redirected, just a "i'm doing this now" printout) | 12:36 |
| pedronis | mvo: there are also unit tests problems on that branch | 12:36 |
| jdstrand | zyga-suse: was that 'yeah' for me to do the work? | 12:37 |
| pedronis | mvo: funnily artful-i386 is quite fast at running unit test | 12:37 |
| jdstrand | zyga-suse: note that for daemon, we don't have the same problem as with shaodw-- it will exist everywhere | 12:37 |
| zyga-suse | jdstrand: ah, I didn't notice your proposal to do that. I can do it later when I'm looking at arch (~Monday), if you want to tackle that before that's fine | 12:38 |
| zyga-suse | jdstrand: I will carry it as a distro patch there to bake | 12:38 |
| jdstrand | zyga-suse: I don't foresee specifying a lot of users and groups in the policy, so there should only be shadow for a while, then maybe a couple more down the line | 12:38 |
| zyga-suse | jdstrand: yes, fortunately :) | 12:38 |
| jdstrand | zyga-suse: the other users will all be the ones managed by snapd, so no problem | 12:39 |
| zyga-suse | ogra_: commented on the PR now | 12:40 |
| * ogra_ sighs deeply | 12:42 | |
| mvo | pedronis: yeah, I noticed and should be good now as well, I will double check though | 12:43 |
| zyga-suse | ogra_: hint hint: https://github.com/snapcore/core-build/blob/master/initramfs/testing/aaa-tests.py | 12:45 |
| zyga-suse | ogra_: try writing a real test | 12:45 |
| mup | PR snapd#3892 opened: systemd: add systemd.MockJournalctl() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3892> | 12:45 |
| zyga-suse | well, a real unit tests | 12:45 |
| pedronis | mvo: still failing: FAILgithub.com/snapcore/snapd/overlord/snapstate/backend [build failed] | 12:49 |
| pedronis | or github confused me again | 12:49 |
| mvo | pedronis: probably legit, I need more tea | 12:51 |
| Chipaca | mvo: pedronis: stdup? | 13:02 |
| Chipaca | pedronis: oh hi | 13:02 |
| pedronis | mvo: standup? | 13:03 |
| mvo | pedronis: yes omw | 13:03 |
| mup | PR core-build#18 closed: fix resize for GPT, be more verbose for logging <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/18> | 13:05 |
| sborovkov | ogra_: damn ittttt. issue is not in config.txt. Something going wrong when psplash.img is built | 13:20 |
| sborovkov | ogra_: tried everything with config.txt options | 13:20 |
| ogra_ | sborovkov, weird | 13:20 |
| sborovkov | then I just replaced my psplash.img | 13:20 |
| sborovkov | with yours | 13:20 |
| sborovkov | and splash showed up | 13:20 |
| ogra_ | hmm | 13:21 |
| ogra_ | sborovkov, how are you building ? | 13:22 |
| ogra_ | on a PC ? | 13:22 |
| ogra_ | or natively onm the pi | 13:22 |
| sborovkov | on a pc, inside docker container | 13:22 |
| sborovkov | xenial-amd64 is used as an image | 13:23 |
| ogra_ | well, that should result in the same binary | 13:23 |
| sborovkov | it is not | 13:23 |
| ogra_ | lzcat psplash.img | cpio -i | 13:24 |
| ogra_ | do that for both (in different tmpdirs, else one overwrites the other) | 13:24 |
| ogra_ | and check the psplash binay with "file" | 13:24 |
| sborovkov | My version: - 472 blocks - file output: psplash.img: LZMA compressed data, streamed ; your version: 471 blocks; same file output | 13:25 |
| ogra_ | no | 13:25 |
| ogra_ | the uncompressed img ... you want to see the binary indside | 13:26 |
| ogra_ | "lzcat psplash.img | cpio -i" will unpack it | 13:26 |
| sborovkov | alright, one moment | 13:27 |
| ogra_ | the img is actually an initrd that we merge in ram with teh actual initrd.img when uboot loads it | 13:28 |
| diddledan | ogra_: regarding ring. I've been digging through their sauce (tomato) and figuring out whether it can work without dbus. I _think_ it can - I'm compiling a new build now | 13:28 |
| ogra_ | i have a slight suspicion that the cross build code doesnt work for you and you end up with an x86 binary | 13:28 |
| sborovkov | ogra_: your version has bin directory, mine has bin executable at the top level | 13:29 |
| ogra_ | oohh ? | 13:29 |
| ogra_ | thats interesting | 13:29 |
| ogra_ | https://github.com/snapcore/pi3-gadget/pull/13/files has "cp psplash initrd/bin" | 13:30 |
| mup | PR pi3-gadget#13: add splash support <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/13> | 13:30 |
| sborovkov | cp psplash initrd/bin | 13:30 |
| sborovkov | yeah :-) | 13:30 |
| ogra_ | so why does it not end zup there | 13:30 |
| sborovkov | there is no such directory? | 13:30 |
| sborovkov | that's why it copies to file? | 13:31 |
| ogra_ | it should fail and scream and shout | 13:31 |
| ogra_ | if that dir isnt theer | 13:31 |
| sborovkov | well it does not - Priming psplash ;Snapping 'screenly-pi3'; is all I get at the end | 13:32 |
| ogra_ | do you have the psplash subdir in your source ? | 13:32 |
| sborovkov | no errors/warnings | 13:32 |
| sborovkov | yeah | 13:32 |
| ogra_ | in that there should be an initrd subdir ... including bin | 13:32 |
| sborovkov | there is no bin directory there | 13:32 |
| sborovkov | initird only | 13:32 |
| ogra_ | oh | 13:33 |
| ogra_ | well, there should be a bunch of dirs | 13:33 |
| ogra_ | not nly bin | 13:33 |
| ogra_ | also scripts | 13:33 |
| ogra_ | did you perhaps miss a git add when merging ? | 13:33 |
| sborovkov | there is script directory | 13:34 |
| diddledan | in other news, I've discovered systemtap | 13:34 |
| diddledan | ^^^ it helped me narrow down where the failure was occuring so I could investigate the sauce (tomato) | 13:35 |
| sborovkov | ogra_: https://github.com/ogra1/pi3-gadget/tree/master/psplash can't see bin here? | 13:35 |
| ogra_ | there shhouldl be psplash/initrd/bin (empty), psplash/initrd/scripts/init-top/ORDER and psplash/initrd/scripts/init-top/psplash | 13:35 |
| sborovkov | there are psplash/initrd/scripts/init-top/ORDER and psplash/initrd/scripts/init-top/psplash | 13:35 |
| sborovkov | no bin | 13:35 |
| ogra_ | hmm | 13:36 |
| sborovkov | ogra_: I have your repo checked out | 13:36 |
| sborovkov | there is no bin as well | 13:36 |
| ogra_ | yeah | 13:36 |
| ogra_ | why deos that work for me then | 13:36 |
| jdstrand | roadmr: hi! can you take a look at https://forum.snapcraft.io/t/unexpected-output-from-click-review/2031/6 | 13:37 |
| roadmr | jdstrand: I'm on it, fighting !*$% kibana to get the output | 13:38 |
| roadmr | jdstrand: it's the same snap I reported some days ago, remember? | 13:38 |
| diddledan | is there a snapcraft variable exposing the default number of make threads so that I can use parallel builds in my build: scriptlet without hardcoding a value? | 13:38 |
| roadmr | jdstrand: this is the latest one: click-review returned unexpected output for package /tmp/tmp5eXbOZ/snapped-atom.retro-causal_1.19.7_amd64.click: ERROR: Could not find '/tmp/review-tools-xhag5033' | 13:39 |
| davidcalle | pstolowski: https://github.com/CanonicalLtd/snappy-docs/pull/98 for you | 13:40 |
| mup | PR CanonicalLtd/snappy-docs#98: Refresh the whole page, add install and remove hooks <Created by caldav> <https://github.com/CanonicalLtd/snappy-docs/pull/98> | 13:40 |
| ogra_ | sborovkov, sorry ... i simply added a mkdir to snapcraft.yaml now before copying ... pull my tree again | 13:40 |
| roadmr | jdstrand: I see 3 fails for this particular snap with unexpected output... and that's it. So his other one that failed review seems to have been a different cause (i.e. a genuine failure, not "unexpected output") | 13:40 |
| cachio | mvo, 2.28.2 is on beta? | 13:44 |
| sborovkov | ogra_: np, good thing we found the issue now | 13:51 |
| ogra_ | sborovkov, yeah, that would have bitten me badly when merging the branch in ... thanks ! | 13:52 |
| * Chipaca hunts for tea | 13:52 | |
| jdstrand | roadmr: hmm | 13:53 |
| pstolowski | davidcalle, will do, thanks! | 13:55 |
| roadmr | jdstrand: I found a few "could not find foo" in the source code but I can't tell which one this is. Maybe changing those to "could not find %s while unpacking" so we can better know what happened? | 13:55 |
| pedronis | pstolowski: just noticed that AddPlug/Slot is also used in interfaces/ifacetest so cannot be moved to export_test.go but is not used a lot | 13:56 |
| pedronis | as we said, so should be ok to change it a bit | 13:56 |
| jdstrand | roadmr: this snap unpacks really big: 1.9G | 13:58 |
| jdstrand | roadmr: could it have run out of space? | 13:58 |
| roadmr | jdstrand: oh, that's a possibility. Let me check | 13:59 |
| roadmr | jdstrand: we did not get any low-space alerts though | 13:59 |
| ogra_ | ppisati, initrd fixes have landed in the PPA, can you trigger a rebuild for pc-kernel and dragonboard-kernel ? | 13:59 |
| jdstrand | roadmr: I think I'm going to see if I can't output json with every error | 14:00 |
| jdstrand | roadmr: I won't be able to finish that today though | 14:00 |
| ppisati | ogra_: ack | 14:02 |
| ogra_ | thx | 14:02 |
| roadmr | jdstrand: no problem, we're not seeing this frequently (only those 3 cases for this snap over the past 7 days) | 14:02 |
| pstolowski | pedronis, yes | 14:03 |
| jdstrand | roadmr: it is also taking *forever* to complete the review (running it here under the review-tools snap) | 14:03 |
| roadmr | how so? time to decompress? | 14:03 |
| jdstrand | roadmr: wonder if there was an OOM | 14:03 |
| jdstrand | roadmr: now, python3 process taking a long time | 14:05 |
| roadmr | ok | 14:05 |
| * ogra_ takes a break | 14:05 | |
| jdstrand | roadmr: well, *forever* is strong. less than 10 minutes | 14:06 |
| sborovkov | ogra_: yay, I can see the splash. it does not like my picture for some reason and draws white line on it but whatever | 14:07 |
| cjwatson | jdstrand: the daemon/bin uid/gid conflict between RH-descended and Debian-descended distributions has been a known problem for at least 20 years and everyone gave up on it | 14:07 |
| mvo | cachio: yes, 2.28~rc2 is in beta | 14:07 |
| cjwatson | jdstrand: at this point it is what it is and there's not much to be done | 14:07 |
| cachio | mvo, yes, I already started beta validation for this one | 14:07 |
| mvo | cachio: great, thank you! | 14:07 |
| jdstrand | cjwatson: yeah, I figured as much, which is why we are doing lookups for the uid/gid in the actual. I personally just didn't realize that diversion in the tests. thanks for the historical context :) | 14:09 |
| jdstrand | actual code* | 14:09 |
| * zyga-ubuntu found the history lesson interesting | 14:10 | |
| zyga-ubuntu | cjwatson: is this a big old accident or was it deliberate? | 14:10 |
| cjwatson | zyga-ubuntu: accident | 14:10 |
| jdstrand | if it is 20 years old, that is kinda interesting | 14:11 |
| cjwatson | zyga-ubuntu: the LSB people tried to standardise a single value and realised they couldn't | 14:11 |
| zyga-ubuntu | I find it curious with new distros that are not derivatives, like solus | 14:11 |
| jdstrand | guessing the LSB was documenting what was out there already and didn't want distros to have to change the uid for daemon by choosing one | 14:11 |
| cjwatson | I don't know why Solus picked a different value, but eh, 3 values isn't particularly worse than 2 | 14:11 |
| zyga-ubuntu | cjwatson: lol, yes, that's just makes it official | 14:12 |
| zyga-ubuntu | thu shall not have constants | 14:12 |
| cjwatson | jdstrand: exactly, and uids/gids are more or less unchangeable | 14:12 |
| * jdstrand nods | 14:12 | |
| zyga-ubuntu | but fedora did change the default user uid from 500 to 1000 a while back | 14:12 |
| zyga-ubuntu | though I understand that has smaller impact (none) | 14:12 |
| cjwatson | that's very different, and I bet they didn't attempt to migrate existing data | 14:13 |
| zyga-ubuntu | yes, it was just on new installs | 14:13 |
| roadmr | jdstrand: all 4 app units have ~40GB of free space | 14:13 |
| cjwatson | migrating my user account on my 1997-installed server from 500 to 1000 has been on my list for a long time, but eh :) | 14:13 |
| jdstrand | hehe | 14:13 |
| zyga-ubuntu | hehe | 14:13 |
| cjwatson | hm, no, maybe 1999 | 14:14 |
| zyga-ubuntu | guess microsoft had some ideas with uuid based account IDs | 14:14 |
| zyga-ubuntu | cjwatson: is it really that old without reinstall? | 14:14 |
| cjwatson | yes | 14:14 |
| zyga-ubuntu | cjwatson: if so I find that really impresisve | 14:14 |
| jdstrand | roadmr: ok. well, since this isn't an emergency, I'll work on cleaning up the output as mentioned so we can better diagnose this in the future | 14:14 |
| cjwatson | reinstalling would be a ton more work than upgrading | 14:15 |
| zyga-ubuntu | cjwatson: is it running debian? | 14:15 |
| cjwatson | yes, first installed with pre-release potato-ish I believe | 14:16 |
| roadmr | jdstrand: thanks. | 14:16 |
| cjwatson | first pre-release Ubuntu images were built on it | 14:16 |
| mup | PR snapd#3797 closed: daemon: allow polkit authorisation to install/remove snaps <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3797> | 14:17 |
| jdstrand | ah, potato | 14:18 |
| roadmr | jdstrand: potato??? | 14:19 |
| roadmr | ahh! | 14:19 |
| roadmr | I see. nm me | 14:19 |
| sborovkov | ogra_: hmm, it's not colorspace issue. interesting. I am getting this https://drive.google.com/open?id=0B5xwucQA3JSJR0JtSFVxUExKbVU (again disregard that it's gigantic, resolution on first boot is very low). That line appears in 1080p as well. Source image is 1080p. I tried both SRGB and RGB. So may be it does not like resoltuion Idk | 14:23 |
| SuperJonotron | i have heard through a third party via canonical that the nmcli is the correct way to modify network management for ubuntu core 16 but all the docs only mention netplan and networkd which seem way more configurable via the yaml file but when you do this all sorts of dns issues come up because it seems to conflict with some other network management going on | 14:30 |
| SuperJonotron | at this point I can switch to nmcli i think fully if I can just get information on getting an ethernet port to maintain it's static IP even if it's not plugged in since right now that is only handled via an interfaces or yaml config file with netplan but those can't be used with any stability for ubuntu core 16 from any of my testing | 14:31 |
| Chipaca | SuperJonotron: as far as I know most ubuntu core devices don't ship network manager | 14:33 |
| Chipaca | some do though | 14:33 |
| Chipaca | SuperJonotron: however, the netplan instabilities you're mentioning are news to me. Could you describe the problems you're seeing in more detail in the forum? | 14:34 |
| SuperJonotron | Chipaca: NetworkManager doesn't seem to be installed in this case but using a yaml netplan file causes a weird issue on boot due to dns issues | 14:34 |
| roadmr | jdstrand: the app units have 16 GB RAM, so should also not be an OOM situation, though e.g. maybe processing multiple huge snaps could result in that | 14:34 |
| SuperJonotron | if I create a yaml file with all the correct syntax, something with a network service on dns entry locks up for ~2 min on the OS boot | 14:35 |
| SuperJonotron | it's failing to resolve dns but once it boots the dns is perfectly fine | 14:35 |
| SuperJonotron | nmcli setting static and leaving dhcp on my second port does not have this issue but does lose static ip's when unplugged | 14:35 |
| Chipaca | SuperJonotron: i'm sorry, i don't know enough about any of these things to help you concretely myself. This is why I suggested the forum, so people more knowledgeable (and on different timezones) can help | 14:36 |
| Chipaca | SuperJonotron: also so that if somebody else has the same problem they find the fix :-) | 14:36 |
| Chipaca | SuperJonotron: however, nmcli is a network manager client, isn't it? if you don't have network manager, how does it even? | 14:37 |
| SuperJonotron | Chipaca: and there in lies the problem, the forums (https://ubuntuforums.org/showthread.php?t=2323253) have this issue and the resolution is all around NetworkManager and configuration files that are read only due to snappy's read only file system so it's an insurmountable bug so far as I can tell | 14:38 |
| Chipaca | SuperJonotron: https://forum.snapcraft.io | 14:39 |
| Chipaca | SuperJonotron: i doubt the url you pasted has anything to do with ubuntu core | 14:39 |
| SuperJonotron | Chipaca: not specifically but it is the exact error message on the OS boot so it's likely a bug that lives in both systems from the same NetworkManager | 14:41 |
| Chipaca | SuperJonotron: there is no network manager in core | 14:41 |
| Chipaca | unless you've installed a snap of it | 14:41 |
| Chipaca | (in which case you'd know) | 14:41 |
| SuperJonotron | Chipaca: I have not. The docs (https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/index), as mentioned before are really conflicting since it seems nmcli is the correct way but netplan and networkd are the documented approaches but when i've used the yaml for netplan it experiences the network manager issues on boot for something not supposed to be installed | 14:44 |
| SuperJonotron | this is why it's a very weird problem for me and i'm ready to just abandon it for nmcli if I can just get static IP to persist even when unplugged | 14:45 |
| Chipaca | SuperJonotron: those are the docs for network manager | 14:45 |
| Chipaca | SuperJonotron: you do not have network manager | 14:46 |
| jdstrand | roadmr: the whole thing shouldn't be in memory so I don't think that would be the case. ok, I think we've exhausted our guesses, I'll work on the unexpected output bits | 14:46 |
| Chipaca | SuperJonotron: could you please create a new forum topic on forum.snapcraft.io, describe exactly what you have, what you do, what you expect, and what happens instead? | 14:47 |
| roadmr | jdstrand: yeah :( thanks... hopefully we'll get to the bottom of this. | 14:47 |
| SuperJonotron | Chpaca: I'd lve to see official documentation to Ubuntu Core IP configurations because that's the closest thing i've found to exist and not have to go to a forum or IRC for this but I will if no such documentation exists | 14:48 |
| Chipaca | SuperJonotron: did you try "sudo console-conf"? | 14:53 |
| Chipaca | SuperJonotron: (on the core device) | 14:53 |
| SuperJonotron | Chipaca: it works but doesn't work for my solution since I need a non-interactive solution so it can be interfaced with via software | 14:55 |
| Chipaca | sigh | 14:57 |
| sborovkov | ogra_: and actually that white line is present on your default splash. commenting out framebuffer and hdmi_mode options does not help. On 1080p it's even more noticeable - https://drive.google.com/file/d/0B5xwucQA3JSJTFBvd2FBSmZMY0U/view?usp=sharing | 14:57 |
| Chipaca | SuperJonotron: in what way do you need it interfaced with via software? what software? | 14:58 |
| SuperJonotron | Chipaca: the software has, or should at least, have full access to modify the IP configuration, static, DHCP, dns, default gateways, etc. It has all the functions ready in a sense just needs to be configured for the OS it's running on | 15:01 |
| SuperJonotron | Chipaca: the software is Niagara | 15:02 |
| Chipaca | SuperJonotron: that sounds like something that needs full access to the device | 15:04 |
| Chipaca | SuperJonotron: also sounds like something that should be decided at the model level, but that's neither here nor there | 15:04 |
| Chipaca | SuperJonotron: I don't know where the netplan docs exist, as I said early on I know very little about this aspect of our stack; I repeat that your best bet will be to ask in the forum | 15:05 |
| Chipaca | SuperJonotron: if your goal is to make your software be able to do all that no matter what networking stack the device is using, you're going to have a lot of fun | 15:06 |
| SuperJonotron | Chipaca: it will in fact be designed to run with UC16 on a specific hardware model series | 15:06 |
| Chipaca | unless netplan can already do the things you need, that is :-) | 15:06 |
| SuperJonotron | Chipaca: I can lock the feature into a specific network stack but figuring out which ones work fully first is where i'm at and can't seem to find stability in any path so far | 15:06 |
| SuperJonotron | I am currently writing a forum post on the topic | 15:07 |
| Chipaca | SuperJonotron: thank you | 15:07 |
| Chipaca | SuperJonotron: i look forward to learning the source of the instability you experience | 15:07 |
| Chipaca | but | 15:07 |
| Chipaca | next week | 15:07 |
| Chipaca | becaue I think i'm going to EOD now | 15:07 |
| Chipaca | mvo, pedronis, zyga-ubuntu, I'm signing off now. I'll have my laptop with me on the road, so I'll be tinkering with stuff, but won't be online | 15:08 |
| Chipaca | o/ | 15:08 |
| pedronis | Chipaca: have fun | 15:08 |
| Chipaca | no | 15:08 |
| Chipaca | after this week, what i need is _boring_ | 15:08 |
| Chipaca | i'll take a 1x1 sudoku game with me | 15:08 |
| Chipaca | :-) | 15:09 |
| ogra_ | sborovkov, interesting, i doont have such a line on any of my installs | 15:10 |
| sborovkov | ogra_: hmm. may be another setting affecting it. about hdmi. Also I guess I do need to psplash-snap. Because there is like 10 seconds between splash screen and our snap started. And with psplash-snap I was getting the same white line there | 15:12 |
| ogra_ | sborovkov, looking at psplash.c i see http://paste.ubuntu.com/25490573/ | 15:12 |
| ogra_ | namely SPLIT_LINE_POS | 15:13 |
| sborovkov | interesting why is it even needed there | 15:13 |
| ogra_ | sborovkov, you dont need psplash-snap, you want vt.handoff=0 and have your UI only call chvt 1 after the UI is up | 15:13 |
| ogra_ | then you wont have a visible switch | 15:14 |
| sborovkov | ok, then I will try that | 15:14 |
| ogra_ | (that is ... *if* the UI can start without the frambuffer being visible) | 15:14 |
| ogra_ | sborovkov, well, happy you have it working now, i guess the rest is simply fixes that we'll manage over time | 15:15 |
| sborovkov | yeah :-) will just try to figure out stuff about white line, wonder what values it gets there to split like that (if it's SPLIT_LINE_POS fault indeed). And this white line is very big on 1080p. And as you can see it's actually 2 lines there on 1080p at the bottom of the screen. I tried setting framebuffer_height to 1080 but my rpi does not start with it hmm. | 15:18 |
| ogra_ | well, in the low-res setup your image is also not vertically centered | 15:19 |
| ogra_ | i bet there is some simple math thhat goes wrong and the split line would actually be supposed to be off sceen | 15:19 |
| ogra_ | sborovkov, regarding the psplash-snap i'll try to collect some data and discuss it with jdstrand next week ... we'll need a splash interface or enhance the framebuffer one or some such (it needs a bit more than what existing interfaces provide) | 15:21 |
| sborovkov | ok cool, thanks a lot for assistance | 15:22 |
| ogra_ | np :) | 15:22 |
| * ogra_ really loves to work on that splash stuff :) | 15:22 | |
| sborovkov | actuaslly | 15:22 |
| sborovkov | no need for chvt 1 | 15:23 |
| ogra_ | nice ! | 15:23 |
| sborovkov | just tried vt.handoff - splash went away when our ui came up | 15:23 |
| ogra_ | perfect | 15:23 |
| ogra_ | cachio, fyi dragonboard resize is nwo fixed in edge,beta and candidate with the latest kernel snap | 15:26 |
| ogra_ | *now | 15:26 |
| ogra_ | (just tested here ... http://paste.ubuntu.com/25490624/ ) | 15:27 |
| cachio | ogra_, nice | 15:36 |
| cachio | ogra_, THANKS | 15:37 |
| === cachio is now known as cachio_lunch | ||
| sborovkov | ogra_: ok the issue is in the psplash.c. I just changed SPLIT_LINE_POS to 10k. Now I get one line instead of 2 at the bottom. Just need to figure out it's logic then. | 15:44 |
| itsfemme[m] | is it possible to run a snap package on a system with PaX enabled? does snapd have some hooking mechanism perhaps that you can use to mark the flags necessary? | 15:51 |
| itsfemme[m] | https://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System#PaX_Flags | 15:51 |
| ogra_ | sborovkov, yeah, i'll lok on the weekend if i can put something into the main psplashh patch for it | 15:56 |
| ogra_ | itsfemme[m], i dubt anyone has tested that yet ... trying it and putting your findings into the forum (see channel topic) might be the best thing here | 15:57 |
| ogra_ | (i doubt anyne has yet run snapd with a gsecurity kernel that also has all the right patches for snap support) | 15:58 |
| mup | PR snapcraft#1540 opened: plugins: extract python finder functions <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1540> | 16:09 |
| smoser | hey. if i have a snapcraft.yaml, but i need a build-package (or stage-packages) from somewhere other than xenial , is that possible ? | 16:29 |
| smoser | specifically, libjson-webtoken-perl is not available in xenial | 16:30 |
| nacc | smoser: building on lp, you can specify where to build. But i'm not sure you can specify one dep come from a specific release | 16:32 |
| smoser | nacc, thanks | 16:34 |
| smoser | thats kind of what i thought | 16:34 |
| nacc | smoser: it would be nice if that was possible, but i've also seen oddness about how the debs are handled (e.g., postinst isn't run, so you need to manually handle that, if necessary (e.g., alternatives that normally get setup) and I don't think there's a way to specify recommends shoudl also be installed (where recommends really are neeeded :) | 16:35 |
| smoser | well, yeah. the 'packages' are really just installed into the build system so its sane to assume that they are rsolved within the archive that bhe build system. | 16:38 |
| nacc | smoser: yeah | 16:39 |
| nacc | smoser: we recently swtiched git-ubuntu over to artful for this reason (we needed newer versions) | 16:39 |
| mup | PR snapcraft#1541 opened: [WIP] Debug fake store in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1541> | 16:45 |
| === cachio_lunch is now known as cachio | ||
| ogra_ | smoser, worst case there are always scriptlets to ise wget and dpkg -x ;) snapcraft.yaml is extremely hack friendly | 16:57 |
| ogra_ | *to use | 16:57 |
| smoser | ogra_, thanks. i hdnt known of scriptlets | 17:04 |
| posi | Is this a good place to ask snap questions? If so, I am having issues getting the brave webbrowser's seccomp-bpf sandbox properly functioning in the snap I built. Anything fancy I need to do? | 18:00 |
| pedronis | mvo: I'm saying strange error in core transition tests, I wonder if we didn't consider some interaction with the prereq code | 18:16 |
| pedronis | s/saying/seeing/ | 18:17 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| mvo | pedronis: reproducable? or in some random tests? | 18:37 |
| mvo | pedronis: eh, random runs in travis | 18:38 |
| pedronis | mvo: it's not even a transition tests but I'm seeing TestSetConf taking more thant 10 minutes, and ensureCoreTransition is in the goroutines | 18:38 |
| pedronis | mvo: I thought it was a test that I touched but no | 18:38 |
| pedronis | mvo: here's the log | 18:39 |
| pedronis | mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170908_125944_bd802@/log.gz | 18:39 |
| * mvo looks | 18:39 | |
| pedronis | it's a weird one | 18:39 |
| pedronis | that branch doesn't touch daemon (the next one does, and anyway that test isn't changed in the next either but irrelevant) | 18:39 |
| mvo | pedronis: hm, strange indeed | 18:41 |
| mvo | pedronis: I investigate monday | 18:44 |
| * mvo vanishes | 18:44 | |
| pedronis | have a great weekend! | 18:44 |
| mup | PR snapd#3893 opened: many: introduce asserts.NotFoundError replacing both ErrNotFound and store.AssertionNotFoundError <Created by pedronis> <https://github.com/snapcore/snapd/pull/3893> | 18:55 |
| === JoshStrobl is now known as JoshStrobl|Work | ||
| mup | PR snapcraft#1277 closed: Handle revoked-uploads case on snap-developer revokes. <Created by psivaa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1277> | 19:49 |
| === CodeMouse92 is now known as CodeMouse92__ | ||
| mup | PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 21:05 |
| mup | PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 21:06 |
| mup | PR snapd#3894 opened: many: fix TestSetConfNumber missing an Unlock and other fragility improvements <Created by pedronis> <https://github.com/snapcore/snapd/pull/3894> | 21:08 |
| mup | PR snapcraft#1542 opened: tests: add integration tests for build snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1542> | 21:13 |
| mup | PR snapcraft#1428 closed: core: reexec as root for `os` snaps if necessary <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1428> | 21:31 |
| mup | PR snapcraft#1430 closed: tests: enable the snaps installation in armhf <Created by elopio> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1430> | 21:34 |
| mup | PR snapcraft#1535 closed: jhbuild plugin: remove dependency on pkgconf <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1535> | 23:16 |
| mup | PR snapcraft#1539 closed: nodejs plugin: expose hidden bin path when using yarn <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1539> | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
