=== JoshStrobl is now known as JoshStrobl|zzz [06:11] mvo: hey! [06:12] hey morphis [06:13] morphis: so… anbox still failing? [06:13] mvo: I am sorry, didn't had much time yesterday evening to debug the seccomp issue further [06:13] mvo: jepp, still get seccomp denials [06:13] https://paste.ubuntu.com/25381201/ [06:13] mvo: did a reboot this morning [06:13] DEBUG: raising privileges to load seccomp profile [06:14] morphis: this DEBUG: read 48 bytes from /var/lib/snapd/seccomp/bpf//snap.anbox.container-manager.bin looks right, 48byte is the allow profile [06:14] sounds like somethign which shouldn't happen for a devmode snap, or I am wwrong with that assumption? [06:14] ah [06:14] morphis: it should not happen, we need to figure out why it is happening now :) [06:14] morphis: can you pastebin the dmesg denials again please? [06:14] sure [06:15] https://paste.ubuntu.com/25381213/ [06:15] a few [06:15] morphis: and those are the result of "sudo SNAP_CONFINE_DEBUG=1 snap run anbox.container-manager " and this command gets killed right away? [06:15] nope, anbox.container-manager doesn't get killed [06:16] that is the tricky thing here [06:16] anbox.container-manager uses LXC to start a container [06:16] morphis: aha, I think I get it - the arch=40000003 is the problem :/ [06:16] and processes inside that container are getting killed [06:16] mvo: why that? [06:16] morphis: what arch is that? someting android special? or is there some usermode cpu emulation or something going on? [06:16] no cpu emulation, let me check [06:17] morphis: when you do a "seccomp.NewFilter(default=Allow)" this will still filter on architecture :( [06:17] morphis: and this arch is none not amd64 nor i386 [06:18] morphis: hm, or maybe it is just in a different notation, let me dig into it [06:19] it should be either amd64 or i386 [06:19] mvo: https://paste.ubuntu.com/25381228/ [06:19] morphis: aha! thanks, so *maybe* multi-arch releated [06:19] mvo: yeah that makes sense [06:20] but everything inside the Android container should be either 64 or 32 bit x86 [06:20] there is no ARM stuff [06:20] mvo: the new filtering came in with 2.27? [06:20] morphis: and indeed, the arch is 386 [06:21] morphis: correct [06:21] ok, then smells like we're not filtering correct [06:21] morphis: actually it came in with 2.26.x :/ [06:21] hm [06:22] did we release a 2.26 deb package? [06:22] morphis: yes, it was availabe in -proposed [06:22] morphis: it should still be in -updates, so you should be able to downgrrade [06:22] if I am not wrong I was using 2.26 here either through re-exec or via the deb package [06:23] mvo: do you need anymore debugging from my side on this? [06:23] morphis: maybe, let me try to reproduce again with your steps [06:23] mvo: then let me keep this for a moment [06:27] morphis: ok, this is all very strange - I snap install anbox, run the same command as you in the pastebin, get exactly the same .bin file, get exactly the same debug output but no errors, the thing just runs. can you pastebin the output of "snap version" please? [06:28] https://paste.ubuntu.com/25381266/ [06:28] mvo: ah, you need to do a bit more to trigger the errors [06:28] $ sudo systemctl stop snap.anbox.container-manager.service [06:28] sudo SNAP_CONFINE_DEBUG=1 snap run anbox.container-manager [06:29] $ ANBOX_LOG_LEVEL=debug anbox session-manager [06:29] the last one will trigger the boot of the container and then you should see the denials [06:30] morphis: I get "failed to start as either binder or ashmem kernel drivers are not loaded", I guess I need to do an insmod somehere? [06:30] morphis: this is using lxc, right? I wonder if it is related to that, iirc it also has some seccomp bits [06:31] morphis: but first, let me try to reproduce :) any suggestion for the binder/ashmem? [06:31] mvo: ah right, you need https://launchpad.net/~morphis/+archive/ubuntu/anbox-support [06:31] then apt install anbox-modules-dkms [06:31] that will build and load the binder/ashmem kernel drivers [06:32] mvo: or if you take the right way: $ snap install --classic anbox-installer && anbox-installer [06:32] that will do these things for you [06:33] morphis: hrm, hrm, I modprobe binder_linux, its showing up in lsmod but I get the same error message :( [06:33] modprobe ashmem_linux [06:33] you need both [06:33] ta [06:34] morphis: *cough* still no denial :( [06:34] morphis: [Renderer.cpp:248@initialize] successfully initialized EGL [06:34] hm, stop the session-manager and start it with $ anbox session-manager --single-window [06:35] that should give you a Android screen after a while [06:35] mvo: which kernel are you on? [06:35] I am running the 4.10 HWE kernel here [06:36] morphis: the zesty default kernel 4.10.0-32-generic [06:36] ok [06:36] so same as me [06:36] morphis: single-window does it for me, loads of syscall denials [06:36] good! [06:37] morphis: thank you, I dig a bit [06:37] np, thanks for getting into this :-) [06:43] morphis: just to confirm, no issues with 2.26.14 [06:43] mvo: let me revert back to that and verify [06:44] morphis: its fine,I think I can take it from here [06:44] morphis: again, thanks a lot for reporting this! [06:45] mvo: jepp, verified now, 2.26.14 is working fine [06:45] mvo: np [06:56] morphis: I think I have a fix, its indeed a multi-arch related regression, building an update now [06:56] mvo: nice! [07:14] PR snapd#3795 opened: Polkit interactive flag [07:16] mvo: ^^ the above is a fairly simple improvement to my polkit-support branch you merged yesterday: let the client decide whether to allow interaction [07:22] jamesh: thanks, checking [07:24] good morning peeps [07:24] electrician is here and my power will be going off by about 20 minutes at some point soon [07:34] good morning [07:35] * zyga-suse waits forever until PRs show up :/ [07:43] zyga-suse: just fyi, 2.27.4 just got uploaded, morphis helped me to track down the seccomp regression, it was a missing cherry pick related to multi-arch. I think we don't have a spread test for this case yet, I will add one [07:43] mvo: understood, thank you, I wil help with updated packages [07:43] mvo: I remember that fix but didn't you make it for 2.26.x? [07:43] mvo: was it just not merged back to 2.27 after the release? [07:44] (after the 2.26.x release was merged back to master) [07:44] zyga-suse: yeah, that was exactly the problem [07:44] mvo: as a sanity check, can you look at merging release/2.26 into release/2.27 please? [07:45] and we could use this as a standard process [07:45] to ensure that no point release fixes are missing in new release [07:45] * zyga-suse rolls up his packaging sleeves [07:45] and throws a coin to see if the tarball layout is the same ;-) [07:50] morphis: if you happen to be editing snapd-user-instance again sometime, could you s/'%s'/%q/? [07:51] Chipaca: I left comments for that [07:51] Chipaca: I am trying to get to that point, will include that [07:51] morphis: i was going to comment on the PR but couldn't find a way to properly say "don't do this unless you happen to be here" and have you believe me [07:53] zyga-suse: ah! you did? missed it [07:53] Chipaca: perhaps a new instance of that was added [07:53] zyga-suse: yeah, not seeing your comment :-) [07:58] zyga-suse: *pff* - yeah, I did a sanity check and things look good, some delta mostly because we did some things slightly differently in 2.26 and fixed that in 2.27 === __chip__ is now known as Chipaca [08:03] * zyga-suse_ is fed up with shitty network [08:07] zyga-suse_: welcome to my world :) [08:08] mcphail: where do you connect from? [08:09] zyga-suse_: I work away from home in the north of scotland. I'm often on 2G mobile connections, but even broadband in the "city" of Inverness is painfully slow [08:09] PR snapd#3796 opened: release: new 2.27.4 release [08:10] I'm technically on LTE but I ran over (ahem, kids did) my data plan so I get to see why they show number of bits per second :/ [08:10] heh. buy another sim for the rest of the month? [08:11] if you need a decent connection, it has to be worth the money [08:12] Claim it back from canonical as a work expense :) [08:12] mcphail: it's not easy, only one network is here, I'm in the woods with no car (no way to go out until my wife comes back for weekend) and normal data plans strongly favor contract over pre-paid (one month) thing (from this telco only, others are better but don't have any coverage here) [08:12] it's just for this week, normally I have two mobile connections that work OK [08:12] (in the capital) [08:12] aah well. Enjoy the solitude :) [08:13] zyga-suse_: https://chris.bolin.co/offline/ [08:14] PR snapd#3796 closed: release: new 2.27.4 release [08:16] PR snapd#3797 opened: daemon: allow polkit authorisation to install/remove snaps [08:17] why did you close the PR? [08:18] mvo: ^^ and here's the other branch. This one would definitely need niemeyer's signoff based on previous conversations [08:20] PR snapd#3788 closed: cmd/snap-repair: ignore superseded revisions like the rest of the assertion infra [08:20] PR snapd#3798 opened: release: 2.27.4 [08:23] ooh, nice, bug [08:25] jamesh: thank you [08:25] Chipaca: what bug? [08:25] mvo: snap's completion of service names does not filter [08:27] hello [08:28] there was some confusion with my small PRs, I need a quick review of snapd#3787 , which now is just adding some test cases [08:28] PR snapd#3787: cmd/snap-repair: more test coverage of filtering [08:44] * zyga-suse_ looks === zyga-suse_ is now known as zyga-suse [08:58] 2017-08-24 09:58:00 Cannot allocate linode:ubuntu-16.04-32: cannot create Linode disk with ubuntu-16.04-32: you do not have enough unallocated storage to create this Disk (872 requested, but only 0 available) [08:58] :-( [08:59] we require more megabytes [08:59] (spoken with starcraft zerg voice) [08:59] * zyga-suse waits _eternity_ for package downloads :/ [08:59] ah, finally cached! [09:09] PR core#54 opened: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher [09:13] oh so i should upload 2.27.4 to debian ? [09:14] mwhudson: yes, unless we disabled seccomp in debian [09:14] oh i think we did [09:14] but I think uploading it is ok in general since pepole will feel it is in sync [09:14] ifeq ($(shell dpkg-vendor --query Vendor),Debian) [09:14] VENDOR_ARGS=--disable-apparmor --disable-seccomp --enable-static-libcap [09:15] someone said something about taking that out but apparently i didn't... [09:15] I think we might enable seccomp on debian nowadays [09:15] mvo: did you actually tag 2.27.4? [09:15] and not do static libcap (we don't need to) [09:16] mwhudson: there is a tag, is there not? [09:16] * zyga-suse uploads new suse build [09:16] mvo: ah yes, got confused about which remote was which in this repo :) [09:17] :) [09:18] zyga-suse: i can make those changes, how do i tell if they've broken something? [09:18] mvo, hmm ... did you explisictly pick beta when building core ? (edge stil has the old builds) [09:18] mwhudson: run snaps [09:18] zyga-suse: ok :) [09:18] ogra_: sort of, I changed edge back right after pushing to beta [09:18] ah, fine then [09:18] ogra_: so that it refelects master [09:18] yep [09:19] mwhudson: there's a PR that has several most downloaded/important snaps [09:19] mwhudson: just trying a few I think (or one of each class) is sufficiently good as smoke test IMO [09:25] suse is now up-to-date [09:25] man, this is too easy [09:25] * zyga-suse looks at arch [09:44] mvo: snapd#3798 seems to have broken cmd/snap-repair tests on it, not sure how/why [09:44] PR snapd#3798: release: 2.27.4 [09:45] pedronis: how stange, let me lok [09:45] look [09:46] debian@debian:~$ hello.universe [09:46] /usr/lib/snapd/snap-confine: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory [09:46] how did i do that [09:46] mwhudson: uh, is that apparmor denials for libcap.so.2 ? [09:46] oh yes [09:47] * mwhudson puts that bit back [09:47] Chipaca: it's cannot allocate disks land? [09:48] yuh [09:48] :/ [09:50] * zyga-suse needs a faster HDD [09:51] mwhudson: you confined snap-confine [09:51] mwhudson: take this patch: [09:51] i did [09:51] https://github.com/snapcore/snapd/pull/3791/files [09:51] PR snapd#3791: cmd/snap-confine: allow using additional libraries required by openSUSE [09:51] mwhudson: also look at master, cherry pick one more patch before this one affecting the same file [09:51] mwhudson: this should fix it for you [09:52] travis/spread is unhappy today [09:52] my hdd is unhappy [09:52] my 300GB old HDD is unhappy to be precse [09:52] mvo: https://github.com/snapcore/go-gettext/pull/1 [09:52] PR go-gettext#1: update import path to new location [09:52] :) [09:54] zyga-suse: did you see https://github.com/snapcore/snapd/pull/3760 [09:54] PR snapd#3760: Allow snap-confine to be confined even with --disable-apparmor [09:54] I probably did, let me review it [09:54] mmm tests failed i wonder why [09:55] mwhudson: I sent a RFC PR and got detailed feedback from jdstrand yesterday [09:55] mwhudson: we have infrastructure problems atm , all tests are failing [09:55] pedronis: these tests ran a few days ago [09:55] as in https://github.com/snapcore/snapd/pull/3792 [09:55] PR snapd#3792: cmd/snap-confine: allow running snap-exec without confinement [09:55] ah ok [09:56] mwhudson: I think we want to solve the same problem [09:56] mwhudson: check out what jamie wrote about it [09:57] zyga-suse: ah yes [09:57] zyga-suse: i thought there was another way of doing this, which was to generate a super loose apparmor policy when in forced devmode state [09:58] rather than generating no policy at all [09:58] zyga-suse: but do what jamie says, i guess :) [10:05] * zyga-suse -> coffee [10:05] I'll wait 20 minutes for various pulls/pushes/builds anyway [10:05] sigh [10:10] PR snapcraft#1505 opened: errors: introduce ContainerError [10:24] mvo: I marked this upcomign for you: https://forum.snapcraft.io/t/snapd-not-restarting-on-revert/1679 I think you merged a fix [10:27] pedronis: thank you [10:29] mvo: I made a small tweak/fix to tests related to LANG [10:29] mvo: https://github.com/snapcore/snapd/pull/3799 [10:29] PR snapd#3799: snap/squashfs: use LANG=C.UTF-8 [10:29] mvo: I suspect we may need a few more as new translations show up [10:29] PR snapd#3799 opened: snap/squashfs: use LANG=C.UTF-8 [10:29] mvo: this lets me go test without fiddling with language [10:34] ok [10:37] zyga-suse: can you pastebin the failure you are seeing (that lead to this change) ? [10:37] sure [10:39] mvo: https://paste.gnome.org/pjmwzmgo2 [10:40] zyga-suse: ta [10:40] mvo: are you running your system with english or german locale? [10:42] zyga-suse: does http://paste.ubuntu.com/25382296/ help? [10:42] zyga-suse: I use en [10:42] mvo: that explains it, looking [10:42] setenv is evil [10:43] I wonder how golang can have a broken function like that [10:43] I honestly prefer my approach as it limits the env change to the started process [10:43] and not to golang process [10:44] zyga-suse: I will reply in the pR [10:47] mvo: I replied [10:48] mvo: looking at it from i18n angle [10:49] mvo: what would be the right solution if both the invoked program and the snapd code itself was localized [10:49] mvo: the test would have to have synchronized localization [10:52] zyga-suse: the paste was not the final solution, just checking that this is enough to fix the issue. I still think from a i18n pov its preferable that the child runs with the native locale, it might have to tell the user something [10:52] yes, that I agree with [10:52] zyga-suse: anyway, this is slightly crufty code (pretty old) I have a look if there is a way to remove some of this oddness [10:52] we could just patch the test for now [10:53] zyga-suse: yeah [10:53] .* vs the english error [10:53] zyga-suse: I think runCommand is really not needed with testutil.MockCommand() etc [10:53] aha, good point too [10:53] zyga-suse: I have a look, but feel free to do the change you suggested [10:54] ok [10:54] I'll check in a moment, just wrapping up arch builds [10:54] zyga-suse: no worries and no rush [10:58] zyga-suse: *cough* I think the problem goes away entirely [10:58] zyga-suse: hm, maybe, maybe not, looking harder [10:58] hmm? [10:58] can you explain [10:58] zyga-suse: just wait for my PR, its kind of funny [11:00] PR snapd#3800 opened: squashfs: remove runCommand/runCommandWithOutput as we do not need it [11:00] zyga-suse: -^ [11:01] zyga-suse: thanks again for finding this! I get some lunch now, let me know your thoughts [11:01] enojy [11:04] zyga-suse: you mentioned the problem is not solved, afaict the error happens in testcode that I removed, so what is left to do? [11:05] mvo: I mean we removed the test so the problem is not going to show up [11:05] but we need to figure out how to test i18n eventually [11:05] that's what I wanted to convey [11:10] * zyga-suse has is usual food poisoning woes after moving to a new location [11:10] how I hate my body in days like this === ShalokShalom_ is now known as ShalokShalom [11:17] PR snapcraft#1503 closed: ci: speedup the CLA check [11:27] what's wrong with travis today? [11:28] no spread run can get disks afaict [11:30] good day to feel sick and work locally then [11:30] * zyga-suse notices that British pound is awfully cheap lately [11:35] PR snapcraft#1504 closed: project loader: refactor into package [11:44] ppisati, is the 3.10 branch of the sample-kernel tree up to date ? (i need to port to a board that only has 3.10 sources) [11:48] ogra_: it's in line xenial, so yeah, go ahead [11:48] *on par [11:55] zyga-suse: right, well, the test and the offending code is gone, but yes, at some point we will need to look at i18n in tests [11:56] * zyga-suse nods [11:56] ppisati, thanks ! [11:56] popey: hey [11:56] popey: isn't martin an arch TU? [11:56] can we ask him for help? [11:57] PR snapd#3799 closed: snap/squashfs: use LANG=C.UTF-8 [12:15] jdstrand: what am I doing wrong here: https://paste.gnome.org/pwb7cargz [12:17] jdstrand: note that I added just this [12:17] +#include [12:30] jdstrand: ah, I see now [12:41] niemeyer: would you agree that people in other teams working on snapd would benefit from joining the standup if they're struggling with process? [12:42] e.g. if they're bashing their heads on the wall of OMG 50+ PRs [12:42] I *am* bashing my head against 50+ PRs [12:43] pedronis: you should join the standup! [12:43] zyga-suse: when including a directory the directory must exist [12:43] wait [12:43] right, it did exist, the problem was " " vs < > [12:43] zyga-suse: so the packaging is going to need to create it [12:43] oh right, I think I told you wrong wrt " vs <> [12:43] Chipaca: it might help or not, 50+ PRs is a bit bad anyway [12:43] (sorry) [12:44] Chipaca: for anybody [12:44] taking gustavo's advice about email we should close them all [12:44] i tried that [12:44] people got upset [12:44] jdstrand: no worries, I found the jump to apparmor docs interesting [12:45] well I think we are close to a point in which we should just stop adding them until they are below one page [12:47] pedronis: +1.33 [12:48] and i say that as somebody with a branch ready to be a pr [12:48] PR snapd#3372 closed: tests: add basic lxd test [12:49] struct { PRs [50]PR } snapd; [12:49] or something [12:49] Chipaca: anyway even just, you, zyga, me and mvo, if each of us has 10 open PRs, it makes 40 [12:50] back when poland was under soviet rule we had "stamps" for food and other basic things [12:51] we could bring "PR stamps" [12:51] you get 3 a week [12:51] and you have to make it [12:51] * zyga-suse cannot wait to see the economy of stamp trading [12:53] zyga-suse: but then we'd have a solidarnosc team handing out counterfeit stamps [12:53] it might also end with the round table talks and free elections ;) [12:54] will we have to hand over snapcore to walesa ? [12:54] zyga-suse: the longer-term economic impact of your suggestion dissuades me [12:54] zyga-suse: he used to be one, but gave it up when he moved to work on ubuntu [12:54] popey: not according to the TU page [12:54] yeah, he still has limited access in places [12:54] are you suggesting that if an individual has more than N open PRs, stop proposing PRs and start reviewing? [12:54] Chipaca: ^ [12:54] flexiondotorg: ^ [12:55] jdstrand: something something, sadly some PRs have more complicated constraints [12:55] yes [12:55] I was going to mention that [12:55] also it's clear that the forum has eaten into reviewing time [12:55] it is a hard problem [12:55] yes [12:55] forum is more fun than reviews [12:55] oh gosh, the forum has eaten into all time [12:55] that's a problem [12:55] we should nationalise the trains [12:55] well, fun [12:55] heh [12:56] everything leads on from there [12:56] I mean, we are told to be responsive to the forum (with good reason) [12:56] yes [12:56] and releases [12:56] I used to be an Arch TU. [12:56] I stood down about 8 months ago. [12:56] Looks like that page didn't get updated. [12:56] So I have considered re-applying, just to maintain snapd etc. [12:56] yes, just saying that PR creation seems to be one of the few things we can control [12:57] that's technically true, but it won't fly when people say 'the forum has too much traffic, so people couldn't do reviews, so I stopped proposing PRs" [12:57] flexiondotorg: I could work with you, I can prepare each release technically [12:57] it's a difficult problem [12:58] jdstrand: i'm saying _we_ should stop pushing PRs until the queue is under control [12:58] flexiondotorg: I just need to have someone sponsor it (in arch-specific way) [12:58] Chipaca: "you should stop eating until we have more food" [12:58] ish [12:58] I agree but it's not a simple solution [12:58] Chipaca: as a temporary action, sure [12:58] that makes a ton of sense [12:59] I was thinking bigger picture [12:59] we're going to have to have something in place permanently, as clearly we aren't self-governing without _something_ [12:59]