=== chihchun_afk is now known as chihchun [04:11] PR snapcraft#1393 opened: python plugin: output json in pip list [05:05] PR snapd#3564 opened: tests: speedup prepare statement part 1 === mjl_ is now known as mjl === stokachu_ is now known as stokachu === cargonza_ is now known as cargonza === oh4_ is now known as oh4 === souther_ is now known as souther [07:24] PR snapd#3561 closed: tests: store /etc/systemd/system/snap-*core*.mount in snapd-state.tar.gz [07:24] PR snapd#3563 closed: release: merge release/2.26 branch back into master [07:26] PR snapcraft#1394 opened: tests: document the test suites in the snapcraft repo [07:29] re [07:37] PR snapd#3551 closed: systemd, osutil: rework systemd logs in preparation for services commands [07:42] PR snapd#3504 closed: interfaces: bring back seccomp argument filtering [07:43] a second review for 3501 would be great, looks very straightforward [07:45] zyga: maybe 3491 is sometihng that you could review? just needs a second review [07:46] morning! [07:46] mvo: certainly, with pleasure [07:47] hey morphis [07:47] zyga: thank you! [07:48] zyga, mvo: how was the sprint last week? [07:48] morphis: very productive [07:49] morphis: but also some bugs interfered [07:50] oh bad [07:50] zyga: still for the 2.26 release? [07:51] morphis: indeed [07:51] I guess you had a lot fun last week :-) [07:54] morphis: *cough* [07:55] fgimenez: snapd 2.26.8 is now also -proposed everywhere and ready for SRU testing [07:59] mvo: great thanks, on it, we should have proper detection now on spread-cron, could you please check the date the tests were triggered? https://travis-ci.org/snapcore/spread-cron/builds/250440323 [08:02] fgimenez: 14h ago sounds about right [08:03] mvo, pstolowski: reviewed https://github.com/snapcore/snapd/pull/3491#pullrequestreview-48258965 [08:03] PR snapd#3491: snapd: generate snap cookies on startup [08:05] zyga, thanks! [08:06] mvo: cool thx [08:31] PR snapd#3565 opened: cmd/snap-repair: skeleton code around actually running a repair [08:32] mvo: hi, this ^ is the last of a chain, it has some skeleton code (similar to what you had in one of your branches) about where actually running the repair could happen [08:33] pedronis: nice, thank you! [08:34] mvo: I have a wip branch with code to actually verify the signature of the repair, anyway that plugs in one of the previous pieces in the chain where there's a todo [08:35] pedronis: ok, I need to tie up some loose ends and then I can jump on it [08:36] mvo: it's quite a bit of code in those PRs :/ the fetching is a bit complicated [08:37] pedronis: yeah, I noticed, I peeked over them already (but not review carefully yet) [08:39] mvo: anyway mostly saying, getting those pieces into shape for landing or changing as needed, running and small TODOs in those branches should be all things that can be worked on while I'm of, verification is probably something that I can pick up again when I'm back, anyway the server bits still needs a bit more work too [08:40] mvo: so as I said in the standup, depending on timings, 2.28 or 2.29 are probably more realistic goals to get this all pieced together [08:42] mvo: btw about file names etc, I'm following the current stuff in "transparent" section of the forum topic [08:42] if we change those we should change the topic as well [08:43] pedronis: ok, sounds good [08:44] mvo: sorry for the info dump, but I'm off a bit this afternoon as I said, and you are taking tomorrow off? [08:45] pedronis: correct [08:45] pedronis: no need to be sorry, I appreciate the update :) [08:47] mvo: I migtht also get a PR up, today or tomorrow about reading brand/model out of the seed/assertions data, haven't started yet though and want to work also on something else [08:47] unrelated to repairs [08:48] ta [08:49] I'll put a link in the forum if I get to it [08:49] (the other PRs are also already linked from there) [08:52] mvo, pstolowski: trivial and long overdue https://github.com/snapcore/snapd/pull/3566 [08:52] PR snapd#3566: interfaces: fix copy-pasted iio vs io in io-ports-control [08:53] PR snapd#3566 opened: interfaces: fix copy-pasted iio vs io in io-ports-control [08:54] zyga, looks good, but I think the test file has the same issue? s/iio/io there too? [09:00] pstolowski: which one? [09:00] pstolowski: I only see iio_* files having iio identifiers [09:01] zyga, io_ports_control_test.go has Iio* [09:01] ah, I didn't look for Iio :) [09:01] thanks [09:01] fixed [09:02] pushed [09:02] thanks [09:05] +1 [09:24] PR snapd#3518 closed: cmd/snap-confine: various small fixes and tweaks to seccomp support code [09:36] mvo: zyga i'm getting an error on trusty when trying to install core from beta http://paste.ubuntu.com/25031042/ [09:38] fgimenez: looking [09:38] fgimenez: what version of libseccomp do you have installed in that machine? is it the latest from -updates? [09:38] pedronis: is there a sorting requirement for a series? [09:38] interesting [09:39] mvo: missing dep on snapd? [09:39] pedronis: that is, in “series, err := stringList(headers, "series")”, can series be assumed sorted? [09:39] mvo: thread synchronization is a feature that was not originally in the distro [09:39] Chipaca: not atm [09:39] mvo: let me check [09:40] pedronis: aw [09:40] Chipaca: I think it's also fair to assume there's not bazillion of them [09:40] pedronis: was hoping we could drop one of the implementations of inStringList [09:40] :-) [09:40] Chipaca: I suppose we have copies of two ? (sorted and unsorted) [09:41] time to put those into strutil? [09:41] yeah [09:41] pedronis: and there's testutils's Contains, just for extra fun [09:41] testutil's* [09:41] test and prod should not meet :) [09:41] or something [09:42] mvo: http://paste.ubuntu.com/25031072/, libseccomp2 is at 2.1.1-1ubuntu1~trusty3 [09:42] * zyga hugs contains [09:43] pedronis: yeah, testutil's is all about reflect :-) [09:44] fgimenez: this looks good, how strange [09:45] fgimenez: how strange - those tests passed in linode/spread [09:45] fgimenez: aha, what kernel is running? [09:45] mvo: for the sru validation we install the package from the archive, it's the only difference afaict [09:46] mvo: 4.4.0-85-generic from snap version [09:46] fgimenez: what does uname -r tell you? [09:47] mvo: same, 4.4.0-85-generic [09:47] fgimenez: confusing, I have a look [09:47] mvo: i can prepare a tunnel if you want to log in the machine [09:48] fgimenez: I start with my local vm [09:48] fgimenez: but thank you [09:48] mvo: great thanks [09:48] mvo: it does look good "on paper" [09:48] Chipaca: I see for 4 "contains" around, so maybe indeed worth a look [09:49] zyga: what exactly :) the kernel version? or the code? or sometihng-else? [09:50] Chipaca: seems a its own branch thing though [09:50] totz [09:50] * pedronis lunch [09:51] pedronis: which are the four? I see this new "inStringList", overlord/snapstate's contains, and one contains in interfaces/policy/basedeclaration_test [09:51] this is studiously ignoring the one in testutil ;-) [09:51] and vendor obvs [09:51] there are some that are even declared locally [09:52] ./partition/grubenv/grubenv.go: var contains = func(needle string, haystack []string) bool [09:52] ./daemon/api.go: contains := func(needle string, haystack []string) bool { [09:52] as well [09:52] ah [09:52] and haven't looked to hard with things name like my in* [09:53] *too hard for things* [09:53] my grep was looking for ^func :-) [09:53] * Chipaca tries harder [09:53] * pedronis really lunch [09:53] Chipaca: that's not the full story(tm) :) [09:54] mvo: zyga for reference these are all the steps taken during sru validation for putting the snapd package in place https://github.com/snapcore/snapd/blob/release/2.26/tests/lib/apt.sh#L15 we begin from the package in updates, then add the proposed pocket and upgrade snapd from it [09:58] 3× unsorted, 1× sorted [09:58] I'll add strutil.ListContains and strutil.SortedListContains [10:00] re! [10:00] ha [10:00] stupid orange modem [10:02] fgimenez: I can reproduce the issue on 14.04 [10:05] * zyga tries one more thing with his network [10:08] zyga: Wat heb je tegen het Huis van Oranje? [10:08] zyga: (or something) === ahrs_ is now known as ahrs [10:24] maybe this will hold, for now [10:49] mvo, do you know from top of your head where do we set refresh.schedule to 0 in our tests? (it's also possible we don't actually do this and I've a bug in my branch) [10:51] i couldn't find any explicit assignment, so perhaps it's set automagically somewhere [10:54] * pstolowski lunch [10:56] PR snapd#3566 closed: interfaces: fix copy-pasted iio vs io in io-ports-control [10:57] pstolowski: iirc this is just the default value [10:57] PR snapd#3553 closed: interfaces: enable access to bridge settings [11:00] PR snapd#3555 closed: assserts,overlord/assertstate: test we don't accept chains of assertions founded on a self-signed key coming externally [11:02] mvo: any idea about 14.04 error? [11:03] mvo: is that on 3.13 or on the LTS kernel? [11:03] zyga: I can reproduce it on the lts kernel - but only with snap install --beta core - not with the stable core [11:03] mvo: hum hum hum [11:04] mvo: so does it indicate we are using a new version/feature/code branch in libseccomp? [11:04] mvo: when I was diffing libseccomp at the sprint I did see tsync patches [11:04] pstolowski: there are lines doing snap set core refresh.* = ... in prepare.sh ? do you mean something else? [11:06] pstolowski: ah, you meant unit tests? [11:20] zyga: I'm not sure what it means yet unfortunately. maybe a missing patch in the libseccomp backport for trusty [11:31] WTF! [11:32] ppisati, something does always release the unusable newer kernel to stable, only you, me, the kernel team and mvo have access [11:32] i dont get how that happens, is the kernel team running any scripts ? [11:33] (this is the third time i had to roll back the snap) [11:34] * ogra_ talks about pi2-kernel here [11:35] ogra_: yep, you me and my team [11:35] ogra_: i guess someone inside my team is doing it, though it shouldn't go to -stable [11:35] ogra_: but unusable why? [11:35] ogra_: for the dtb relocation? [11:36] ppisati, because the dtb we ship in the gadget doesnt boot with anything newer than rev 22 of the pi2-kernel snap [11:36] only the gadget updates implementation will fix that ... but thats still far out [11:37] ogra_: ok, let me work it out [11:37] (we cant update the dtb on disk of users yet .... so we're stuck with the kernel revision the first stable image had) [11:37] ppisati, thanks [11:37] i hope it at least rolls back properly ... :) [11:38] * ogra_ never runs stable ... [11:38] ogra_: so, the kernel snap creation script automatically pushes the kernel to "candidate, beta" [11:38] https://code.launchpad.net/~ubuntu-kernel/+snap/pi2-kernel [11:38] thats fine [11:38] so, someone else is moving it to -stable [11:38] could also push to edge if you feel like [11:38] let me find my whip and this guy [11:39] :) [11:42] ppisati, since we're just talking ... i'll likely need a fix in the vc4 setup ... seems loading the overlay dtb for it breaks the kernels "simple framebuffer" ... using something that writes to /dev/fb0 directly with that overlay loaded makes the board hang hard (see my last comment on bug 1701018 ) [11:42] Bug #1701018: Splash screen is not enabled in kernel [11:44] might be that https://github.com/raspberrypi/firmware/issues/597 is related ... there seems to be a dtb fix [11:57] ogra_: "psplash only works with a working simple framebuffer driver, so this option needs to be disabled" [11:57] ogra_: FB_SIMPLE (the simple-framebuffer kernel driver) is already off, because if i turn it on, it'll attach (and screw actually) to the simple-framebuffer DT node, injected by u-boot [11:59] ppisati, well, somehow vc4 breaks fb0 ... and i see a patch (added a link to the bug) [11:59] there seems to be a corresponding u-boot dt change too though [12:00] ogra_: what does vc4-kms-v3d do? [12:00] turn on vc4 acceleration [12:00] it is needed for GLES and mir-kiosk [12:00] ogra_: ok, is there a way for me to test if this acceleration is on? [12:01] ppisati, use an ubuntu core image, we have it on by default there [12:01] beyond that, just set the option in your config.txt on a classic install ... should do the same [12:02] ogra_: but if we already have this acceleration on, why do we need this vc4-kms-v3d overlay? [12:02] no [12:02] we have the overlay loaded by default [12:03] (which turns it on) [12:03] without the dtbo you dont have any acceleration [12:04] ogra_: uhm, ok [12:04] i havent seen any prrobs with it yet until i tried to use psplash on it ... (psplash works fine on all other boards) [12:04] Chipaca: thanks for the reviews btw, bit surprised the Next one didn't get any extra comments :) [12:05] Chipaca: mvo: as I mentioned yesterday, going to be off for some hours from now, so no standup for me today [12:07] pedronis, Chipaca: thanks for the notification. I may also not make it today, a repairman is scheduled for this afternoon and the time is a bit uncertain [12:15] pedronis: hrm, maybe i missed something? :-) [12:25] mvo: I'm not familiar with the 'tsync bit' error. It seems to be a libseccomp-golang thing though: https://github.com/seccomp/libseccomp-golang/blob/master/seccomp.go#L497 [12:27] mvo: strike that. I see libseccomp-golang give that error string, but libseccomp does reference tsync [12:28] mvo: I did see this: https://github.com/seccomp/libseccomp/issues/20 [12:29] mvo: which may me wonder if libseccomp on trusty is built with a 3.13 kernel (as opposed to lts kernel), perhaps it isn't being built with tsync support [12:29] mvo: (guess) [12:30] mvo: I then saw https://github.com/seccomp/libseccomp/commit/a1f144a9a28aa1b831f7d3f481fb3e0e5e3de3aa [12:30] "The seccomp() syscall was first added in Linux 3.17 so most systems [12:30] should now support this syscall. Most importantly, the use of the [12:30] seccomp() syscall enabled the thread sync functionality which isn't [12:30] possible with prctl(); although callers still need to enable the flag [12:30] per-filter as the thread sync default is disabled." [12:31] mvo: with snap-seccomp, we moved to prctl [12:32] pedronis, mvo thanks, it was about spread tests and refresh schedule [12:32] mvo: maybe if we appropriately used the seccomp syscall, this would resolve itself? [12:33] jdstrand: sorry, disconnected, you mean use seccomp() instead of prctl() ? [12:33] mvo_: yes. let me give you full context [12:33] mvo, pedronis with my changes wrt json decoding it now requires " to be escaped around timestamp, otherwise it treats it as number taking leading 0 ang ignoring the rest :( [12:34] mvo_, pedronis has to do with shell eating quotes I suppose [12:34] mvo_, pedronis so snap set core refresh.schedule="0:00-23:59" needs to be snap set core refresh.schedule=\"0:00-23:59\" [12:34] mvo_: http://paste.ubuntu.com/25031898/ [12:34] bummer [12:36] jdstrand: aha, thank you - yes, I have a look [12:36] mvo_: fingers crossed :) [12:36] pstolowski: oh, nice find [12:38] mvo_, well, it's *after* my changes [12:39] mvo_: I'm not sure if this will be needed for libseccomp on trusty: https://github.com/seccomp/libseccomp/commit/08a682a9f895b8f622499df5ee69fcabe1e3cbab [12:40] (but not sure if naively applying that would cause problems for libseccomp with non-lts kernel) [12:40] jdstrand: hm, indeed, it sounds slightly dangerous [12:40] mvo_: actually, if you are calling the seccomp syscall directly, you aren't using libseccomp, so that should be needed [12:41] jdstrand: shouldor should not? [12:41] I guess we'll need to see what libseccomp-golang ends up doing if you use seccomp syscall instead of prctl [12:41] mvo_, this is bad, becase it means it may break for people on their variables if they start with a number (one such case is also in our tests - an IP address) [12:41] mvo_: heh, shoud *not* [12:41] sould* [12:41] argh [12:41] jdstrand: :) no worries [12:41] s h o u l d n o t [12:41] :) [12:41] jdstrand: lol [12:42] I'm not using my external keyboard atm. I'll blame that [12:43] my laptop keyboard likes to occasionally drop entire words [12:43] :) [12:45] jdstrand: o/ [12:46] jdstrand: interesting observation on prctl vs seccomp syscall (darn flags) [12:47] * zyga thinks about skipping standup and having lunch instead [12:47] jdstrand: is it possible that cat /sys/kernel/security/apparmor/policy/*/raw_data truncates stuff? [12:51] mvo_: is this sensbile? pastebin.ubuntu.com/25031983/ [12:51] zyga-suse: hm, with the latest master this shoudl be fixed [12:51] zyga-suse: is our branch current? [12:54] mvo_: this is from https://github.com/snapcore/snapd/pull/3531 (10 days ago) [12:54] PR snapd#3531: interfaces: updates default, mir, optical-observe, system-observe, screen-inhibit-control and unity7 [13:00] zyga: it just needs master [13:00] niemeyer: sorry, I miss standup, there is a repairman at the door [13:00] mvo_: np, thanks for the note [13:08] zyga: I am not familiar with those interfaces. curious why you a playing with them, but jjohansen would be the person to ask [13:09] ppisati, did you see bug 1691729 ... seems a few classic users have actual probs with it [13:09] Bug #1691729: linux-firmware-raspi2 conflicts with linux-firmware over brcmfmac43430-sdio.bin [13:11] jdstrand: I can give you some advice but I already spoke with jj about that [13:18] zyga: is this for a pending PR? [13:20] ogra_: added to my list - i think that is the bluetooth fw [13:21] ah [13:26] jdstrand: more like bug hunting [13:26] I see [13:26] jdstrand: trying to figure out why people bump into the issue with snap-confine using old profile [13:26] zyga: talked to jj about truncating possiblility. I would think 'no' but that is based on nothing :) [13:26] jdstrand: and one case where it seems profiles are in wonky state and only work after re-loading by hand [13:27] ah that [13:27] * zyga learned x10 more about how apparmor works in the last week [13:28] volunteering for the security team ? [13:28] :) [13:28] zyga: I'm not saying this is it, but keep in mind when the cache file is used and when it isn't [13:29] zyga: it is possible to get into situations where an old cache file is loaded into the kernel, then the thing runs with it, then it is loaded/updated later [13:30] so at debug time, everything looks ok, but at the moment of the access, the old cache was in place [13:30] this is just general advice not anything specific to what you are doing [13:31] also, with snapd deciding which snap-confine and which profile to use, that could get even more interesting [13:33] PR snapd#3567 opened: many: introduce and use strutil.ListContains [13:33] jdstrand: yes, that's a good point, cache is bypassed when we upgrade packages [13:33] jdstrand: but we write to the cache in that case [13:36] if I were debugging this, I would try to trace the whole process from boot to denial to debug time. tracing for when apparmor unit loads the profile, when snap-confine runs at all, what profile it is running under, the cache mtimes vs profile mtimes at time you run apparmor_parser, etc [13:36] jdstrand: I'd love to see this reproduced first [13:36] oh still no reproducer. that is unfortunate to say the least [13:36] yes [13:37] so working "dry" [13:37] and reading binary profiles [13:37] (very interesting btw) [13:37] but if your tracing is in place, maybe you can see a potential race [13:39] zyga: (also what options are being used with apparmor_parser whenever it is called) [13:40] pstolowski, zyga: This is the issue: https://play.golang.org/p/qyx_D3F-DO [13:40] jdstrand: -T -W [13:41] pstolowski: When you use a decoder, it handles the input as a stream [13:41] niemeyer, aaah! [13:41] niemeyer: WAT? [13:41] niemeyer: ah [13:41] pstolowski: It's decoding the first integer, and waiting for instructions [13:42] niemeyer, indeed... [13:42] so all we have to do is to ensure we reached end of the input [13:43] zyga: I meant as part of the tracing exercise (if you are going to do that). seeing the arguments that are actually being used rather than what you expect them to use [13:44] pedronis: i couldn't resist and threw together snapd#3567 [13:44] PR snapd#3567: many: introduce and use strutil.ListContains [13:44] jdstrand: interesting, I'll patch my system to log apparmor_parser invocations [13:59] travis seems to have network hicckups [14:31] spread times out on snapd downloads with speeds of 50KB/s [14:31] that's pretty slow [14:49] * zyga-suse dinner [15:00] ogra_: that linux-raspi2-firmware package wasn't the one in the archive, but one from a PPA [15:00] lp1691729 [15:00] bug1691729 [15:00] ppisati, oh sigh ...again ? [15:00] ogra_: yes [15:01] iirc the last big issue was also some PPA stuff [15:01] oh my [15:01] JamieBennett, ^^^ [15:01] well, we deserve the blame because we never generated an ubuntu classic img so far [15:01] What is required to update the 'current' link for the ubuntu-core images? The 'stable' image for pi3 is still using an image from 2017-03-14, but much newer stable pi3 images exist [15:01] this link: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ [15:02] ppisati, huh ? we do have http://cdimage.ubuntu.com/ubuntu-server/xenial/daily-preinstalled/current/ [15:02] oh, you are talking about pi3 i guess [15:02] fginther, "ubuntu-core" ?!? [15:03] ogasawara, this is what https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 links to [15:03] fginther, thats dead and gone since ages ... your board should have migrated from "ubuntu-core" to "core" quite a while ago [15:03] so, this is just crufty websites? [15:03] fginther, right, i'm talking about the snap on your system :) [15:03] nah [15:03] the images are fine, they should all auto-migrate to core [15:03] oh, snap list shows it as "core" [15:04] core 16-2.26.8 2331 canonical - [15:04] ogra_: yes, pi3 [15:04] that sounds recent [15:07] fginther: what? No it links to http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz [15:07] Oh sorry, misread the thread :) [15:08] davidcalle, yeah, naming issues (snap vs image name) : [15:08] :) [15:09] * davidcalle got scared for a second [15:10] (the chain of notifications made it look like http://cdimage.ubuntu.com/ubuntu-server/xenial/daily-preinstalled/current/ was the link on developer.ubuntu.com) [15:10] hhe [15:10] heh [15:13] The pi3 image at http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz does have a bug (https://bugs.launchpad.net/snappy/+bug/1678076), but newer 'stable' images don't. I was curious if the fix for the bug is to just update the current link. [15:13] Bug #1678076: console-conf crashes with eth0 and wlan0 on Pi 3 [15:16] fginther, i dont know what conditions need to be fulfilled to have the ones in pending/ move to current/ ... there are definitely newer ones in pending [15:17] i guess the QA for them isnt done yet (they are only a day old) [15:18] fginther, fgimenez and slangasek might be able to tell you though :) [15:18] zyga: it shouldn't truncate, and you should be able to use multiple reads/search etc [15:18] iirc federico is the gatekeeper and slangasek owns the setting of the links [15:19] that being said the lxd guys reported occasionally getting a truncated file, but I could never reproduce [15:21] ogra_, thanks for the info. I'll follow up with fgimenez [15:21] once I test this again and have better info [15:23] Chipaca: lgtm but the tests aren't happy on that branch [15:23] ah, i didn't run the full unit tests [15:23] fginther, note that wlan-only installs do not work yet though ... only the python traceback issue of that bug will be fixed [15:23] literally just threw the branch together [15:23] i'll take a look in a bit [15:24] PR snapd#3568 opened: snapctl: add new `snapctl internal configure-core` [15:25] ogra_, thanks [15:25] jjohansen: interesting [15:25] jjohansen: thank you [15:25] (there is another bug i cant find right now) [15:27] https://bugs.launchpad.net/snappy/+bug/1632387 looks promising [15:27] Bug #1632387: console-conf wifi only setup on pi3 beta3 image not possible [15:29] fginther, yeah, thats the one [15:29] fginther, it works fine after the first reboot ... you can just run "sudo console-conf", turn of eth0 and configure wlan just fine [15:30] only the very first boot breaks ... [15:30] ogra_, right, that worked for me (wlan only works if you restart during console-conf) [15:30] well [15:30]