=== AdmWiggin is now known as tianon === chihchun_afk is now known as chihchun [03:41] PR snapd#3494 opened: tests: Restart rng-tools services after few seconds === chihchun is now known as chihchun_afk [04:17] hey guyz snapcraft fails tests with python 3.6 [04:40] PR snapcraft#1318 closed: tests: refactor the travis jobs using stages [04:55] PR snapcraft#1291 closed: beta [06:16] PR snapcraft#1331 closed: integrations: use the snapcore/snapcraft docker image in travis === fnordahl_ is now known as fnordahl [07:07] PR snapd#3495 opened: tests: remove snapd before building from branch === mcphail_ is now known as mcphail [07:34] fgimenez: morphis: I'm running off to physio, but I thought I'd ask you guys if you could look into why spread on debian (when travis gets past the auth issue) is failing with “go: command not found” [07:34] Chipaca: you have a link? [07:34] https://travis-ci.org/snapcore/snapd/builds/244733765#L653 [07:35] Chipaca: sure, looking [07:36] Chipaca: morphis maybe the problem happens a bit earlier "Cannot install 'libudev-dev'" [07:36] yes, that looks like what it is [07:37] if the install command in pkgdb gets a list of packages it aborts on the first error [07:37] aborts but doesn't return an error? [07:37] ah, but this is really gdebi [07:38] AFAIK it does [07:38] anyway, i really need to run [07:38] o/ [07:38] hm, https://packages.debian.org/sid/libudev-dev is in all debian archives [07:41] version issue ? (we used to have that with the core snap wehn we used too ship our own systemd version, people building something with libudev-dev in build-packages had their builds fall over ... the version is a == one iirc [07:42] ) [08:05] re [08:12] ogra: hey [08:12] yo [08:12] ogra: do you have a moment? [08:12] sure [08:13] ogra: how can I run test-init without it being init [08:13] ogra: I don't want to use break=... and then script the shelll that spawns (unreliable) [08:13] zyga, i meant the other way around [08:14] and no, you shouldnt use break :) [08:14] ogra: can you tell me what you mean then? [08:14] zyga, you boot with boot=/test-init ... [08:14] that simply runs /init [08:14] so that you get all the env bits you need [08:14] aha [08:14] * zyga tries [08:14] hmm [08:15] the environment and available devices differ between the stages [08:15] and init makes sure to exec each bit in its assignedf stage [08:15] ogra: so kernel command line would have boot=test-init [08:15] right [08:15] ogra: that wants to run /scripts/test-init [08:15] ogra: how do I pass arguments to my init program? [08:15] and test-init somehow needs toexec the scrip snippets at the step that init would use [08:16] take a look at it ... it read env vars [08:16] *reads [08:16] * zyga looks [08:16] every ubuntu install has the script in /usr/share/initramfs-tools/init [08:16] so no need to dig into the source ;) [08:16] TBH the whole exercise only made me want to write /init in C more than anyhting [08:17] well, thats something you should discuss with debian :) [08:17] all the complexity there and all the fragility [08:17] why? is debian doing ubuntu-core? :D [08:17] ogra: btw, I think I found a bug in the script [08:17] no, but we use their inittamfs-tools package [08:17] ogra: have a look at the FIXME I added [08:17] yeah [08:17] we should just fix it ;) [08:17] ogra: I'd like to do a pass and document and test some of those functions better [08:18] (well, we use debians package with ubuntu sauce on top indeed) [08:18] ogra: right but I didn't want to bring that in with this patch, I want this to land [08:18] ogra: I don't know if anyone else is doing this [08:18] ogra: (testing initrd this way) [08:18] ogra: but I wanted to show it is doable [08:18] nope [08:18] and it would be way coooler to actually do it in the distro :) [08:18] * zyga was super slow because python3 async was a learning curve and several small details stopped me mid-process [08:18] also I'm sick [08:19] so that we could just use it from there (and have someone else maintain the core part of it ;) ) [08:19] and moving out day after tomorrow [08:19] and also sunburned and on painkillers [08:19] :( [08:19] so some adverse factors towards productivity [08:19] ogra: I wrote the code to be modular and reusable, with some more polish this could be used to test any early boot scenario [08:20] well, we're not on a race, are we ? [08:20] ogra: I'm mostly fond of the snapshot approach, which means this is blazingly fast [08:20] ogra: well, I feel some pressure to finish this and move to snapd [08:20] zyga, yeah, and i think you should show it to infinity and slangasek and ask them if they want to take it over into the initramfs-tools package [08:20] ogra: I had a look at a redhat paper describing qemu and kernel optimizations that allows them to boot a kernel i 150ms [08:21] ogra: sounds like a good idea, I will [08:21] (alongside with landing it in our branch) [08:21] if they take over we only need to care for the tests in the end [08:21] and not for the framework [08:21] and they get testing for free ;) === cjwatson_ is now known as cjwatson [08:24] ogra: yeah [08:25] ogra: well, let me try that change you suggested [08:26] to set the env vars you want executed in /init, just drop a file into /conf/conf.d// with the values set you want ... /init will read them from there [08:27] ogra: I'm not yet sure if that's the approach to take but let me experiment and see what I can come up with [08:27] and if you do that you can drop a lot of your code ... i.e. the bits that populate /dev and mount all the filesystems [08:28] (and use what /init does at the top) [08:29] INFO:qemu:(console) Begin: Mounting root file system ... /init: /scripts//test-init: line 1: syntax error: unexpected word (expecting ")") [08:29] ogra: it seems that boot=test-init assumes everything is written in shell [08:29] it shouldnt, that would be a kernel bug [08:30] INFO:qemu:starting: ['qemu-system-x86_64', '-enable-kvm', '-snapshot', '-m', '64', '-kernel', 'kernel', '-initrd', 'initrd.back-to-back.cpio.gz', '-append', 'console=ttyS0 boot=/test-init -- testio=ttyS1', '-chardev', 'pipe,id=console,path=/tmp/consolefrqqj0e0', '-chardev', 'pipe,id=monitor,path=/tmp/monitoror3qf2oy', '-chardev', 'pipe,id=testio,path=/tmp/testio5zk4mizt', '-display', 'none', '-monitor', [08:30] 'chardev:monitor', '-device', 'isa-serial,chardev=console', '-device', 'isa-serial,chardev=testio', '-device', 'isa-debug-exit,iobase=0xf4,iosize=0x4', '-drive', 'file=disk.img'] [08:30] (and systemd wouldnt work either ... unless there is a secret shellscript wrapper we dont know about ) [08:31] * zyga feels dizzy again [08:31] what a day :/ [08:31] take a sick day ... [08:31] seriously [08:31] one sec [08:32] no, one day :P [08:32] not curing it just makes it last longer [08:32] ogra: just sent you a pic [08:32] ogra: everything looks like this around me [08:32] downstairs is mostly packed now [08:33] you picked the angle where i dont see the mountain of napkins around you :) [08:33] ogra: they are behind me in the rubbish bin [08:33] yeah, thought so :) [08:44] fgimenez, hey, i'm seeing a bunch of auth errors from linode on travis [08:47] hi pstolowski, do you have a link to the errors? sounds like something we can't help with, just to confirm [08:47] fgimenez, https://travis-ci.org/snapcore/snapd/builds/244606124?utm_source=github_status&utm_medium=notification [08:51] pstolowski: mm that error comes from spread itself, it can be caused by a missing or wrong SPREAD_LINODE_KEY env var, let me check locally using the same spread binary as travis [08:56] * zyga de-conflicted https://github.com/snapcore/snapd/pull/3464 [08:56] PR snapd#3464: interfaces: put base policy fragments inside each interface [09:01] pstolowski: the same binary works fine locally with a valid SPREAD_LINODE_KEY, the errors you get can be caused by a transient error on linode, changes in how the binary behaves on travis, changes on the encryption keys... if the errors keep happening you need gustavo to look into this [09:02] fgimenez, ack, thanks for looking into this! [09:03] pstolowski: yw :) [09:07] hey pstolowski [09:08] how are you doing? [09:08] hi zyga! good, thanks! what's up? [09:08] pstolowski: could you have a look at https://github.com/snapcore/snapd/pull/3464 [09:08] PR snapd#3464: interfaces: put base policy fragments inside each interface [09:09] pstolowski: patch by patch, it should be trivial to review as each diff fits on screen (just moves code from a to b) [09:11] zyga, very nice, i will [09:12] pstolowski: dzięki :) [09:23] Could somebody please retry the xenial-i386 test on https://github.com/snapcore/snapd/pull/3475 ? It looks suspiciously not-a-problem-with-my-branch [09:23] PR snapd#3475: store: change main store host to api.snapcraft.io [09:27] actually, can someone do a second review on 3475 please? should be straightfoward (and an easy win) [09:31] cjwatson: I don't know if anyone can do this easily [09:32] cjwatson: I was talking to mvo about it a few days ago, that it is not easy to re-trigger those tests [09:32] mvo: I'll look at it in a bit [09:33] zyga: What options do I have? [09:34] cjwatson: no worries, once this has a second review it can go in [09:35] cjwatson: the autopkgtests are "extra", the only hard requirement is that travis is green which we have more control over. autopkgtest is still very useful as a canary for problems we may otherwise only see after a snapd deb upload [09:36] cjwatson: force push again, not sure [09:39] Ah, sounds like maybe I can just ignore the failing test then ... [09:40] cjwatson: yes, this is our problem, not yours :) [09:40] OK :) [09:40] I like the sound of that. [10:02] PR snapd#3496 opened: cmd/snap-repair: start of Runner, implement first pass of Peek and Fetch [10:06] mvo: ^ [10:07] pedronis: yeah, just peeked (no pun intended) at it. I'm looking at debian unstable right now, breaks all our tests [10:09] mvo: just a heads up really, I understand getting 2.26 out is out first priority [10:12] pedronis: thanks for this [10:15] PR snapd#3497 opened: spread: help libapt resolve installing libudev-dev [10:30] morphis: fgimenez: any luck with the debian thing? [10:31] Chipaca: can you drop the quiet around that gdebi call so we can see why it fails to install libudev? [10:32] morphis: if the gdebi call failed the quiet would print the output. Is it not failing? [10:32] or rather, is it not returning with exit_failure? [10:33] it should as it prints out it can't install libudev for whatever reason [10:33] i can also disable debian and let you dig; it's not just my PR that's failing in this way [10:33] no, don't disable debian [10:35] so something has changed which breaks this now [10:36] ah, you mean the --quiet [10:36] Chipaca: morphis snapd#3497 from mvo fixes it [10:36] not a prefix quiet but gdebi's --quiet itself [10:36] PR snapd#3497: spread: help libapt resolve installing libudev-dev [10:36] at what point did we regress prepare to run apt-get install eleventyfour times, once for each package we wanted to install? [10:37] ah! [10:37] we'd got it reduced to a single call or two at most :-( [10:37] because it added several minutes to the prepare time [10:38] Chipaca: I have a change pending to improve the pkgdb for that [10:39] morphis: what's the idea behind pkgdb? i mean, other distros will have differently-named packages for the same thing, yet last i looked at it it was still handling things at the package level [10:40] Chipaca: it abstracts package installation [10:40] morphis: yes, i get that [10:40] Chipaca: you give it something "cups" and it will figure out the right thing to do [10:40] morphis: but does it make sense, given package names are going to be different? [10:40] it will map "cups" to the right packages for each distro [10:40] based on the set SPREAD_SYSTEM [10:41] morphis: is "cups" a target, or a package name? [10:41] dunno if "target" is the right name [10:41] it's a name of a thing you want to install [10:41] it can be a package name [10:41] so we're going to carry around a table of package names per distro? [10:41] yes [10:42] that keeps these distro specific things out of the test cases [10:42] and you just have to express "I want cups" [10:46] Chipaca: but doing more than on apt-get call per distro_install_package call isn't what we should do [11:09] PR snapd#3498 opened: hooks: support for install and remove hooks [11:12] PR snapd#3497 closed: spread: help libapt resolve installing libudev-dev [11:23] mvo: btw. what is the state of the 2.26 release? [11:36] Chipaca: I'm getting repeated mail from github all the time about this checkin of yours: osutil: unexport KillProcessGroup until we have a use case (f67bedb) [11:36] are you doing anything strange? [11:36] or it's a github bug [12:03] morphis: seccomp-bpf needs to get merged, then we are unstuck again [12:03] mvo: ah [12:03] mvo: any timeline for this? [12:04] morphis: jamie and I are working on this as quick as possible, the goal is before the end of this week [12:04] hopefully sooner [12:04] ok [12:04] not pressure from my site, was just curious :-) [12:04] mvo: would be good to have an update on https://forum.snapcraft.io/t/in-progress-snapd-2-26-4/514/15 so everyone else knows too [12:07] pstolowski: small review of 3498 [12:07] cjwatson: reviewed that PR, +1 , couple small remarks [12:17] Mornings [12:18] How's Travis behaving this morning? Still issues? [12:18] hey niemeyer [12:18] * zyga hasn't seen any issues yet [12:19] niemeyer: have you seen this? [12:19] [12:19] [12:19] This job ran on our Trusty, sudo: required environment which will be updated on Wednesday, June 21st. Please add group: edge to your .travis.yml file to try the new images and check our blog for more details about this update. [12:20] zyga: Yeah, but that's just a note.. we were having some issues yesterday about authentication issues on Linode, which apparently is actually about Travis itself not being quite sane [12:21] We also saw at least once a message of packaging problems very early on in Travis setup land, before travis.yaml takes over [12:22] niemeyer: I saw a patch from mvo about debian and udev update, maybe that's that [12:23] (and also saw my branch fail on debian prepare) [12:24] yes, things are failing on debian atm [12:25] pedronis: thanks, pushed fixes [12:30] hey niemeyer, yes, we had authentication issues from travis to linode, seems to be better now [12:30] fgimenez: Any news from this morning? [12:32] niemeyer: we were getting this morning auth errors like https://travis-ci.org/snapcore/snapd/builds/244823012?utm_source=github_status&utm_medium=notification, recent executions don't show this error (i'm about to retrigger that one btw) [12:33] zyga: ping [12:35] morphis: hey, what's up? [12:36] zyga: I am currently looking into a failure of tests/main/interfaces-content on Fedora, https://paste.ubuntu.com/24907862/ [12:36] effectively I don't see the bind mount in place so wondering what I should look at [12:36] morphis: looking [12:37] with master, I presume [12:37] morphis: any SELinux denials? [12:37] no [12:37] but wait, maybe I have a clue [12:37] morphis: it's a new program, perhaps the policy is stale [12:37] the bind mount is in place, /var/lib/snapd/snaps/test-snapd-content-slot_2.snap on /snap/test-snapd-content-plug/2/import type squashfs (ro,nodev,relatime) [12:38] hah [12:38] $ echo $SNAP [12:38] /var/lib/snapd/snap/test-snapd-content-plug/2 [12:38] that is the reason why [12:38] morphis: updated the forum [12:38] mvo: thanks! === jdstrand_ is now known as jdstrand [12:38] morphis: I think we spoke about that [12:38] morphis: that $SNAP is wrong on Fedora [12:38] zyga: we did [12:39] morphis: I thought we fixed that but ... well :) [12:39] morphis: good catch [12:39] zyga: we fixed the content interface impl [12:39] but as it seems not the part which sets up SNAP [12:43] fgimenez: That's the same we were observing yesterday [12:43] fgimenez: Please let me know if you see it again.. I'll tweak spread to debug the problem if so [12:44] niemeyer: sure, thx [12:50] mvo: hey, yesterday I had some ideas on the testsuite but I forget to click 'Review changes' so they were pending til just now. Let me know if you have questions [12:52] jdstrand: o/ [12:52] jdstrand: cool, let me read it now [12:52] jdstrand: did you see me point you at a snap the other day? [12:52] jdstrand: I think all your other suggestions are now implemented, thanks again [12:53] Chipaca: I don't recall otoh. which snap? [12:53] jdstrand: test-snapd-service-notify [12:53] mvo: thank you :) once you are ready, I wanted to go through it one more time top to bottom [12:54] oh I definitely didn't see that [12:54] * jdstrand looks [12:54] Chipaca: I can also approve snaps fwiw [12:54] mvo: it's published :-) [12:54] mvo: it's about it getting DENIEDs because it's notify [12:54] Chipaca: ok, yes, it is in the store and published. what do you need? [12:54] ah [12:55] jdstrand: if you install it, you'll see denies [12:55] jdstrand: so first a question: is it a bug in the snap, ie is it expected, or is it a bug in our confinement? [12:55] Chipaca: is this as script or compiled code? if compiled code, where is the source? [12:55] if the latter, i can file a bug and all :-) [12:55] jdstrand: it's not compiled [12:55] jdstrand: it's python, using the system python, and a sdnotify.py included in the snap [12:55] let me look at it. I feel like I remember this was intentional [12:56] Chipaca: aha, sorry, then I misunderstood [12:56] I remember we did talk about how you were seeing denials and would get back to me [12:56] mvo: I don't know how you could've possibly misunderstood my vague insinuations at the half-formed predecessors of ideas [12:57] jdstrand: this is that :-) [12:57] yeah, c'mon mvo [12:57] Chipaca: yep :) [12:57] Chipaca: lol [12:59] PR snapd#3480 closed: overlord/cmdstate: new package for running commands as tasks [13:00] jdstrand: thanks for your comments, that looks very nice. I have the standup now, I will get back to it. I'm not sure I understand the "runimentary" part in the simulateBpf suggestion. unless I miss something (and modulo bugs) this should be exactly the same bpf environment that the kernel is using. we can talk after the standup if you want, maybe I'm missing something [13:03] mvo: it isn't the same bpf vm as the kernel and we can't launch programs under it [13:03] and so* [13:04] by using the kernel, we can prove to ourselves it will work (well, at least on those kernels) and by running a program under it, even if it is /bin/true, we can prove to ourselves that the bpf is sane enough to be useable as a seccomp filter === mhall119_ is now known as mhall119 [13:06] you are right that the fact that it compiles and is usable under the bpf vm shows a good deal (since the tested bpf needs to be good enough for both the vm and the kernel to use) [13:06] mvo: ^ [13:19] Chipaca: ok, this needs a new interface because in 'man sd_notify' we see that sd_pid_notify() and sd_pid_notifyf() allow specifying a pid as the originating pid of the message, so a snap would be able to send status messages to systemd-notify for other processes not part of the snap [13:20] Chipaca: this interface would consist of a comment along the lines of what I just mentioned and this rule '/run/systemd/notify w,' [13:24] Chipaca: were you planning on using this mechanism by default? [13:27] Chipaca: it looks like that interface could also include this rule: /{,usr/}bin/systemd-notify ixr, [13:27] jdstrand: the only mechanism i think we wanted to support is notifying systemd itself (ie the READY=1 thing i think, plus the watchdog one?) but I think you're saying that you can't separate these things? [13:29] jdstrand: thanks, yeah. I think both tests complement each other nicely, the nice thing aobut the VM is that we can easily test the KILL works and the whole thing is more controlled. but +1 for both tests [13:29] jdstrand: I look into this now [13:30] jdstrand: that last "you" was meant in the same generic "we"/"one" voice I was using before, I'm not saying you personally can't separate them :-) [13:31] Chipaca: apparmor cannot-- it either gives access to the socket or it does not. access to the socket means that only DAC permissions will protect you, so if you are a root daemon, you can send status messages for other root daemons, based on the man page. I did not test this with code [13:31] * Chipaca nods [13:32] mvo: yes, not advocating for removing the vm (though a fork/exec could handle the kill ok) [13:32] but yeah [13:32] Hi, is it possible that the localhost has 2 login IDs? [13:32] Chipaca: do you want me to dive deeper on that? [13:33] Chipaca: I suspect I will only prove my assertion since the man page says that is what the api is designed to do [13:33] jdstrand: and in any case we'd want the interface to support the broader use [13:33] jdstrand: so, maybe jot it down to do in your copious free time [13:33] Vamsi: pardon? [13:34] jdstrand: it==the deeper dive i mean [13:34] Chipaca: systemd could be updated to mediate that better since it says 'provided the appropriate privileges are available'. it could query the LSM (eg, AppArmor) to do more than just check DAC/capabilities [13:35] Chipaca: to login the local host is showing two ssh IDs. [13:35] Chipaca: how about I just create the interface and then detail everything in comments? [13:35] jdstrand: A+ [13:35] I don't have any problem with the interface since users get to decide (or snap decls) [13:36] yup [13:36] Chipaca: when do you need this? [13:36] For example: blah@172.18.0.65 and blah@172.19.0.65 [13:36] jdstrand: no present urgency [13:37] Vamsi: where are you seeing this? What is the system running? [13:37] Chipaca: ok, after the bpf and profile regeneration mvo is working on, and after password-manager-service, I'll do this (that puts it ahead of getting back to wayland, but this shouldn't take too long so I think that is ok. I might be able to squeeze it in somewhere sooner [13:37] ) [13:38] jdstrand: perfect, thank you [13:38] * Chipaca watches Vamsi go off and is left wondering [13:40] Chipaca: I have connected my Ubuntu core local host to a monitor and that's where I see this. [13:41] ogra: do you know if we print both addresses if you have more than one live interface? [13:41] i think we do, yeah [13:41] Vamsi: does your device actually have two network interfaces? [13:42] they both need to be up and have an assigned IP [13:42] Chipaca: I was initially using it on another network. And now changed the network. [13:43] that shouldn't cause it [13:43] so ssh in ... run sudo console-conf and de-confiigure the unused interface [13:43] or should it? [13:43] ogra: ? [13:43] Chipaca, well, if he used a fixed IP that IP would still be set [13:43] ogra: right, but if it were fixed it wouldn't pick up a new one [13:44] ogra: and if it's dynamic it should just pick up the new one [13:44] on that device [13:44] Vamsi: I didn't see you answer: do you actually have two network interfaces on this device? [13:44] mvo, Chipaca: What builds were failing on the auth issue? [13:44] niemeyer: aw, i just restarted one [13:44] niemeyer: but, chances are it'll be back [13:44] Chipaca: np, goal was to restart indeed.. do you have a link? [13:45] (travis is slow so it'll take a while to start) [13:45] Chipaca: No. only one at a time. I had to change to a different because of some reasons. [13:45] I've pushed an initial debug build of spread [13:45] niemeyer: https://travis-ci.org/snapcore/snapd/builds/244930470 is the one i just restarted [13:45] THanks [13:46] niemeyer: seems to be 1:4 success rate right now, so you should see it fail again soon [13:46] it just started, in fact [13:46] mvo: Looks like yours passed [13:46] PR snapd#3475 closed: store: change main store host to api.snapcraft.io [13:46] niemeyer: it failed again [13:46] niemeyer: yeah, I had a bunch of issues this morning but the current one seems to be ok [13:47] Chipaca: Great, let me see [13:47] Vamsi: are you able to access the device? [13:48] Vamsi: over the network to one of those two addresses? [13:48] Vamsi: actually, could you open a forum topic with all this? that way the console-conf people will also be able to help (i think they're in APAC tz) [13:49] niemeyer: does that tell you anything? [13:52] Chipaca: It does.. the environment seems right, which puts the doubt back on Linode.. I'll print out part of the actual key right before sending to be 100% sure [13:54] niemeyer: maybe do a 'printenv'-like thing? [13:54] i thought we had a printenv but i guess we ditched to save space in the logs [13:54] Chipaca: We do that already [13:54] Chipaca: Right before the call to spread [13:55] Chipaca: (it's folded) [13:55] ah so we do [13:55] Okay, there we go again.. hold tight [13:55] jdstrand: hey, can you review https://github.com/snapcore/snapd/pull/3464 please [13:55] PR snapd#3464: interfaces: put base policy fragments inside each interface [13:55] jdstrand: ideally before new interfaces land :) [13:56] niemeyer: -_- are you printing it at every api call? [13:56] Chipaca: Oh no... it passed.. that's going to be a long log :) [13:56] niemeyer: that's a lot of api calls [13:56] zyga: yes it is on my list. it is after the bpf stuff atm [13:57] niemeyer: cancel the build, i'm told spread loves that [13:57] Chipaca: Yeah, we monitor the machines to see if they go down [13:57] jdstrand: perfect, thank you [13:57] Chipaca: Because they take a very long time to restart.. [13:57] I should optimize that so it uses less calls [14:03] Alright.. future runs won't print sooo much data [14:20] niemeyer: hello :) [14:21] niemeyer: when you have a sec we'd love your feedback in https://forum.snapcraft.io/t/edge-case-scenarios-for-snap-validations/1036 [14:21] PR snapd#3499 opened: Spi patch [14:30] Chipaca: It passed, despite a reaaaaaaaly long log [14:30] niemeyer: I'm sorry [14:31]