[06:11] <morphis> mvo: hey!
[06:12] <mvo> hey morphis
[06:13] <mvo> morphis: so… anbox still failing?
[06:13] <morphis> mvo: I am sorry, didn't had much time yesterday evening to debug the seccomp issue further
[06:13] <morphis> mvo: jepp, still get seccomp denials
[06:13] <morphis> https://paste.ubuntu.com/25381201/
[06:13] <morphis> mvo: did a reboot this morning
[06:13] <morphis> DEBUG: raising privileges to load seccomp profile
[06:14] <mvo> 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] <morphis> sounds like somethign which shouldn't happen for a devmode snap, or I am wwrong with that assumption?
[06:14] <morphis> ah
[06:14] <mvo> morphis: it should not happen, we need to figure out why it is happening now :)
[06:14] <mvo> morphis: can you pastebin the dmesg denials again please?
[06:14] <morphis> sure
[06:15] <morphis> https://paste.ubuntu.com/25381213/
[06:15] <morphis> a few
[06:15] <mvo> 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] <morphis> nope, anbox.container-manager doesn't get killed
[06:16] <morphis> that is the tricky thing here
[06:16] <morphis> anbox.container-manager uses LXC to start a container
[06:16] <mvo> morphis: aha, I think I get it - the arch=40000003 is the problem :/
[06:16] <morphis> and processes inside that container are getting killed
[06:16] <morphis> mvo: why that?
[06:16] <mvo> morphis: what arch is that? someting android special? or is there some usermode cpu emulation or something going on?
[06:16] <morphis> no cpu emulation, let me check
[06:17] <mvo> morphis: when you do a "seccomp.NewFilter(default=Allow)" this will still filter on architecture :(
[06:17] <mvo> morphis: and this arch is none not amd64 nor i386
[06:18] <mvo> morphis: hm, or maybe it is just in a different notation, let me dig into it
[06:19] <morphis> it should be either amd64 or i386
[06:19] <morphis> mvo: https://paste.ubuntu.com/25381228/
[06:19] <mvo> morphis: aha! thanks, so *maybe* multi-arch releated
[06:19] <morphis> mvo: yeah that makes sense
[06:20] <morphis> but everything inside the Android container should be either 64 or 32 bit x86
[06:20] <morphis> there is no ARM stuff
[06:20] <morphis> mvo: the new filtering came in with 2.27?
[06:20] <mvo> morphis: and indeed, the arch is 386
[06:21] <mvo> morphis: correct
[06:21] <morphis> ok, then smells like we're not filtering correct
[06:21] <mvo> morphis: actually  it came in with 2.26.x :/
[06:21] <morphis> hm
[06:22] <morphis> did we release a 2.26 deb package?
[06:22] <mvo> morphis: yes, it was availabe in -proposed
[06:22] <mvo> morphis: it should still be in -updates, so you should be able to downgrrade
[06:22] <morphis> if I am not wrong I was using 2.26 here either through re-exec or via the deb package
[06:23] <morphis> mvo: do you need anymore debugging from my side on this?
[06:23] <mvo> morphis: maybe, let me try to reproduce again with your steps
[06:23] <morphis> mvo: then let me keep this for a moment
[06:27] <mvo> 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] <morphis> https://paste.ubuntu.com/25381266/
[06:28] <morphis> mvo: ah, you need to do a bit more to trigger the errors
[06:28] <morphis> $ sudo systemctl stop snap.anbox.container-manager.service
[06:28] <morphis> sudo SNAP_CONFINE_DEBUG=1 snap run anbox.container-manager
[06:29] <morphis> $ ANBOX_LOG_LEVEL=debug anbox session-manager
[06:29] <morphis> the last one will trigger the boot of the container and then you should see the denials
[06:30] <mvo> 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] <mvo> morphis: this is using lxc, right? I wonder if it is related to that, iirc it also has some seccomp bits
[06:31] <mvo> morphis: but first, let me try to reproduce :) any suggestion for the binder/ashmem?
[06:31] <morphis> mvo: ah right, you need https://launchpad.net/~morphis/+archive/ubuntu/anbox-support
[06:31] <morphis> then apt install anbox-modules-dkms
[06:31] <morphis> that will build and load the binder/ashmem kernel drivers
[06:32] <morphis> mvo: or if you take the right way: $ snap install --classic anbox-installer && anbox-installer
[06:32] <morphis> that will do these things for you
[06:33] <mvo> morphis: hrm, hrm, I modprobe binder_linux, its showing up in lsmod but I get the same error message :(
[06:33] <morphis> modprobe ashmem_linux
[06:33] <morphis> you need both
[06:33] <mvo> ta
[06:34] <mvo> morphis: *cough* still no denial :(
[06:34] <mvo> morphis: [Renderer.cpp:248@initialize] successfully initialized EGL
[06:34] <morphis> hm, stop the session-manager and start it with $ anbox session-manager --single-window
[06:35] <morphis> that should give you a Android screen after a while
[06:35] <morphis> mvo: which kernel are you on?
[06:35] <morphis> I am running the 4.10 HWE kernel here
[06:36] <mvo> morphis: the zesty default kernel 4.10.0-32-generic
[06:36] <morphis> ok
[06:36] <morphis> so same as me
[06:36] <mvo> morphis: single-window does it for me, loads of syscall denials
[06:36] <morphis> good!
[06:37] <mvo> morphis: thank you, I dig a bit
[06:37] <morphis> np, thanks for getting into this :-)
[06:43] <mvo> morphis: just to confirm, no issues with 2.26.14
[06:43] <morphis> mvo: let me revert back to that and verify
[06:44] <mvo> morphis: its fine,I think I can take it from here
[06:44] <mvo> morphis: again, thanks a lot for reporting this!
[06:45] <morphis> mvo: jepp, verified now, 2.26.14 is working fine
[06:45] <morphis> mvo: np
[06:56] <mvo> morphis: I think I have a fix, its indeed a multi-arch related regression, building an update now
[06:56] <morphis> mvo: nice!
[07:14] <mup> PR snapd#3795 opened: Polkit interactive flag <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3795>
[07:16] <jamesh> 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] <mvo> jamesh: thanks, checking
[07:24] <Chipaca> good morning peeps
[07:24] <Chipaca> electrician is here and my power will be going off by about 20 minutes at some point soon
[07:34] <zyga-suse> good morning
[07:35]  * zyga-suse waits forever until PRs show up :/
[07:43] <mvo> 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] <zyga-suse> mvo: understood, thank you, I wil help with updated packages
[07:43] <zyga-suse> mvo: I remember that fix but didn't you make it for 2.26.x?
[07:43] <zyga-suse> mvo: was it just not merged back to 2.27 after the release?
[07:44] <zyga-suse> (after the 2.26.x release was merged back to master)
[07:44] <mvo> zyga-suse: yeah, that was exactly the problem
[07:44] <zyga-suse> mvo: as a sanity check, can you look at merging release/2.26 into release/2.27 please?
[07:45] <zyga-suse> and we could use this as a standard process
[07:45] <zyga-suse> to ensure that no point release fixes are missing in new release
[07:45]  * zyga-suse rolls up his packaging sleeves
[07:45] <zyga-suse> and throws a coin to see if the tarball layout is the same ;-)
[07:50] <Chipaca> morphis: if you happen to be editing snapd-user-instance again sometime, could you s/'%s'/%q/?
[07:51] <zyga-suse> Chipaca: I left comments for that
[07:51] <morphis> Chipaca: I am trying to get to that point, will include that
[07:51] <Chipaca> 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] <Chipaca> zyga-suse: ah! you did? missed it
[07:53] <zyga-suse> Chipaca: perhaps a new instance of that was added
[07:53] <Chipaca> zyga-suse: yeah, not seeing your comment :-)
[07:58] <mvo> 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
[08:03]  * zyga-suse_ is fed up with shitty network
[08:07] <mcphail> zyga-suse_: welcome to my world :)
[08:08] <zyga-suse_> mcphail: where do you connect from?
[08:09] <mcphail> 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] <mup> PR snapd#3796 opened: release: new 2.27.4 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3796>
[08:10] <zyga-suse_> 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] <mcphail> heh. buy another sim for the rest of the month?
[08:11] <mcphail> if you need a decent connection, it has to be worth the money
[08:12] <mcphail> Claim it back from canonical as a work expense :)
[08:12] <zyga-suse_> 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] <zyga-suse_> it's just for this week, normally I have two mobile connections that work OK
[08:12] <zyga-suse_> (in the capital)
[08:12] <mcphail> aah well. Enjoy the solitude :)
[08:13] <mcphail> zyga-suse_: https://chris.bolin.co/offline/
[08:14] <mup> PR snapd#3796 closed: release: new 2.27.4 release <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3796>
[08:16] <mup> PR snapd#3797 opened: daemon: allow polkit authorisation to install/remove snaps <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3797>
[08:17] <zyga-suse_> why did you close the PR?
[08:18] <jamesh> mvo: ^^ and here's the other branch.  This one would definitely need niemeyer's signoff based on previous conversations
[08:20] <mup> PR snapd#3788 closed: cmd/snap-repair: ignore superseded revisions like the rest of the assertion infra <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3788>
[08:20] <mup> PR snapd#3798 opened: release: 2.27.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3798>
[08:23] <Chipaca> ooh, nice, bug
[08:25] <mvo> jamesh: thank you
[08:25] <mvo> Chipaca: what bug?
[08:25] <Chipaca> mvo: snap's completion of service names does not filter
[08:27] <pedronis> hello
[08:28] <pedronis> 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] <mup> PR snapd#3787: cmd/snap-repair: more test coverage of filtering <Created by pedronis> <https://github.com/snapcore/snapd/pull/3787>
[08:44]  * zyga-suse_ looks
[08:58] <Chipaca> 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] <Chipaca> :-(
[08:59] <zyga-suse> we require more megabytes
[08:59] <zyga-suse> (spoken with starcraft zerg voice)
[08:59]  * zyga-suse waits _eternity_ for package downloads :/
[08:59] <zyga-suse> ah, finally cached!
[09:09] <mup> PR core#54 opened: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
[09:13] <mwhudson> oh so i should upload 2.27.4 to debian ?
[09:14] <zyga-suse> mwhudson: yes, unless we disabled seccomp in debian
[09:14] <mwhudson> oh i think we did
[09:14] <zyga-suse> but I think uploading it is ok in general since pepole will feel it is in sync
[09:14] <mwhudson> ifeq ($(shell dpkg-vendor --query Vendor),Debian)
[09:14] <mwhudson>     VENDOR_ARGS=--disable-apparmor --disable-seccomp --enable-static-libcap
[09:15] <mwhudson> someone said something about taking that out but apparently i didn't...
[09:15] <zyga-suse> I think we might enable seccomp on debian nowadays
[09:15] <mwhudson> mvo: did you actually tag 2.27.4?
[09:15] <zyga-suse> and not do static libcap (we don't need to)
[09:16] <mvo> mwhudson: there is a tag, is there not?
[09:16]  * zyga-suse uploads new suse build
[09:16] <mwhudson> mvo: ah yes, got confused about which remote was which in this repo :)
[09:17] <mvo> :)
[09:18] <mwhudson> zyga-suse: i can make those changes, how do i tell if they've broken something?
[09:18] <ogra_> mvo, hmm ... did you explisictly pick beta when building core ? (edge stil has the old builds)
[09:18] <zyga-suse> mwhudson: run snaps
[09:18] <mwhudson> zyga-suse: ok :)
[09:18] <mvo> ogra_: sort of, I changed edge back right after pushing to beta
[09:18] <ogra_> ah, fine then
[09:18] <mvo> ogra_: so that it refelects master
[09:18] <ogra_> yep
[09:19] <zyga-suse> mwhudson: there's a PR that has several most downloaded/important snaps
[09:19] <zyga-suse> mwhudson: just trying a few I think (or one of each class) is sufficiently good as smoke test IMO
[09:25] <zyga-suse> suse is now up-to-date
[09:25] <zyga-suse> man, this is too easy
[09:25]  * zyga-suse looks at arch
[09:44] <pedronis> mvo: snapd#3798  seems to have broken cmd/snap-repair tests on it, not sure how/why
[09:44] <mup> PR snapd#3798: release: 2.27.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3798>
[09:45] <mvo> pedronis: how stange, let me lok
[09:45] <mvo> look
[09:46] <mwhudson> debian@debian:~$ hello.universe
[09:46] <mwhudson> /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] <mwhudson> how did i do that
[09:46] <mvo> mwhudson: uh, is that apparmor denials for libcap.so.2 ?
[09:46] <mwhudson> oh yes
[09:47]  * mwhudson puts that bit back
[09:47] <pedronis> Chipaca: it's cannot allocate disks land?
[09:48] <Chipaca> yuh
[09:48] <pedronis> :/
[09:50]  * zyga-suse needs a faster HDD
[09:51] <zyga-suse> mwhudson: you confined snap-confine
[09:51] <zyga-suse> mwhudson: take this patch:
[09:51] <mwhudson> i did
[09:51] <zyga-suse> https://github.com/snapcore/snapd/pull/3791/files
[09:51] <mup> PR snapd#3791: cmd/snap-confine: allow using additional libraries required by openSUSE <Created by zyga> <https://github.com/snapcore/snapd/pull/3791>
[09:51] <zyga-suse> mwhudson: also look at master, cherry pick one more patch before this one affecting the same file
[09:51] <zyga-suse> mwhudson: this should fix it for you
[09:52] <zyga-suse> travis/spread is unhappy today
[09:52] <zyga-suse> my hdd is unhappy
[09:52] <zyga-suse> my 300GB old HDD is unhappy to be precse
[09:52] <mwhudson> mvo: https://github.com/snapcore/go-gettext/pull/1
[09:52] <mup> PR go-gettext#1: update import path to new location <Created by mwhudson> <https://github.com/snapcore/go-gettext/pull/1>
[09:52] <mwhudson> :)
[09:54] <mwhudson> zyga-suse: did you see https://github.com/snapcore/snapd/pull/3760
[09:54] <mup> PR snapd#3760: Allow snap-confine to be confined even with --disable-apparmor <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3760>
[09:54] <zyga-suse> I probably did, let me review it
[09:54] <mwhudson> mmm tests failed i wonder why
[09:55] <zyga-suse> mwhudson: I sent a RFC PR and got detailed feedback from jdstrand yesterday
[09:55] <pedronis> mwhudson: we have infrastructure problems atm , all tests are failing
[09:55] <mwhudson> pedronis: these tests ran a few days ago
[09:55] <zyga-suse> as in https://github.com/snapcore/snapd/pull/3792
[09:55] <mup> PR snapd#3792: cmd/snap-confine: allow running snap-exec without confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/3792>
[09:55] <pedronis> ah ok
[09:56] <zyga-suse> mwhudson: I think we want to solve the same problem
[09:56] <zyga-suse> mwhudson: check out what jamie wrote about it
[09:57] <mwhudson> zyga-suse: ah yes
[09:57] <mwhudson> 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] <mwhudson> rather than generating no policy at all
[09:58] <mwhudson> zyga-suse: but do what jamie says, i guess :)
[10:05]  * zyga-suse -> coffee
[10:05] <zyga-suse> I'll wait 20 minutes for various pulls/pushes/builds anyway
[10:05] <zyga-suse> sigh
[10:10] <mup> PR snapcraft#1505 opened: errors: introduce ContainerError <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1505>
[10:24] <pedronis> 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] <mvo> pedronis: thank you
[10:29] <zyga-suse> mvo: I made a small tweak/fix to tests related to LANG
[10:29] <zyga-suse> mvo: https://github.com/snapcore/snapd/pull/3799
[10:29] <mup> PR snapd#3799: snap/squashfs: use LANG=C.UTF-8 <Created by zyga> <https://github.com/snapcore/snapd/pull/3799>
[10:29] <zyga-suse> mvo: I suspect we may need a few more as new translations show up
[10:29] <mup> PR snapd#3799 opened: snap/squashfs: use LANG=C.UTF-8 <Created by zyga> <https://github.com/snapcore/snapd/pull/3799>
[10:29] <zyga-suse> mvo: this lets me go test without fiddling with language
[10:34] <mvo> ok
[10:37] <mvo> zyga-suse: can you pastebin the failure you are seeing (that lead to this change) ?
[10:37] <zyga-suse> sure
[10:39] <zyga-suse> mvo: https://paste.gnome.org/pjmwzmgo2
[10:40] <mvo> zyga-suse: ta
[10:40] <zyga-suse> mvo: are you running your system with english or german locale?
[10:42] <mvo> zyga-suse: does http://paste.ubuntu.com/25382296/ help?
[10:42] <mvo> zyga-suse: I use en
[10:42] <zyga-suse> mvo: that explains it, looking
[10:42] <zyga-suse> setenv is evil
[10:43] <zyga-suse> I wonder how golang can have a broken function like that
[10:43] <zyga-suse> I honestly prefer my approach as it limits the env change to the started process
[10:43] <zyga-suse> and not to golang process
[10:44] <mvo> zyga-suse: I will reply in the pR
[10:47] <zyga-suse> mvo: I replied
[10:48] <zyga-suse> mvo: looking at it from i18n angle
[10:49] <zyga-suse> mvo: what would be the right solution if both the invoked program and the snapd code itself was localized
[10:49] <zyga-suse> mvo: the test would have to have synchronized localization
[10:52] <mvo> 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] <zyga-suse> yes, that I agree with
[10:52] <mvo> 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] <zyga-suse> we could just patch the test for now
[10:53] <mvo> zyga-suse: yeah
[10:53] <zyga-suse> .* vs the english error
[10:53] <mvo> zyga-suse: I think runCommand is really not needed with testutil.MockCommand() etc
[10:53] <zyga-suse> aha, good point too
[10:53] <mvo> zyga-suse: I have a look, but feel free to do the change you suggested
[10:54] <zyga-suse> ok
[10:54] <zyga-suse> I'll check in a moment, just wrapping up arch builds
[10:54] <mvo> zyga-suse: no worries and no rush
[10:58] <mvo> zyga-suse: *cough* I think the problem goes away entirely
[10:58] <mvo> zyga-suse: hm, maybe, maybe not, looking harder
[10:58] <zyga-suse> hmm?
[10:58] <zyga-suse> can you explain
[10:58] <mvo> zyga-suse: just wait for my PR, its kind of funny
[11:00] <mup> PR snapd#3800 opened: squashfs: remove runCommand/runCommandWithOutput as we do not need it <Created by mvo5> <https://github.com/snapcore/snapd/pull/3800>
[11:00] <mvo> zyga-suse: -^
[11:01] <mvo> zyga-suse: thanks again for finding this! I get some lunch now, let me know your thoughts
[11:01] <zyga-suse> enojy
[11:04] <mvo> 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] <zyga-suse> mvo: I mean we removed the test so the problem is not going to show up
[11:05] <zyga-suse> but we need to figure out how to test i18n eventually
[11:05] <zyga-suse> 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] <zyga-suse> how I hate my body in days like this
[11:17] <mup> PR snapcraft#1503 closed: ci: speedup the CLA check <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1503>
[11:27] <zyga-suse> what's wrong with travis today?
[11:28] <pedronis> no spread run can get disks afaict
[11:30] <zyga-suse> good day to feel sick and work locally then
[11:30]  * zyga-suse notices that British pound is awfully cheap lately
[11:35] <mup> PR snapcraft#1504 closed: project loader: refactor into package <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1504>
[11:44] <ogra_> 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] <ppisati> ogra_: it's in line xenial, so yeah, go ahead
[11:48] <ppisati> *on par
[11:55] <mvo> 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] <ogra_> ppisati, thanks !
[11:56] <zyga-suse> popey: hey
[11:56] <zyga-suse> popey: isn't martin an arch TU?
[11:56] <zyga-suse> can we ask him for help?
[11:57] <mup> PR snapd#3799 closed: snap/squashfs: use LANG=C.UTF-8 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3799>
[12:15] <zyga-suse> jdstrand: what am I doing wrong here: https://paste.gnome.org/pwb7cargz
[12:17] <zyga-suse> jdstrand: note that I added just this
[12:17] <zyga-suse> +#include </var/lib/snapd/apparmor/snap-confine.d>
[12:30] <zyga-suse> jdstrand: ah, I see now
[12:41] <Chipaca> 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] <Chipaca> e.g. if they're bashing their heads on the wall of OMG 50+ PRs
[12:42] <pedronis> I *am* bashing my head against 50+ PRs
[12:43] <Chipaca> pedronis: you should join the standup!
[12:43] <jdstrand> zyga-suse: when including a directory the directory must exist
[12:43] <Chipaca> wait
[12:43] <zyga-suse> right, it did exist, the problem was " " vs < >
[12:43] <jdstrand> zyga-suse: so the packaging is going to need to create it
[12:43] <jdstrand> oh right, I think I told you wrong wrt " vs <>
[12:43] <pedronis> Chipaca: it might help or not,  50+ PRs is a bit bad anyway
[12:43] <jdstrand> (sorry)
[12:44] <pedronis> Chipaca: for anybody
[12:44] <zyga-suse> taking gustavo's advice about email we should close them all
[12:44] <Chipaca> i tried that
[12:44] <Chipaca> people got upset
[12:44] <zyga-suse> jdstrand: no worries, I found the jump to apparmor docs interesting
[12:45] <pedronis> 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] <Chipaca> pedronis: +1.33
[12:48] <Chipaca> and i say that as somebody with a branch ready to be a pr
[12:48] <mup> PR snapd#3372 closed: tests: add basic lxd test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3372>
[12:49] <zyga-suse> struct { PRs [50]PR } snapd;
[12:49] <zyga-suse> or something
[12:49] <pedronis> Chipaca: anyway even just,  you, zyga, me and mvo, if each of us has 10 open PRs, it makes 40
[12:50] <zyga-suse> back when poland was under soviet rule we had "stamps" for food and other basic things
[12:51] <zyga-suse> we could bring "PR stamps"
[12:51] <zyga-suse> you get 3 a week
[12:51] <zyga-suse> and you have to make it
[12:51]  * zyga-suse cannot wait to see the economy of stamp trading
[12:53] <Chipaca> zyga-suse: but then we'd have a solidarnosc team handing out counterfeit stamps
[12:53] <zyga-suse> it might also end with the round table talks and free elections ;)
[12:54] <ogra_> will we have to hand over snapcore to walesa ?
[12:54] <Chipaca> zyga-suse: the longer-term economic impact of your suggestion dissuades me
[12:54] <popey> zyga-suse: he used to be one, but gave it up when he moved to work on ubuntu
[12:54] <zyga-suse> popey: not according to the TU page
[12:54] <popey> yeah, he still has limited access in places
[12:54] <jdstrand> are you suggesting that if an individual has more than N open PRs, stop proposing PRs and start reviewing?
[12:54] <jdstrand> Chipaca: ^
[12:54] <popey> flexiondotorg: ^
[12:55] <pedronis> jdstrand: something something, sadly some PRs have more complicated constraints
[12:55] <jdstrand> yes
[12:55] <jdstrand> I was going to mention that
[12:55] <pedronis> also it's clear that the forum has eaten into reviewing time
[12:55] <jdstrand> it is a hard problem
[12:55] <zyga-suse> yes
[12:55] <zyga-suse> forum is more fun than reviews
[12:55] <jdstrand> oh gosh, the forum has eaten into all time
[12:55] <zyga-suse> that's a problem
[12:55] <Chipaca> we should nationalise the trains
[12:55] <jdstrand> well, fun
[12:55] <zyga-suse> heh
[12:56] <Chipaca> everything leads on from there
[12:56] <jdstrand> I mean, we are told to be responsive to the forum (with good reason)
[12:56] <zyga-suse> yes
[12:56] <zyga-suse> and releases
[12:56] <flexiondotorg> I used to be an Arch TU.
[12:56] <flexiondotorg> I stood down about 8 months ago.
[12:56] <flexiondotorg> Looks like that page didn't get updated.
[12:56] <flexiondotorg> So I have considered re-applying, just to maintain snapd etc.
[12:56] <pedronis> yes, just saying that PR creation seems to be one of the few things we can control
[12:57] <jdstrand> 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] <zyga-suse> flexiondotorg: I could work with you, I can prepare each release technically
[12:57] <jdstrand> it's a difficult problem
[12:58] <Chipaca> jdstrand: i'm saying _we_ should stop pushing PRs until the queue is under control
[12:58] <zyga-suse> flexiondotorg: I just need to have someone sponsor it (in arch-specific way)
[12:58] <zyga-suse> Chipaca: "you should stop eating until we have more food"
[12:58] <zyga-suse> ish
[12:58] <zyga-suse> I agree but it's not a simple solution
[12:58] <jdstrand> Chipaca: as a temporary action, sure
[12:58] <jdstrand> that makes a ton of sense
[12:59] <jdstrand> I was thinking bigger picture
[12:59] <Chipaca> we're going to have to have something in place permanently, as clearly we aren't self-governing without _something_
[12:59] <zyga-suse> standup time
[12:59] <zyga-suse> Chipaca: vote
[12:59] <Chipaca> omw
[12:59] <jdstrand> but maybe temporary halting PRs and review queue focus isn't bad in the short term
[13:00] <jdstrand> while people think about how to do it better long term
[13:00] <zyga-suse> +1
[13:00]  * zyga-suse goes for the token
[13:00] <zyga-suse> sigh
[13:00] <zyga-suse> why does chrome always log me out
[13:02] <flexiondotorg> zyga-suse OK, I'm not sure how well an application to re-apply will go down. More so given the agenda.
[13:02] <flexiondotorg> But I can try.
[13:03] <zyga-suse> let's try
[13:03] <jdstrand> Chipaca, zyga-suse: one thing we experimented with on the security team was heuristics. you give everything a point value based on priority. different attributes add to the heuristic. for example, critical vs high vs medium vs low priority feature, customer facing bug, regular bug, contribution from community, how old the PR is, etc (whatever makes sense). then you give a score for each
[13:03] <jdstrand> Chipaca: if you end up with a PR review with a higher score than a feature's score, you do the review
[13:04] <mup> PR snapd#3456 closed: many: add interfaces.SystemKey() helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3456>
[13:04] <jdstrand> Chipaca: this isn't perfect, because you can't squeeze blood from a stone. an understaffed team will end up  with a big queue, but at least the most important items are being worked on
[13:06] <jdstrand> Chipaca: importantly, age of PR review could get extra points. eg, 0 extra of < 1 week, 10 extra if 2 weeks old, 50 if 3
[13:10] <zyga-suse> jdstrand: right, I think there are many ways to solve this, we just have to agree on something and be consistent
[13:14] <mup> PR snapd#3585 closed: many: configure store from state, reconfigure store at runtime <Created by atomatt> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3585>
[13:14] <jdstrand> if the team is severely understaffed, you end in a particularly bad state where you are only reviewing things that are old. you therefore seem unresponsive (cause you are!) and you aren't getting features done
[13:16] <Chipaca> jdstrand: yeah. I think we're not that bad, but we risk seeming so if we don't stay on top of it
[13:18] <ogra_> you could have a comment-bot that adds "we'll be processing yoour PR shortly, please hold the line" once a week
[13:18] <ogra_> :)
[13:22] <zyga-suse> there are ... 3512 days remaining
[13:23] <jdstrand> lol
[13:30] <Chipaca> zyga-suse: 𝕐𝕠𝕦𝕣 𝒷𝓇𝒶𝓃𝒸𝒽 is 𝓿𝓮𝓻𝔂 𝔦𝔪𝔭𝔬𝔯𝔱𝔞𝔫𝔱 𝗍𝗈 𝓊𝓈.
[13:31] <zyga-suse> "all the operators are busy though"
[13:32] <zyga-suse> I wonder how your message shows up in text mode programs
[13:32] <zyga-suse> how did you do it?
[13:33] <zyga-suse> I just went to amazon.com and got a "are you a robot" page
[13:33] <zyga-suse> woah
[13:33] <ogra_> and ?
[13:33] <ogra_> are you ?
[13:33] <zyga-suse> well, it's somewhat intrusive change,
[13:34] <zyga-suse> I wonder why they introduced it
[13:34] <zyga-suse> screen-scraping bots?
[13:38] <ogra_> yeah, likely
[13:39] <ogra_> though if people use screen scapers they can as well just use pixel correct click generation ... as long as the layout doesnt change and the checkbox is always in the same place at least
[13:42] <zyga-suse> it's a captcha
[13:43] <ogra_> ah, not the "I'm not aa robot" checkbox thing then
[13:44] <ogra_> (which is kind of a cut down capcha ...)
[13:45] <pedronis> niemeyer: I don't think I fully parsed how we should tag things you should review? you said "BLOCKED" that means more it cannot go in yet to me (probably because it breaks something or is incompatible with something or some new choice)
[13:46] <niemeyer> pedronis: Sorry, I used the word in a loose way instead of actually suggesting using that as a tag
[13:47] <pedronis> niemeyer: I mean I have now a couple of things that are marked blocked and some need your review, but they are blocked because we changed our minded or are not fully updated to some other change, not because they need your review
[13:47] <niemeyer> pedronis: Trying to come up with a good term for that
[13:47] <pedronis> niemeyer: ok
[13:48] <pedronis> not urgent but do let us know
[13:48] <niemeyer> pedronis: There's actually a real mechanism in GH to ask someone to review it
[13:48] <niemeyer> pedronis: I wonder if there's a filter on it
[13:48] <niemeyer> That would be the best
[13:51] <pedronis> I use it
[13:51] <pedronis> but I haven't found a filter fo rit
[13:52] <pedronis> it would be strange if there isn't though
[13:52] <pedronis> niemeyer:  https://github.com/pulls/review-requested
[13:52] <pedronis> ?
[13:53] <niemeyer> pedronis: Brilliant.. review-requested:<username>
[13:53] <niemeyer> pedronis: So we don't need to invent anything else
[13:53] <Chipaca> zyga-suse: https://github.com/chipaca/bin/blob/master/unifonter
[13:57] <pedronis> niemeyer: I think I marked the ones I'm aware of correctly
[13:58] <pedronis> niemeyer: though snap#3573 it's in a messy state atm, I need travis back to work so I can land the revert of 'generic'-signed allowing to put it into shape
[13:59] <niemeyer> pedronis: I'm cleaning it
[14:00] <niemeyer> I'm actually implementing a feature in spread to do it for me, as there are too many machines to do that by hand without it feeling absurd
[14:15] <pedronis> mvo: zyga-suse: Chipaca: that's what is marked for Gustavo:  https://github.com/snapcore/snapd/pulls/review-requested/niemeyer don't know if you have any other thing
[14:16]  * zyga-suse looks
[14:16] <zyga-suse> oh, nice
[14:17] <zyga-suse> I don't have any other things yet, after my hangout review I know what to do
[14:18] <Chipaca> pedronis: i'll tag him in one of the ones about the store work
[14:19] <pedronis> Chipaca: yes, I need to review those too but they are quite serialized
[14:20] <Chipaca> yeah, but no point him reviewing them as a series
[14:20] <Chipaca> i think
[14:20] <Chipaca> e.g. the storestate one is pretty clear, clean, and straightofrward imo
[14:20] <Chipaca> pedronis: that is snapd#3780 fwiw
[14:20] <mup> PR snapd#3780: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>
[14:20] <Chipaca> which i'm reviewing now
[14:21] <Chipaca> (so it might turn out to be terrible! :-) )
[14:21] <pedronis> probably james henstridge ones need his input?
[14:22] <Chipaca> pedronis: wasn't he already done with those?
[14:23] <pedronis> there are new ones
[14:23] <Chipaca> pesky people, making forward progress and stuff
[14:24] <pedronis> Chipaca: there's a bit of an open question in #3780  which is , it does nothing about the urls in auth.go
[14:29] <Chipaca> pedronis: well... those aren't in Config
[14:29] <Chipaca> pedronis: by which i mean: i think moving them into config would be alright, but separate from this pr
[14:30] <Chipaca> but let's see what the pr authors say
[14:30] <pedronis> Chipaca: yes, would be good to understand the plan forward though
[14:38] <sergiusens> jdstrand: how can I see that a slot is effectively setup or way it failed to do so?
[14:38] <sergiusens> this is what I get when trying to connect: "error: snap "gnome-3-24" has no slot named "gnome-3-24-platform""
[14:51] <zyga-suse> sergiusens: try new snap interface (singular)
[14:51] <zyga-suse> though we need snap connections
[14:52] <sergiusens> zyga-suse: says I don't have that command
[14:53] <zyga-suse> ah, !released :/
[14:53] <davidcalle> ikey: welcome to the frontpage of snapcraft.io
[14:53] <zyga-suse> 2.28
[14:54] <sergiusens> zyga-suse: any lower level way to verify this?
[14:54] <zyga-suse> sergiusens: try snap interfaces (plural)
[14:54] <zyga-suse> and pastebin
[14:54] <sergiusens> zyga-suse: only one entry
[14:55] <zyga-suse> only one? that's odd
[14:55] <sergiusens> this feels like https://forum.snapcraft.io/t/vanishing-plugs/1823?u=sergiusens
[14:55] <sergiusens> I'll continue there
[14:55] <zyga-suse> harry potter and the vanishing plugs
[14:55]  * ogra_ hands sergiusens a drill to make more plugs
[14:58] <mup> PR snapd#3632 closed: asserts,overlord/assertstate: auto refresh account-keys <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3632>
[15:00] <sergiusens> just posted an update zyga-suse on there, change 128 is interesting
[15:00] <zyga-suse> lookinb
[15:02] <zyga-suse> sergiusens: what's the smoking gun?
[15:02] <zyga-suse> everything looks fine there
[15:03]  * sergiusens curses at the forum at its force of quoting on text selection
[15:03] <ogra_> well
[15:03] <ogra_> 124  Error   2017-08-24T07:01:10Z  2017-08-24T07:11:54Z  Auto-refresh snap "lxd"
[15:03] <ogra_> 125  Error   2017-08-24T12:26:10Z  2017-08-24T12:36:58Z  Auto-refresh snap "lxd"
[15:03] <sergiusens> zyga-suse: 128 is "Connect gnome-twitch:gnome-3-24-platform to gnome-3-24:gnome-3-24-platform" and yet it failed
[15:03] <ogra_> that happened right beofre
[15:03] <ogra_> *before
[15:04] <zyga-suse> ah, I see
[15:04] <sergiusens> ogra_: you say the transaction breaks as it is not an isolated task?
[15:04] <sergiusens> this could explain the previous failure too
[15:04] <zyga-suse> sergiusens: can you collect the state file
[15:05] <ogra_> sergiusens, i have no idea, i just noticed that you have a bunch of erroring updates of lxd there as well
[15:05] <sergiusens> fwiw, lxd cannot update due to a profile switch error, it has been discussed on the forum
[15:05] <zyga-suse> though we don't store plugs/slots in the state
[15:05] <zyga-suse> is this in a container?
[15:05] <zyga-suse> what is snap version
[15:05] <sergiusens> zyga-suse: where do you store it? snapd things its good from a state PoV it seems, but not really
[15:05] <sergiusens> zyga-suse: no, my real system
[15:05] <zyga-suse> just in memory
[15:06] <sergiusens> 2.27.3+17.10
[15:07] <zyga-suse> interesting
[15:07] <zyga-suse> I'll think about what might cause this behavior
[15:07] <zyga-suse> just to make sure
[15:07] <zyga-suse> snap interfaces
[15:07] <zyga-suse> that shows nothing ?
[15:09] <sergiusens> zyga-suse: I added a call to that with a grep on the post
[15:09] <sergiusens> it doesn't
[15:09] <sergiusens> I bet that if I reinstall it will work
[15:09] <zyga-suse> yes
[15:09] <zyga-suse> reinstall adds/removes interfaces from a given snap
[15:09] <zyga-suse> can you just pastebin full "snap interfaces" please
[15:10] <sergiusens> zyga-suse: http://paste.ubuntu.com/25383368/
[15:11] <zyga-suse> sergiusens: can you keep the system as is
[15:11] <zyga-suse> and let me think for a moment
[15:11] <sergiusens> zyga-suse: well I reinstalled the snap, sorry
[15:11] <sergiusens> my work machine
[15:11] <zyga-suse> and the output is before or after?
[15:11] <sergiusens> I bet if you installed many snaps for use you'd run into this ;-)
[15:13] <zyga-suse> sergiusens: I had 15 before I were testing purge logic
[15:13] <sergiusens> zyga-suse: before... I like just did it 15" ago
[15:13] <zyga-suse> seyeongkim: I have 7 now
[15:13] <zyga-suse> ok
[15:13] <zyga-suse> sergiusens: ^
[15:13] <sergiusens> zyga-suse: gnome-twitch still doesn't run unfortunately "cannot change profile for the next exec call: No such file or directory"
[15:14] <sergiusens> so I still have a weird problem with interfaces ;-)
[15:14] <zyga-suse> sergiusens: that seems to say that you have no apparmor profile
[15:14] <zyga-suse> sergiusens: are you on a !ubuntu kernel?
[15:14] <zyga-suse> I'm working on something that will make that work soon
[15:15] <sergiusens> zyga-suse: yeah, non ubuntu, well ubuntu with things on top
[15:15] <zyga-suse> sergiusens: can you run ls -l in /sys/kernel/security/apparmor/features
[15:16] <ogra_> and apparmor dropped :P
[15:16] <sergiusens> http://paste.ubuntu.com/25383394/
[15:17] <ogra_> thats a short list :)
[15:17] <zyga-suse> sergiusens: right, you need more for snapd to enable apparmor
[15:17] <sergiusens> aa-status does say I have apparmor though http://paste.ubuntu.com/25383400/
[15:17] <zyga-suse> sergiusens: as a quick workaround rebuild snapd
[15:17] <zyga-suse> sergiusens: and pass --disable-apparmor to configure
[15:17] <zyga-suse> yes, but not all the features
[15:17] <ogra_> ogra@nanopi-air:~$ ls /sys/kernel/security/apparmor/features
[15:17] <ogra_> capability  caps  dbus  domain  file  mount  namespaces  network  policy  ptrace  query  rlimit  signal
[15:17] <ogra_> thats the subdirs you want
[15:17] <sergiusens> got it
[15:18] <zyga-suse> alternatively copy all of security/apparmor to your kernel and rebuild that
[15:18] <zyga-suse> jdstrand: https://github.com/zyga/snapd/commit/ef40971ea1da4110fa6474ccff634802236aebdd
[15:19]  * zyga-suse -> break / walk
[15:19]  * Chipaca -> break walkers' legs
[15:19] <jdstrand> zyga-suse: this feels like it should be coordinated with mvo's https://github.com/snapcore/snapd/pull/3456
[15:19] <mup> PR snapd#3456: many: add interfaces.SystemKey() helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3456>
[15:20] <zyga-suse> jdstrand: perhaps but for now it is a small improvement over what we have in release.go
[15:21] <zyga-suse> jdstrand: I only intend to make it "enough" to implement the permissive confinement
[15:21] <zyga-suse> jdstrand: when we pick up the system key branch again we can tie that into it easily
[15:21] <jdstrand> ok, I'm sure mvo will comment when it goes up for review. I'll look at this as is
[15:22] <zyga-suse> thank you!
[15:25] <sergiusens> zyga-suse: ogra_ ok I am back, I rebooted into an ubuntu kernel, installed, and now back and it all works
[15:26] <sergiusens> so with the profiles created with the kernel that has all the features I get a working snap on a kernel without all the features ;-)
[15:31] <zyga-suse> yes, we'll soon have a feature that will make it work on a partially supported kernel
[15:31] <zyga-suse> (with just some apparmor features around)
[15:32] <zyga-suse> it will still be devmode but at least it will not fail
[15:34] <sergiusens> zyga-suse: if I install the way I just mentioned, I don't get devmode though
[15:34] <zyga-suse> that's an interesting bug in itself
[15:34] <zyga-suse> something that jamie just spoke about is related to it
[15:34] <sergiusens> zyga-suse: and I get loaded profiles
[15:35] <zyga-suse> right
[15:35] <zyga-suse> just because the apparmor backend was not loaded at all
[15:35] <zyga-suse> my patches address that partially already
[15:35] <zyga-suse> so it will work regardless
[15:35] <zyga-suse> but not by accident
[15:39] <sergiusens> jamesh: hey, can you please take a final look at https://github.com/snapcore/snapcraft/pull/1298 ?
[15:39] <mup> PR snapcraft#1298: jhbuild plugin: new plugin <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/1298>
[15:39] <zyga-suse> jdstrand: thank you for the review, I added rlimit, I'll work on subsequent parts of this
[15:40] <mup> PR snapd#3800 closed: squashfs: remove runCommand/runCommandWithOutput as we do not need it <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3800>
[15:42] <Chipaca> mvo: dunno if you saw but snapd#3693 is properly sad
[15:42] <mup> PR snapd#3693: snapstate: improve the error message when classic confinement is not supported <Created by mvo5> <https://github.com/snapcore/snapd/pull/3693>
[15:44] <mvo> Chipaca: everything was sad the entire day, let me see if there is different sadness this time. thanks for the heads up
[15:44] <Chipaca> mvo: no, this one is on you
[15:45] <Chipaca> mvo: "classic confinement requires snaps under /snap or symlink from /snap to %!s(MISSING)"
[15:45] <mvo> Chipaca: autsch
[15:45] <mvo> Chipaca: let me fix that
[15:45] <Chipaca> IKR
[15:45] <zyga-suse> m-i-s-s-i-n-g
[15:45] <zyga-suse> I wonder why golang doesn't make that a compile time error
[15:45] <Chipaca> ruh roh
[15:45] <Chipaca> dreamhost dead?
[15:45] <zyga-suse> even C does nowadays
[15:46] <zyga-suse> what's on dreamhost?
[15:46] <Chipaca> chipaca.com :-)
[15:46] <Chipaca> well, r.chipaca.com
[15:46] <Chipaca> which is where the fun is
[15:46] <zyga-suse> aha
[15:46] <zyga-suse> dreamhost is sleeping?
[15:46]  * zyga-suse should take a break
[15:46] <Chipaca> dns seemed to have hiccuped
[15:46] <Chipaca> it's back now
[15:47] <Chipaca> zyga-suse: agreed
[15:47] <zyga-suse> https://paste.gnome.org/pddn5v3pp
[15:47]  * zyga-suse is grumpy 
[15:47] <zyga-suse> well
[15:48] <Chipaca> zyga-suse: here: https://www.youtube.com/watch?v=u5XDnaeGbLk
[15:48] <Chipaca> that one cheers me up :-)
[15:48] <mup> PR snapd#3586 closed: client, daemon: rest api to reconfigure snapd with a custom store <Created by atomatt> <Closed by atomatt> <https://github.com/snapcore/snapd/pull/3586>
[15:48] <mup> PR snapd#3590 closed: cmd/snap: snap cli to set or revert the custom store <Created by atomatt> <Closed by atomatt> <https://github.com/snapcore/snapd/pull/3590>
[15:49] <jdstrand> zyga-suse: unfortunately the reviews for commits doesn't let me group them altogether, so they are coming in piecemeal, but I'm done now
[15:51] <kyrofa> I just updated snapd in my lxd container to 2.26.10, and it's no longer starting up
[15:52] <kyrofa> I'm getting this: "snapd.service: Failed at step NICE spawning /usr/lib/snapd/snapd: Permission denied"
[15:52] <zyga-suse> jdstrand: that's fine, I get notified on each in a separate section
[15:52] <Chipaca> kyrofa: i think there's a bug about that
[15:54] <Chipaca> kyrofa: look for Nice=-5 in snapd.service and nuke it
[15:54] <Chipaca> kyrofa: and shake your fist at systemd, or at the universe in general
[15:55] <kyrofa> Chipaca, I suppose we still have no spread tests running on lxd, then?
[15:55] <Chipaca> kyrofa: and then systemctl daemon-reload, and maybe restart snapd
[15:55] <ogra_> i think we do, but the fix (dropping NICE=) actually landed in 2.27.3
[15:56] <Chipaca> kyrofa: it broke after we'd released (the nice has been there for a while)
[15:56] <Chipaca> kyrofa: the universe has very good integration tests
[15:56] <Chipaca> kyrofa: but they run on production
[15:57] <pedronis> kyrofa: mvo started some but it there were issues
[15:58] <kyrofa> pedronis, what issues?
[15:58] <pedronis> kyrofa:  https://github.com/snapcore/snapd/pull/3372
[15:59] <kyrofa> Chipaca, thanks for the Nice hint, I'm back up and running. Teach me to update my production instance
[15:59] <mup> PR snapd#3372: tests: add basic lxd test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3372>
[16:00] <kyrofa> Thanks pedronis
[16:00] <ogra_> do we re-exec in lxd ? then you could just switch to the core in beta
[16:00] <ogra_> hmm ... or not since the systemd unit probably still comes from the outside
[16:00] <pedronis> this is about the .service files so reexec doesn't help
[16:00] <ogra_> yeah, just struck me
[16:03] <mup> PR snapd#3801 opened: tests: add test to ensure amd64 can run i386 syscall binaries <Created by mvo5> <https://github.com/snapcore/snapd/pull/3801>
[16:04] <kyrofa> There are numerous other issues in lxd as well. Particularly the garbage collection one
[16:04] <mvo> kyrofa: https://github.com/snapcore/snapd/pull/3372 has some code but I couldn't make it reliable (I get the irony)
[16:04] <mup> PR snapd#3372: tests: add basic lxd test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3372>
[16:04] <kyrofa> mvo yeah, bad sign eh? :P
[16:10] <zyga-suse> lxd
[16:11] <mup> PR snapd#3794 closed: asserts,overlord/devicestate: revert allowing 'generic'-signed serials <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3794>
[16:13] <zyga-suse> well
[16:13] <zyga-suse> I really want to break now
[16:14] <zyga-suse> jdstrand: I pushed more patches there but I failed to use dirs (cycles)
[16:15] <Chipaca> zyga-suse: snapd#3692 is blocked on you
[16:15] <mup> PR snapd#3692: tests: install most important snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3692>
[16:16] <zyga-suse> Chipaca: approved
[16:17] <mup> PR snapd#3785 closed: asserts,overlord/devicestate: accept generic serials only if the model has generic-serials: true <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3785>
[16:19] <Chipaca> zyga-suse: snapd#3635 has some changes requested by cachio, a week ago
[16:19] <mup> PR snapd#3635: tests: add out-of-the-box test suite <Created by zyga> <https://github.com/snapcore/snapd/pull/3635>
[16:19] <zyga-suse> I should close that PR
[16:20] <zyga-suse> it doesn't work well with rest of spread suites
[16:21] <niemeyer> Alright
[16:21] <niemeyer> I've made a change in Spread, and from now on it should be cleaning systems even in those bad situations
[16:22] <niemeyer> It cannot prevent the space errors since this can be caused simply by interrupting forcefully previous processes in a bad moment, but it will clean up those machines and the error will be gone
[16:23] <niemeyer> I can already see the effect.. just from the last few PRs run, systems are all clean already
[16:24] <niemeyer> So hopefully this is the last thing that required manual care
[17:08] <superjonotron> is there a way to mount a usb drive as writable on ubuntu core?  read only file system changes mount permissions to root and read only so i can't copy anything off of the system onto a usb device
[17:12] <pedronis> cachio: we are still getting    fakestore service not started properly
[17:12] <pedronis> + exit 1  sometimes
[17:12] <pedronis> cachio: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170824_094354_789aa@/log.gz
[17:12] <pedronis> we probably need to log some more there
[17:14] <cachio> pedronis, yes
[17:14] <cachio> pedronis, we should need to see the state of the port at least
[17:14] <pedronis> and the systemd log of the unit
[17:15] <pedronis> we make a unit I think for it, I had forgotten about it
[17:15] <cachio> pedronis, yet, i'll create a branch to add debug information
[17:17] <mup> PR snapd#3787 closed: cmd/snap-repair: more test coverage of filtering <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3787>
[17:17] <pedronis> mvo: I think I asked before, should we reenable the fedora tests? or things are still to unstable to add more potential instability?
[17:17] <pedronis> s/to unstable/too unstable/
[17:18] <cachio> pedronis, the problem is tht I'll need to add debug info to all the tests using the fake store
[17:19] <cachio> pedronis, is it ok?
[17:19] <pedronis> cachio: ?
[17:20] <pedronis> just in setup_fake_store
[17:20] <pedronis> or however is called
[17:20] <cachio> ok,
[17:20] <pedronis> before it does exit 1
[17:21] <jdstrand> cachio: hey, when you get a chance, can you re-review https://github.com/snapcore/snapd/pull/3759
[17:21] <mup> PR snapd#3759: add spread test for wayland <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3759>
[17:22] <cachio> jdstrand, sure
[17:24] <jdstrand> cachio: thanks! :)
[17:26] <mup> PR snapd#3802 opened: tests: adding debug info fakestore when it does not start properly <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3802>
[17:29] <pedronis> cachio: seems there's an addition of tests/main/install-snaps/task.yaml  that doesn't belong there
[17:29] <pedronis> I thought you had a different branch with that in it
[17:31] <cachio> jdstrand, minor comment inline
[17:32] <cachio> pedronis, repearing it
[17:35] <mup> PR snapd#3802 closed: tests: adding debug info fakestore when it does not start properly <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3802>
[17:35] <mup> PR snapd#3803 opened: tests: adding extra info for fakestore when fails to start <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3803>
[17:36] <cachio> pedronis, yes I created a branch based on another one and not from master
[17:36] <cachio> my fault
[17:36] <cachio> pedronis, PR 3803 now
[17:37] <willdeberry> if someone has a moment, what am i missing here? https://forum.snapcraft.io/t/accessdenied-when-running-my-packaged-bluetooth-app/1724/15
[17:42] <superjonotron> mount usb as writable on snappy, anybody know how to accomplish?
[17:42] <jdstrand> cachio: thanks, fixed
[17:53] <Chipaca> willdeberry: maybe https://github.com/chipaca/bin/blob/master/run-snapd-srv helps
[17:53] <Chipaca> willdeberry: but at a glance i think SNAP_REEXEC=0 is the one you're missing
[17:53] <Chipaca> good luck
[18:27] <superjonotron> is it possible to run a snap command from within a snap command for a different snap?
[18:32] <kyrofa> superjonotron, no, at least not currently
[18:33] <superjonotron> back to the drawing board it is then
[18:42] <Pharaoh_Atem> aww
[18:42] <Pharaoh_Atem> I'm sad
[18:42] <Pharaoh_Atem> davidcalle's new design for the front page doesn't have Fedora in the center anymore :(
[18:43] <Pharaoh_Atem> it has.. Debian (meh)
[18:43] <Pharaoh_Atem> davidcalle: I'm hurt... after all that time spent actually keeping stuff up to date :P
[18:46] <niemeyer> Hadn't seen the new design.. looks nice
[18:47] <davidcalle> niemeyer: just landed
[18:47] <niemeyer> davidcalle: Nice!
[18:47] <niemeyer> Let me change the forum icon so it looks the same size
[18:48] <davidcalle> Pharaoh_Atem, if it can be of any consolation, there is someone, somewhere, browsing the site on a tablet in portrait mode and seeing Fedora in the center https://usercontent.irccloud-cdn.com/file/0C2RMUS3/Screenshot%20from%202017-08-24%2020-46-51.png
[18:54] <niemeyer> davidcalle++
[19:17]  * zyga-suse hug, Pharaoh_Atem
[19:21] <ogra_> davidcalle, hmm, in my browser the distro icons on the site look rather awful ...
[19:22] <davidcalle> ogra_: can you grab a screenshot, what's your browser ?
[19:23] <ogra_> davidcalle, http://people.canonical.com/~ogra/snapcraft-io-logos.png
[19:24] <ogra_> kind of off-center and a tad to large for the boxes
[19:25] <davidcalle> Oh wow, that's rather funky, refresh maybe ? Could be some CSS caching gone wrong
[19:25] <ogra_> dang ... doesnt change if i refresh the screenshot madly in the browser :P
[19:25] <ogra_> davidcalle, yeah, that fixed it ...
[19:26] <davidcalle> Hah, interesting, you are the second person to report something like that, ty
[19:26] <ogra_> properly centered and scaled after a refresh
[19:32] <mup> PR snapcraft#1500 closed: grammar: move into project_loader <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1500>
[19:34] <sergiusens> davidcalle: is the tour gone from all documentation instances?
[19:34] <sergiusens> if so, I'd be happy to remove it from snapcraft itself as it is somewhat a maintenance burden
[19:35] <mup> PR snapd#3692 closed: tests: install most important snaps <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3692>
[19:45] <zyga-suse> mwhudson: hey? around?
[19:46] <zyga-suse> mwhudson: I was wondering if I could do a point release of snapd for debian one day, just prepare it and get you to ack it
[19:54] <zyga-suse> mwhudson: I'd like to deprecate snap-confine (the package)
[19:54] <zyga-suse> mwhudson: I really think we should get rid of it from sid
[19:54] <zyga-suse> mwhudson: and send it the way of ubuntu-app-launcher
[20:00] <mup> PR snapd#3804 opened: cmd/snap-seccomp: support parsing 'u:' and 'g:' for username and groups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3804>
[20:26] <mup> PR snapd#3803 closed: tests: adding extra info for fakestore when fails to start <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3803>
[20:28] <mup> PR snapd#3801 closed: tests: add test to ensure amd64 can run i386 syscall binaries <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3801>
[20:47] <mup> PR snapd#3805 opened: interfaces/default,account-control: don't hardcode uid and gid. Use username and group instead <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3805>
[20:50] <zyga-suse> jdstrand: interesting
[20:51] <zyga-suse> jdstrand: why the unsafe/C handling vs golang's user module?
[21:00] <jdstrand> zyga-suse: there is a comment in there
[21:00]  * zyga-suse looks closer
[21:01] <jdstrand> zyga-suse: LookupGroup is not implemented
[21:01] <jdstrand> zyga-suse: so I stole it from upstream master
[21:01] <zyga-suse> ah, drat
[21:01] <zyga-suse> makes sense
[21:01] <jdstrand> I very much wanted to use the user module :)
[21:01] <janisozaur> zyga-suse: I'm here now. Do you still need something tested on Arch?
[21:01] <zyga-suse> hey
[21:01] <zyga-suse> janisozaur: you can try this
[21:02] <zyga-suse> https://github.com/snapcore/snapd/releases/download/2.27.4/snapd-2.27.4-1-x86_64.pkg.tar.xz
[21:02] <zyga-suse> this is the latest release
[21:02] <janisozaur> try how?
[21:02] <zyga-suse> janisozaur: we are also looking to resolve a problem with the package maintainer
[21:02] <zyga-suse> janisozaur: install it :) this is the arch package
[21:02] <zyga-suse> if you prefer to rebuild: https://github.com/snapcore/snapd/releases/download/2.27.4/snapd-2.27.4-1-arch-srcpkg.tar.gz
[21:03] <janisozaur> yes, but what next?
[21:03] <zyga-suse> janisozaur: just install it and see if things work for you
[21:03] <zyga-suse> it contains several fixes since 2.27
[21:04] <zyga-suse> there are two forum threads
[21:04] <zyga-suse> https://forum.snapcraft.io/t/issue-with-discord-snap-in-arch/1811
[21:04] <janisozaur> i imagine opengl is not one of them?
[21:04] <zyga-suse> and https://forum.snapcraft.io/t/updates-to-snapd-package-on-arch/1467
[21:04] <mup> PR snapd#3798 closed: release: 2.27.4 <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3798>
[21:04] <zyga-suse> janisozaur: no change in that area yet :/
[21:08]  * zyga-suse EODs
[21:13] <janisozaur> scummvm appears to work with that package
[21:37] <mwhudson> zyga-suse: o/
[21:38] <zyga-suse> o/
[21:38]  * zyga-suse is really almost sleeping
[21:38] <mwhudson> heh
[21:38] <mwhudson> zyga-suse: well that makes sense
[21:38] <mwhudson> i guess ~everyone who has snap-confine installed has snapd too
[21:39] <mwhudson> so if you change snapd to replaces: snap-confine people upgrading to buster will get snap-confine removed which is what we want?
[21:39] <mwhudson> zyga-suse: just push a branch to alioth when you want me to look at it?
[21:39] <zyga-suse> I think this is also what we did in ubuntu
[21:39] <zyga-suse> ok, I need to brush up my debian skills,
[21:40] <zyga-suse> I'll experiment and push
[21:43] <mwhudson> either push to debian or a new branch depending on confidence level :)
[22:01] <Pharaoh_Atem> zyga-suse: woohoo!
[22:02] <Pharaoh_Atem> DNF is now in Factory!
[22:02] <Pharaoh_Atem> or rather, it will be in the next few minutes
[22:02] <Pharaoh_Atem> it passed legal-auto a few minutes ago
[22:03] <kyrofa> zyga-suse, if I need to log a bug against snap-confine, do I log against snapd these days?
[22:03] <kyrofa> jdstrand, perhaps you're a better person for that question this time of day
[22:04] <Pharaoh_Atem> kyrofa: they go against snapd now
[22:04] <kyrofa> Thanks Pharaoh_Atem :)
[22:05] <kyrofa> Does that mean the bugs at https://bugs.launchpad.net/snap-confine should be reassigned?
[22:05] <stgraber> kyrofa: that was quick :)
[22:05] <kyrofa> stgraber, dude, you're a life-saver
[22:05] <kyrofa> stgraber, I've been hitting that for weeks now
[22:06] <kyrofa> stgraber, I have three containers in production, each of which requires me to SSH into it and convince them to update whenever new snaps come out
[22:06] <kyrofa> I had no clue what was happening
[22:24] <mup> Issue snapcraft#1506 opened: Inconsistent formatting when opening vs. closing channels <Created by Roadmaster> <https://github.com/snapcore/snapcraft/issue/1506>