=== JoshStrobl|AFK is now known as JoshStrobl === jamesh_ is now known as jamesh [02:14] PR snapcraft#1517 closed: vcs: ignore .vscode project settings [05:41] good morning [05:58] * zyga-ubuntu updates debian snapd to .5 [06:01] hello mvo [06:04] PR snapd#3502 closed: snap-seccomp: add in-kernel bpf tests [06:04] hey zyga-ubuntu, good morning [06:04] zyga-ubuntu: how are you? happy about better network :)? [06:05] mvo: yes, I just installed debian-keyring in a blink of an eye [06:05] mvo: and that's a welcome sight :) [06:05] mvo: I'm working on the .5 update for debian [06:15] mvo: could you please upload the extra tarballs to https://github.com/snapcore/snapd/releases/tag/2.27.5 [06:20] zyga-ubuntu: uh, thank you, doing that now. sorry [06:23] * zyga-ubuntu is sad to see gustavo remove 2.28 from 3814 [06:23] zyga-ubuntu: updated [06:24] thank you [06:37] PR snapd#3812 closed: interfaces: expose bluez interface on classic OS [06:57] hmm [06:57] * zyga-ubuntu tries to wrap his head around the git tree for debian snapd [07:18] lool, maybe you know, what is this flash-kernel package? [07:42] pedronis: 3781 has two +1 and green tests, this can go in, right? [07:47] mvo: yes, I think so [07:53] PR snapd#3781 closed: cmd/snap-repair: track and use a lower bound for the time for TLS checks [08:06] mwhudson: hey [08:06] mwhudson: around? [08:06] zyga-ubuntu: ish [08:06] mwhudson: so, I looked at other distros but now I'm back to debian [08:06] mwhudson: how should I approach this? I see git-buildpackage files [08:06] mwhudson: what is the workflow? [08:07] mwhudson: I have both the gbp tree and the dst files from .4 [08:07] mwhudson: should I import-orig? [08:07] zyga-ubuntu: i don't really use gbp much i guess [08:07] mwhudson: ok, so how do you maintain the git repo at alioth? [08:08] git merge 2.27.5; dch; git push i think [08:08] oh git commit as well of course :) [08:08] mwhudson: so merge the snapd upstream repository in this manually? [08:09] yeah, i have upstream as a remote [08:09] * zyga-ubuntu tries [08:14] * zyga-ubuntu tries building [08:14] mwhudson: thanks, I was approaching this from the wrong angle [08:14] mwhudson: will you dput if I push it back? [08:14] mwhudson: reviewdput [08:14] review/dput [08:14] zyga-ubuntu: yes, tomorrow :) [08:15] mwhudson: ok [08:15] mwhudson: I mean, just the changelog [08:15] apart from that it was a clean merge [08:15] zyga-ubuntu: cool [08:15] http://paste.ubuntu.com/25437187/ [08:16] mwhudson: I can dput if I have the permissions to do so [08:16] zyga-ubuntu: push [08:16] pls [08:16] k [08:16] :) [08:16] sorry for terseness, a bit tired :) [08:18] mvo: what's the plan for 2.28 now? === JoshStrobl is now known as JoshStrobl|AFK [08:20] mwhudson: pushed [08:23] pedronis: I it seems 2.27.5 is looking good, so today might be a good day to fork it, I have not checked the 2.28 milestones yet though [08:25] mvo: there's one PR by zyga, seems a bit of a stretch to fit it in, unless we want to do it next week [08:26] pedronis: let me have a look, we could create the 2.28 branch on monday too, that has the added benefit that 2.27 should be out of the door by then [08:26] pedronis: 2.27.5 in stable hopefully [08:26] mvo: #3621 [08:26] PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns [08:26] pedronis: aha, yeah, this one looks risky [08:27] mvo: risky? [08:27] zyga-ubuntu: well, lots of feedback from jamie, no gustavo review yet, risky in the sense that it may take time to get it in shape [08:28] mvo: this was reviewed by gustavo already [08:28] mvo: we did it over a hangout [08:28] mvo: the feedback I reacted to was actually from gustavo originally [08:28] he should probably vote too for clarity [08:28] zyga-ubuntu: aha, I don't see anything in the PR itself about this [08:28] mvo: I'm only worried about one thing: https://github.com/snapcore/snapd/pull/3621#discussion_r136204646 [08:28] PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns [08:28] zyga-ubuntu: exactly what pedronis said, hard for others to know that [08:28] mvo: yes, gustavo didn't comment [08:28] anywway jamie didn't finish his review yesterday [08:29] mvo: I think I need to talk to jamie about that point as I wasn't planning on confining snap-update-ns yet [08:29] zyga-ubuntu: aha, ok [08:29] it's way further down the line and I don't think this is any less safe [08:29] (since snapd already calls it unconfined on interface changes) [08:29] zyga-ubuntu: right, so that is what I mean with "risky", it seems there are some open points still [08:30] zyga-ubuntu: anyway, if its important we can wait, but I don't want to wait long :) [08:30] * zyga-ubuntu would love to get some real-world testing for this [08:30] right [08:30] we should be careful not too move thing so much that 2.29 is after the rally [08:31] pedronis: gustavo has some questions in 3773 about the possiblity to simplify the repair logs by overwriting some old data. I'm slightly concerned about the possible information loss but OTOH it will mean a much more tidy output. have you seen his comment? [08:31] yes, I have seen his comment [08:32] pedronis: good point about the rally [08:33] mvo: I suppose if we send execution where exit status != 0 to errtracker, losing data is a bit less of an issue [08:33] the script doesn't change for the same revision [08:33] so as long as we keep enough info to know which revno we *did* run, it should be ok [08:33] * zyga-ubuntu reboo/ [08:34] mvo: less files around would be nicer [08:34] Would it be possible to make a classic snap that exposes an arbitrary filesystem path to a contained snap via the content interface ? [08:35] mvo: then we would renames all files to r#.ext as we discussed already [08:36] abeato: what do you need to know about flash-kernel? [08:36] stub, ICBW but i think classic turns off all interface capabilities [08:36] abeato: it's an ad hoc way to install kernels on random ARM and other boards [08:36] e.g. in flash, on this or that partition, in this or that format etc. [08:37] pedronis: aha, excellent plan - so errtracker+simplified logs. I will do that [08:37] oh, I thought that sort of thing was starting to be allowed to make it easier to transition from classic -> contained. [08:38] that would be quite a security hole [08:38] lool, yeah, I was wondering what did it support. uboot only? would it support creating and flashing an android boot partition? [08:41] abeato: it does support flashing an android style image [08:41] abeato: see https://anonscm.debian.org/cgit/d-i/flash-kernel.git/tree/functions search for abootimg [08:42] abeato: this is how the db entries look like https://anonscm.debian.org/cgit/d-i/flash-kernel.git/tree/db/all.db [08:42] abeato: search for android in there too [08:42] lool, hmm, so to have a new device supported, it would need to be added to that DB [08:45] abeato: Yes; I think you can override it localy, but the easiest is to edit a .db file to your looking until it works [08:45] *locally [08:46] lool, got it, thanks [08:46] abeato: note that Ubuntu's and Debian's flash-kernel often have a large delta, but the general concepts and architecture should be the same [08:47] lool, ok, noted [09:11] pedronis: 2.28 has one blocker right now, we need to sort some armhf/arm64 syscall in the seccomp tests, I will dig into that later, right now arm builds are broken :/ [09:17] mvo: oops, ok [09:17] i guess zyga's reboot didn't go so well [09:17] yeah, but no worries, I will look into it soon [09:28] re [09:28] * zyga sent kids to the cinema and resumes work [09:29] mwhudson: sorry for being off, if you are still around just tell me if I shall dput now [09:49] zyga: this is splitting hairs a bit but uploaders has me@zygoon.pl but the changelog is @canonical.com [09:50] zyga: otherwise looks fine, i assume you've test built it? [09:50] mwhudson: aw, sorry, shall I amend and force pus> [09:50] zyga: pls [09:50] yes, certainly [09:50] mwhudson: doing that now [09:53] mwhudson: edited, let me rebuild ... just in case [09:54] I also fixed the local repo config so that the right email gets used in the future [10:12] PR snapcraft#1519 opened: lxd: use a unique temporary folder [10:18] * zyga sighs [10:18] artful is artfoul for me :/ === ShalokShalom_ is now known as ShalokShalom [11:06] PR snapd#3831 opened: store: move device auth endpoint uris to config [11:30] mvo: Chipaca: do you remember what's the state of this: https://forum.snapcraft.io/t/hashsum-failures-during-tests/198/4 [11:57] mvo: you need set_tls [11:57] so fedora is back to flakyness [11:58] https://travis-ci.org/snapcore/snapd/builds/270368782?utm_source=github_status&utm_medium=notification [11:58] mvo: syscall=983045. scmp_sys_resolver -a arm 983045 === rumble is now known as grumble [12:00] mvo: also, syscall=78, scmp_sys_resolver -a aarch64 78: readlinkat [12:03] mvo: so, set_tls for armhf and readlinkat for arm64 [12:03] mvo: i386 failure was unrelated to seccomp [12:04] mvo: with old snap-confine I think we may have limited the architectures we ran the testsuite on, so didn't have the full list [12:10] mvo: I'm going to try to build snapd from the ppa in a classic chroot on armhf and see if it needs more than set_tls [12:10] mvo: my dragonboard is not readily available, but if you need me to do the same there, I can [12:24] PR snapd#3832 opened: cmd/snap-seccomp/main_test.go: add syscalls for armhf and arm64 [12:25] mvo: that is for you ^ (I'm still checking armhf) [12:25] * ogra_ glares at 983045 ... i always thought syscall is an int [12:26] that's an int :) [12:26] arm has a few high numbered syscalls for historical reasons [12:27] jdstrand: aha, excellent, thank you [12:28] heh, i guess i'm to old ... somehow my brain made int a 16bit thing :) [12:28] jdstrand: yeah, our testing is now much much better with the new code, thanks a bunch for the PR [12:31] mvo: ok github.com/snapcore/snapd/cmd/snap-seccomp99.356s (armhf) [12:31] mvo: let me dig up my dragonboard [12:32] jdstrand: thanks a bunch. I'm running the tests in my pi2 currently too, but I gues I could hit ctrl-cl now :) [12:33] mvo: you can :) [12:35] jdstrand: all green, thanks a bunch [12:37] mvo: I *think* arm64 is going to be ok if I remember previous patches, but will run the tests in classic on there and update the PR. I'll ping you either way [12:39] jdstrand: if its much of a hassle we can merge/upload it and see if the arm64 build still fails [12:40] jdstrand: getting the dragnboard to work I mean [12:42] mvo: we may have to do that, give me a few minutes. lights are lit... [12:47] mvo: https://github.com/snapcore/snapd/pull/3832#issuecomment-326284730 [12:47] PR #3832: cmd/snap-seccomp/main_test.go: add syscalls for armhf and arm64 [12:48] pedronis: I don't remember the state of that [12:49] Chipaca, https://paste.ubuntu.com/25438314/ [12:49] Chipaca, i have this in a linode machine [12:50] cachio_: with shell access? [12:50] yes [12:50] cachio_: PM me the creds? [12:50] cachio_: from .spread* [12:52] RE [12:54] mvo: re, [12:54] mvo: I can now push that udev fix [12:54] mvo: and other changes [12:55] mvo: did you do the udev fix already by any chance? [12:55] mwhudson: pushed as agreed earlier [12:55] mwhudson: aha, except that !ff are rejected [12:56] mvo: https://github.com/snapcore/snapd/pull/3833 is the fix I talked about [12:56] PR #3833: interfaces/opengl: use == to compare, not = [12:57] PR snapd#3833 opened: interfaces/opengl: use == to compare, not = [13:00] Hey! [13:00] Will be a couple of mins late. Just finishing the mate [13:01] omg [13:01] mvo: I justed noticed (because zyga didn't delete it), that the link to the contributing guide in the PULL TEMPLATE ends up wrong [13:01] niemeyer: ok [13:01] jdstrand: ? [13:02] mvo: the sd card wasn't pushed in all the way :P [13:02] jdstrand: haha [13:02] jdstrand: ok [13:02] jdstrand: LOL [13:02] pedronis: meh, ok [13:02] we probably need an absolute link there [13:02] mvo: we get this atm: https://github.com/snapcore/snapd/pull/CONTRIBUTING.md [13:03] pedronis: ok [13:03] * Chipaca omw [13:03] mvo: ok, give me a few minutes. I'm in [13:04] jdstrand: great, thanks you [13:20] mwhudson: resolved [13:20] zyga-ubuntu, im gonna have some time again for my PR in the next couple of days so im tempted to withdraw and make new [13:20] so that its logically organised [13:21] haven't been on top of it as much as i woulda liked, sorry, but a ton of stuff going on atm [13:22] ikey: that's okay [13:22] ikey: consider chopping it in pieces that can land separately [13:22] between post solus 3, kernels, budgie 11, mate bits... zonked. [13:22] ikey: small diff >> chance of landing IMO [13:22] morning all [13:22] yeah thats what im thinking [13:22] ikey: thank you for doing this [13:22] the PR is a bit convoluted right now if we're honest [13:23] should be **initial** solus support, then apparmor refinement, then GPU stuff, etc [13:23] ikey: and part of the PR landed through my opensuse work [13:23] oh ok [13:23] hm yeah they'd share some common paths with us [13:23] lib64 bits [13:23] I was very generic [13:24] best way [13:24] I think it will work for you [13:24] niemeyer, did you see my post yesterday evening? [13:25] Son_Goku: we're in a call now, will be done in ~20 min [13:39] hey, I'm trying to get ubuntu core working on my raspberry pi3, but it is hanging when applying my network config (using wifi, it is stuck at 66%) [13:39] what could I do to debug/where can I log a bug? [13:40] greyback, which image (you need edge/daily) [13:40] ogra_: ah, I'm using stable. [13:40] ok, I'll switch image [13:40] yeah, dont do that on the pi's [13:41] we should not point to stable on https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 [13:42] greyback: why? [13:43] davidcalle, because the kernels are ancient [13:43] but we can not point to daily/unstable eithere [13:43] davidcalle: if it doesn't work... or at least admit there may be wifi issues [13:44] the prob is that we can not upgrade kernels on the pi ... until we have gadget upgrades in snapd [13:45] ogra_: IIRC, wifi works after first boot, right? [13:45] davidcalle, not sure if the old stable kernel even has all firmware included [13:46] (we could never test it back when that kernel was created because back then netplan was still completely broken) [13:47] (regarding the brcmfmac driver) [13:47] ogra_: ok, let's present the issue on the page then, with both links. Which image do you recommend to get wifi working? [13:48] * greyback trying edge, will let you know if it works out of the box [13:48] davidcalle, daily/edge ... one sec [13:49] davidcalle, http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ ... (or my images from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/) [13:49] mvo: about the base snaps, let me drive home and let's have the call on telegram [13:49] greyback: thanks for testing (at a coworking space today) [13:49] mvo: when would be a comfortable time for you? [13:50] davidcalle: np [13:50] zyga-ubuntu: maybe in ~30-45min? [13:50] zyga-ubuntu: or later [13:50] mvo: that sounds good to me [13:50] 45-60 min [13:50] zyga-ubuntu: sounds good [13:50] I'll be home then [13:50] on my business network :D ^_^ [13:52] * zyga-ubuntu heads home [14:01] mvo: so, I'm having a number of problems. notably: /usr/lib/go-1.6/pkg/tool/linux_arm64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory [14:03] davidcalle: ogra_: edge/daily fixes my wifi issue, all seems to be working well now, thanks! [14:03] mvo: but also, the core snap is stuck on r1432. it keeps wanting to reboot, so I do, then it says it needs to reboot. r2781 is present, but I guess it fails to boot, goes back into r1432 and then loops [14:03] jdstrand: does setting GOMAXPROCS=1 help the memory issue? [14:04] * jdstrand tries [14:05] jdstrand: what board is this, btw? [14:05] Chipaca: dragonboard [14:05] jdstrand: that had a reasonable amount of memory. strange. [14:06] Son_Goku: Thanks for the post! [14:06] Chipaca: looks like 8G [14:06] :-( [14:06] oh no [14:06] it is 800M [14:07] that seems weird [14:07] Chipaca: that did not help [14:07] jdstrand: snap version would be nice to kow what is goind on, i.e. why you can't refresh [14:07] jdstrand: 800mb seems a bit on the low side indeed [14:07] $ snap version [14:07] snap 2.23~201703020745.git.0f2bdc1~ubuntu16.04.1 [14:07] snapd 2.23~201703020745.git.0f2bdc1~ubuntu16.04.1 [14:07] series 16 [14:07] kernel 4.4.0-1049-snapdragon [14:08] * jdstrand hadn't booted this in a while === JanC_ is now known as JanC [14:10] https://developer.qualcomm.com/hardware/dragonboard-410c says it has 1G of memory. so I guess the kernel is taking up the first 200M [14:12] jdstrand: any swap? is /tmp a tmpfs? [14:12] Chipaca: no swap [14:12] niemeyer, I think I covered everything okay [14:12] Son_Goku: niemeyer: is the idea to then have a "amd64 can install amd64, i686, ..., i385" thing? [14:13] that'd be awesome [14:13] Chipaca, that's one hope, yes [14:13] in rpm, we have an arch compatibility table that allows for that semi-automagically [14:14] once the architecture name scheme is fixed up, we can rather easily port that table into snapd and allow that [14:15] so like, for example, x86_64 can install x86_64/amd64, i686, i586, ..., i386 and so on [14:16] and armv7hl can install armv7hl, armv6hl, but not armv6hnl or armv7hnl [14:17] yeah that sort of thing [14:17] i'm sold already :-) [14:17] it's going to be a bunch of work though [14:17] yeah [14:17] at least [14:17] on intel, ia64 and ia32 use different syscalls [14:17] yeah [14:17] so seccomp is munged up [14:17] i dunno arm [14:17] but i expect surprises [14:18] still, we've got the former covered already (because you can ship ia32 binaries in ia64 snaps) [14:18] speaking of which, it's somewhat sad how often I get asked if people can run amd64 stuff on their 64-bit x86 machine [14:18] kyrofa: hey, do you know if anything is missing from my side for the snapcraft pr#1420? [14:18] Son_Goku: "no, sorry, itanium only" [14:18] ogra_: greyback: thanks for the heads up/testing, adding edge to the page with some explanations. Is it the case for Pi2 and Pi3 or just Pi3? [14:18] which is partly why I use "x86_64" as the name, as it's pretty damn generic [14:19] people seem to get that it's Intel or AMD with that name [14:20] davidcalle, no wlan on pi2 ;) [14:21] ogra_: so it doesn't work? :p [14:21] Son_Goku, but totally historically incorrect :) [14:21] davidcalle, there is no wlan hardware :) [14:21] Chipaca: 'so seccomp is muged up' -- what exactly are you talking about? [14:21] munged* [14:21] ogra_, yeah, yeah [14:21] I know AMD invented it [14:22] So I have a working image with a signed kernel; I'm trying to test a new kernel without reflashing the device entirely; I get: - Mount snap "joule-linux" (unset) (cannot replace signed kernel snap with an unasserted one) [14:22] I guess there's no way to bypass this? [14:22] jdstrand: i mean: seccomp rules for ia32 and ia64 are separate (right?) [14:22] Son_Goku, well, alpha did ... AMD just poiorted it to x86 compatibility [14:22] *ported [14:22] well yes [14:23] lool: why not push the new kernel up, so it gets signed? [14:23] but Linux, the compiler, and several other things call it x86_64 [14:23] which just makes the 'amd64' name more confusing === JoshStrobl|AFK is now known as JoshStrobl [14:23] Chipaca: cause I dont have the permissions to do so, it's a canonical signed kernel and I'm not in the right teams [14:23] Son_Goku, and while i dont really care about the arches i use as a developer ... you have to take familiarity into accoount as well ... users of debian based distros know the other namings ... [14:24] ogra_: IMO, just support both names as aliases to each other [14:24] i wonder if it would make sense to have a "visible layer" that can be distro specific [14:24] this is me testing a kernel change/rebuild, but a partner has the same issue: they need to test a new kernel and they are not Canonical and not in a position to publish a test kernel [14:24] so endusers see their distro naming ... [14:24] yeah [14:25] if the distro name is known, use that, otherwise fallback to generic name ('x86_64', 'armv7hl', etc.) [14:25] Chipaca: what do you mean by ia32 and ia64? do you mean i386 and amd64 in Ubuntu speak? [14:25] x86_32 and x86_64, jdstrand [14:25] so, yes [14:26] i686 and x86_64 / i386 and amd64 [14:26] jdstrand: we were talking about amd64 vs i[3456]86 [14:26] ok [14:26] so i used ia32 for the latter [14:26] so, there is a syscall table for each architecture [14:26] ia64 unfortunately is Itanium [14:26] ouch :-) [14:26] sorry then [14:26] the names of the syscalls are usually the same,but some architectures have different names [14:27] for amd64, it also supports compat syscalls for i386 [14:27] lool: I'm not sure (maye noise][ can add info here), but do you need to be canonical to push kernels at all? I'd imagine you'd trigger a manual review, but other than that it should work? [14:27] lool: i mean, you can't push a canonical kernel, but you can push a lool kernel surely? [14:27] so while the names are the same (eg, 'read'), the syscall number in the kernel is different [14:27] $ scmp_sys_resolver -a x86_64 open [14:27] 2 [14:28] $ scmp_sys_resolver -a x86 open [14:28] 5 [14:28] Son_Goku, also your argument about raspbians armhf is a bit moot given they break the standard with that to (falsely) have users be able to use the normal debian rachive alongside [14:28] Chipaca: so, technically, 'yes' things are different, but how we write our policy, it doesn't matter [14:28] armhf is always 'armv7hl' ... [14:28] ogra_, the 'why' is beside the point [14:28] that has been pretty much standardized when we started it [14:29] Chipaca: we write our policy, we include all the relevant syscalls for the architectures [14:29] the point I was trying to illustrate is that base arch names are too coarse [14:29] Chipaca: eg, all the policy has 'open', but it has *both* getfid and getgid32 [14:29] and can be arbitrary or redefined [14:29] err, getgid and getgid32 [14:29] you cant really punish everyone just because an outsider distro decided to break it [14:29] (against better advise actually) [14:29] ogra_: can it really be considered an outsider distro any more than Ubuntu is to Debian? [14:30] also, that's a shitty argument to make to begin with [14:30] jdstrand: right, and that's the kind of fiddly thing i'd imagine we'd have to loop around to support running two slightly different flavour of arm binaries in the same snappy system [14:30] Chipaca: if a syscall that we specify doesn't exist on an arch, we ignore it. so set_tls only exists on arm, but it is in the default template, so on amd64 set_tls is ignred [14:30] ogra_, and this is not even really punishing anyone [14:30] measured by userbase and amount of derivatives ? ... yeah [14:30] as it is today, even Fedora's ecosystem can't properly handle this [14:30] jdstrand: ah, i didn't realise we shipped everything everywhere, that might make it easier [14:30] because we do have derivatives that do this [14:30] Chipaca: so... adding other architectures is easy-- if there are other syscalls (there wouldn't be terribly many-- most syscall names are shared), we just add them to the appropriate interface [14:31] Son_Goku, that is why we tired to form a standard back then ... [14:31] yup [14:31] across distros actually [14:31] jdstrand: i get that it wouldn't be a lot of work, but i see it as fiddly work (that i'd be terrible at) [14:31] well, I was around during the arm bootstraps for these, and I don't recall such a thing happening [14:31] Chipaca: so to bring on itanium, if execve was execve_itanium, then we just add execve_itanium to the default template [14:31] the rpm guys reached out to arm to actually figure out how to do it [14:31] and we followed their advice [14:31] somewhere in there https://lists.linaro.org/pipermail/cross-distro/ [14:32] Chipaca: sure. that is something I could help with [14:32] anyway, g2g to work [14:32] bbs as Pharaoh_Atem [14:32] it isn't as fiddly as you might think [14:32] jdstrand: i stopped listening after you promised to do the work yourself [14:32] =D [14:32] because I have the entire list of syscalls for all architectures that Ubuntu builds in ./cmd/snap-confine/README.syscalls [14:33] jdstrand: aha, but that's the thing, we're talking about arch flavours we _don't_ currently build in [14:33] and there are only a few arch-specific syscalls [14:33] but yeah, i get that there wouldn't be a lot of variation [14:33] Chipaca: I understand. there is nothing saying we can't add to that [14:33]