=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:04] o/ [07:08] * zyga looks outside at the rainy day [07:29] * zyga spends the morning on email and PRs [07:49] zyga: I updated 3512 - iirc you asked about this last week [07:53] mvo: looking [07:55] mvo: I read that, thanks for updating it, I'm worried that tests failed [07:55] mvo: (not related to branch, linode/travis timeouts) [08:07] zyga: yes, all tests are currently broken due to linode issues [08:08] zyga: have you seen the last few posts in https://forum.snapcraft.io/t/test-failures-with-cannot-create-lock-directory-run-snapd-lock/390/28 ? it looks like for thomi the apparmor profile was not correctly loaded for snap-confine. I wonder if this is related to the issues we saw during the sprint when there also was a profile that was supposedly loaded except it was not during one of the spread tests. do you remember the issue? [08:13] mvo: yes, I do, looking at the forum [08:15] looks like apparmor regression to me [08:15] mvo: but let me look at the data that fgimenez collected to be sure [08:15] zyga: yeah, I was thinking the same [08:15] mvo: we collected data before and after a profile load [08:16] zyga: do you remember what test it was that failed? [08:16] mvo: home writer one [08:16] zyga: mvo hey, all the info from the issue last week is in bug #1701494 [08:16] Bug #1701494: apparmor profiles are eventually not properly generated [08:16] https://bugs.launchpad.net/snapd/+bug/1701494 [08:16] ah :D [08:17] * zyga just found the reference [08:17] fgimenez: nice, thank you [08:18] mvo: ha [08:18] very interesting!!! [08:18] fgimenez: I changed the title, it was correctly generated iirc, it was valid on disk but not the right one was loaded(?) [08:18] mvo: the profiles have identical hashes [08:18] zyga: tell me more [08:18] and everything else [08:18] zyga: wuut? [08:18] *except* for raw_data [08:18] ohh [08:18] so it's not the same but only in one of the files [08:18] so very buggy on 1st look [08:18] hashes the same [08:18] but not the same raw_data [08:19] zyga: yeah, I understood, was just puzzled :) [08:19] oh no :( [08:19] sorry, premature happiness [08:19] tar didn't copy data out of those files [08:19] they are size 0 [08:19] bummer [08:19] we only have raw data because that one was (for whatever reason) copied [08:20] fgimenez: can you run that loop on pi again please [08:20] but this time collect the data with cp and then tar it [08:20] sysfs can be wonky for tar [08:20] zyga: sure on it [08:22] mvo: but one interesting observation [08:22] mvo: this happened on pi2 with a unchanging kernel [08:22] mvo: so the only (likely) reason is userspace changes [08:22] zyga: oh, good point. [08:22] the files have largely different content [08:22] zyga: the last apparmor update is ages old though [08:23] there are some blobs here and there that are the same (out of 50KB maybe) [08:23] but it's just something else [08:23] mvo: another possibility is caching issue or cache corrpution [08:24] zyga: yeah, I was wondering about this, but thomi got this on a classic system [08:24] zyga: but then, maybe its unreleated [08:30] mvo: maybe it's an old, existing bug that just (for whatever random reason) happened now more often [08:34] mvo: I could add a patch to snapd that looks at that data and perhaps records the compiled binary somehow [08:34] mvo: we could even load it >1 and ensure it is stable [08:34] mvo: not sure if you think this is worth pursuing [08:35] zyga: not sure either, maybe we talk first with jj if he has a theory [08:35] mvo: yeah, good idea [08:35] mvo: I'll also check the kernel sources and docs to understand why there are two hash files and what they represent [09:09] * zyga wonders why apparmor has its own /dev/null file [09:10] * zyga reboots and will be back shortly [09:14] PR snapd#3555 opened: assserts,overlord/assertstate: test we don't accept chains of assertions founded on a self-signed key coming externally [09:24] re [09:26] mvo, urgh ... i fired up my pi3 after the sprint yesterday and it got a core update ... now i just installed a new snap and get this: [09:26] ogra@pi3:~$ sudo psplash.psplash-write hello [09:26] /var/lib/snapd not root-owned 1000:1000 [09:26] ogra@pi3:~$ snap list core [09:26] Name Version Rev Developer Notes [09:26] core 16-2.26.7 2321 canonical - [09:26] ogra@pi3:~$ [09:27] mvo, i'm relatively sure this image used to work before without issues [09:27] oh,. wait, the code had changed ... but shouldnt i have the fixed core ? [09:28] ah, wait, could be that i messed around with it [09:28] ignore that [09:31] ogra_: this is edge, thats "ok" [09:31] ogra_: ish [09:31] ogra_: please refresh to beta [09:31] ogra_: actually, wait a sec [09:32] ogra_: please try "sudo snap refresh --beta core" and reboot, then things should be ok again [09:33] ogra_: edge is broken right now, fix is scheduled for tomorrow morning [09:36] spread and travis and linode all hate me [09:36] i think i'm going to go shopping [09:37] Chipaca: !!! [09:37] Chipaca: yeah, its in deep hate mode, looks like today is the day for mail and forum (and code reviews :) [09:39] Chipaca: I think its actually linode that is deep in unhappy land, the rest appears to be fine [09:39] (not that this helps in any way) [09:39] I'm an equal-hate complainer [09:49] damn you json [09:49] * pstolowski grumbles about json decoding gotchas [09:52] pstolowski: hmm? [09:52] Chipaca: don't worry, could be worse [09:54] zyga, by default json.Unmarshall treats numbers as float64, which gives this https://forum.snapcraft.io/t/snap-set-digits-as-string/1099/3 [09:54] zyga, to workaround this, you create a Decoder and do UseNumber() on it [09:55] zyga, it works nicely for number then. except it breaks on ip addresses :/ [09:55] zyga: ¬p ⇏ ¬q, or something [09:55] pstolowski: aha, indeed [09:55] * zyga hugs Chipaca and looks at the pouring rain outside [09:56] zyga, it wants to treat "1.2.3.4" as a float, and fails [09:56] pstolowski: but json *is* typed, so just set this as string [09:56] pstolowski: I think that lacking a schema we should treat everything as a string [09:59] zyga, well, yeah, problem is we have very little control over that in snapctl arg parsing, you can basically pass arbitrary json to it via commandline and if it parses, it's opaque to us [10:01] pstolowski: well, I don't think it's a JSON problem, either we just tell people snapctl/snap set take json or we do something more DWIM but then we need to explain the details [10:01] JSON is not yaml, it doesn't have logic to guess if something is a string or not [10:03] pedronis, thank you!!! [10:03] pedronis, you made me realize where the problem leis [10:03] *lies [10:03] pedronis, ip address needs to be quoted, that's it [10:03] pedronis, all tests passing now [10:05] including the new ones I added for integers [10:05] all good it seems === chihchun is now known as chihchun_afk [11:28] fgimenez: hey, any luck reproducing that issue? [11:29] zyga: nothing after 22 executions, i'll keep trying, last week it appeared after 17 and 15 runs, let's see [11:30] fgimenez: thank you! [11:30] I'm working on a tool that would help us understand what is going on if we have the data [11:38] * ogra_ hugs sergiusens for updating telegram ... finally no more update notifications :) [11:58] ogra_: you are welcome [12:03] niemeyer or mvo can you take a quick look at https://github.com/snapcore/snapcraft/pull/1373 which uses an undocumented attr on https://forum.snapcraft.io/t/the-snap-format/698/2?u=sergiusens or https://snapcraft.io/docs/snaps/metadata [12:03] PR snapcraft#1373: snapcraft.yaml: add support for reload-command and completer directives [12:08] zyga, is this the pull with all the stuff? http://lkml.iu.edu/hypermail/linux/kernel/1707.0/01380.html [12:09] it doesn't sound like it... [12:10] Son_Goku, what are you doing here, shouldnt you celebrate your brexit today ? [12:10] haha [12:11] :) [12:13] Son_Goku: it's not everything but this is most of it [12:13] ogra_: brexit in US? [12:13] zyga, *of* the US ;) [12:14] * zyga still doesn't get it [12:14] July 4 is Independence Day [12:14] Son_Goku: I'm in the kernel land all day today, I saw some things are not around yet [12:14] Son_Goku: like signal mediation [12:14] Son_Goku: ah, I get the brexit now :) [12:14] it was when the Declaration of Independence was signed in 1776 [12:14] * zyga does high-five on Son_Goku [12:15] Son_Goku: imagine the horrors if US was about to exit the EU if it were still a part of the british empire ;D [12:15] heh [12:15] well, the US has the benefit of potentially being somewhat self sufficient [12:16] Son_Goku: and texas would be all pro-independence to stay in EU ;-) [12:16] not many countries can do that anymore [12:16] the UK is a federation of countries [12:16] so it's already weird [12:16] zyga, nah, texs would form their own coalition with bavaria [12:16] Son_Goku: except north korea :-) [12:16] *texas [12:16] * zyga thinks this is the perfect time for a cup of coffee and another dive into DFA land of apparmor [12:17] lederhosen with gun pockets and stetson ... [13:37] * zyga goes for lunch [13:39] mvo: what's the state of snapd#3512 , do we need it for the release? or it's 2.27 related? [13:39] PR snapd#3512: cmd: avoid using current symlink in InternalToolPath [13:40] pedronis: its fine for 2.27 [13:40] pedronis: the snap-seccomp code has its own version of this, this is a generalization [13:45] niemeyer, whee ! our frist spam on the forum (do we have a badge for that ? :P ) [13:45] (laste entry in https://forum.snapcraft.io/t/snapd-in-docker/177/14 ) [13:48] mvo: I marked it for 2.27 for clarity [13:53] pedronis: I think we want it ASAP [13:53] mvo: without that we use wrong tools [13:53] heh [13:53] me is confused [13:53] but will let you sort if out [13:53] mvo: I'd add it to 2.26 [15:10] zyga: hm, will it cleanly apply to 2.26? if not we need to backport it [15:36] zyga: hm, hm, what will be the consequence if 3512 is missing from 2.26? slightly worried that it may not make it until tomorrow given how unhappy linode is [15:41] ogra_: Thanks, it's actually not the first one [15:42] well, the first one i see :) [15:42] ogra_: You can flag such posts, so they quickly get sorted [15:42] If enough people flag it, it gets away by itself [15:42] ah, k ... i wasnt sure if the flagging does anything apart from notifying me about changes [15:42] the tooltop isnt so clear [15:42] *tooltip [15:44] ( "privately ... private" -> should perhaps instead talk about "notifying ... admin" or some such to be more clear) [15:44] mvo: I think it will cause wrong tools to be used during core migration [15:44] mvo: if you want I can do that (backport) === pbek_ is now known as pbek [15:44] zyga: if you can, that would be lovely [16:05] niemeyer: you around? [16:06] niemeyer: the MBR issue, as far as I can tell, is always on ubuntu-core-16-64. I thought it was spread amongst different ones but at least right now (and since yesterday) it doesn't seem to be [16:06] niemeyer: this does point to a corrupt image; can you regenerate it? [16:14] * Chipaca ~> cuppa tea [16:30] Chipaca: I think it's always on it, actually [16:30] Chipaca: It happens on the "Direct Disk" Linodes, and we only use that to handle core since we need to reboot into the disk without using grub [16:36] niemeyer: ah. I guess http://pastebin.ubuntu.com/25019305/ isn't that interesting then :-) [16:38] Chipaca: Probably not :) [16:38] Let me ping Linode again to see what those guys are up to [16:48] niemeyer: https://giphy.com/embed/11BbGyhVmk4iLS [16:50] Yeah, pretty much [16:53] brb, reboot [17:43] mvo: I have that backport, running spread locally now [17:43] mvo: not sure if it will pass yet [17:48] mvo: I'll push when it is green locally [17:59] zyga: thank you very much [18:10] mvo: so far so good [18:13] zyga: keep me posted (tomorrow :) [19:12] zyga: did you ever file a bug for the issue around entering and exiting namespaces? [19:23] jjohansen: hey [19:23] I saw the news about the apparmor stuff making its way into 4.13 [19:24] what's left in re snappy apparmor? [19:26] Son_Goku: I split out any mediation that did exist up stream already. The update was already huge, and I decided if it wasn't all going to make it in it was best to get the base in, and update the existing upstream mediation [19:26] could we see the remaining bits make it in for 4.14? [19:26] upstream is missing mount controls, network controls [19:26] Son_Goku: that is the goal [19:26] that's the kernel that we're targeting for Mageia [19:26] err, Mageia 7 [19:27] yeah, I think everyone is targeting 4.14 as its going to be the next stable kernel [20:48] jjohansen: hey [20:49] jjohansen: not yet, I was researching another bug today [20:49] jjohansen: I have a question about raw_data in sysfs, is there a tool to load and display that? [21:19] niemeyer: reping about https://github.com/snapcore/snapcraft/pull/1373 [21:19] PR snapcraft#1373: snapcraft.yaml: add support for reload-command and completer directives [21:46] zyga-suse: what do you mean by load and display? Do you mean to reverse the policy compile and show it as text? [21:47] there is the start of a tool, and I can do some of it, but the really interesting bits will just come out as a dfa state machine, still better than nothing [21:48] I'll fiddle with it and see if I can't get it pushed some where [22:05] jjohansen: show the internal format [22:05] jjohansen: not really decompile, just dump it in readable form [22:05] jjohansen: can you point me to that? [22:11] zyga-suse: it isn't any where visible yet. I'll need to do a little cleanup (make sure it even builds atm I haven't touched it for at least a year), and push it up to an apparmor branch, I'll point you at it when I get that done [22:58] PR snapcraft#1391 opened: tests: reduce the amount of test code in test_meta