[01:31] <willdeberry> any around around by chance?
[01:31] <willdeberry> anyone*
[04:22] <mup> PR snapd#3806 opened: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3806>
[05:53] <mup> PR snapd#3693 closed: snapstate: improve the error message when classic confinement is not supported <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3693>
[07:04] <mup> PR snapd#3806 closed: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3806>
[07:11] <pedronis> ++ dnf -q -y --refresh install 'pkgconfig(systemd)'
[07:11] <pedronis> Error: Failed to synchronize cache for repo 'updates'
[07:33] <zyga-suse> kyrofa: re
[07:33] <zyga-suse> kyrofa: not sure about bug tracking, I think keeping it all in snapd is easier though
[07:33] <zyga-suse> good morning everyone :-)
[07:39] <mvo> zyga-suse_: hey, I think I addressed your points in 3260, let me know. I will ponder a bit more over the cmd_userd_test.go in the meantime
[07:39] <zyga-suse_> hey
[07:40] <zyga-suse_> thank you, let me look
[07:40] <zyga-suse_> I'm working on a blanket in the grass
[07:40] <zyga-suse_> I wonder if people will wonder what I do here ^_^
[07:49] <zyga-suse_> mvo: poor network connection, are you reading this?
[07:50] <mvo> zyga-suse_: yes
[08:01] <zyga-suse_> odd, I can chat on IRC but I cannot load any website
[08:04] <zyga-suse_> loaded
[08:09] <zyga-suse_> mvo: replied on the Ping comment
[08:09] <zyga-suse_> mvo: that's the only part I really cared about
[08:09] <zyga-suse_> let me read the diff
[08:13] <zyga-suse_> mvo: reviewed
[08:15] <zyga-suse_> mvo: I'm sorry about being strict about that ping method there, let me know if that works in the end
[08:18] <mvo> zyga-suse_: we are not implementing Ping() currently
[08:18] <mvo> zyga-suse_: we are not implementing the Dbus.Peer interface at all
[08:18] <zyga-suse_> mvo: go dbus doesn't do it for free?
[08:18] <zyga-suse_> it's typically implemented by libraries
[08:18] <mvo> zyga-suse_: unfortunately not
[08:18] <zyga-suse_> aww, bummer
[08:18] <zyga-suse_> that's not good
[08:18] <mvo> zyga-suse_: at least not as far as I can tell
[08:18] <mvo> zyga-suse_: d-feet is what i use
[08:18] <zyga-suse_> does it show up in introspection?
[08:18] <zyga-suse_> aha
[08:18] <mvo> zyga-suse_: yes, introspection shows up
[08:19] <zyga-suse_> I mean, does Peer show up?
[08:19] <mvo> zyga-suse_: no, peer does not show up at all, it does show up for the old safe launcher though (because dbus-gio)
[08:19] <zyga-suse_> right
[08:20] <Chipaca> good morning all! happy "all versions of go shipped in ubuntu are obsolete" day!
[08:20] <Chipaca> (1.9 is out)
[08:20] <zyga-suse_> oh, nice
[08:20] <zyga-suse_> anything shiny?
[08:20] <zyga-suse_> are generics in yet?
[08:21] <Chipaca> zyga-suse_: type aliases are a thing
[08:21] <Chipaca> zyga-suse_: and monotonic time
[08:21] <zyga-suse_> whee
[08:21] <zyga-suse_> so 2001 of us
[08:21] <mvo> zyga-suse_: I look into it, maybe we are just holding^Wusing it wrong
[08:22] <zyga-suse_> mvo: maybe we could just implement Peer
[08:22] <zyga-suse_> it's no-op Ping
[08:22] <zyga-suse_> and get machine id
[08:22] <Chipaca> zyga-suse_: the nicest change that would impact my work is that ./... no longer looks in vendor
[08:23] <zyga-suse_> yes, I saw that one
[08:23] <zyga-suse_> that's a nice change
[08:23] <Chipaca> so go test ./... would finally dtrt
[08:23] <mvo> zyga-suse_: yeah, otoh, if we can call OpenURL and get a reply like "cannot use ping-ping-ping:" we know the interface is up as well. but yeah, ping is nicer, I have a look
[08:24] <zyga-suse_> Chipaca: I'm still holding out for generics
[08:24] <zyga-suse_> mvo: agreed
[08:24] <zyga-suse_> mvo: if you want +1, just move to libexecdir
[08:24] <zyga-suse_> mvo: I may look at Ping over weekend
[08:25] <mvo> zyga-suse_: we are actually using the normal "snap" command for the userd subcommand, so it will be the regular bindir (unless I miss something)
[08:25] <zyga-suse_> mvo: ahh, sorry
[08:25] <zyga-suse_> I must have misread the diff
[08:25] <mvo> zyga-suse_: no worries
[08:25] <zyga-suse_> I assumed it would be a new binary
[08:25] <zyga-suse_> ok, I have two tests to fix
[08:26] <zyga-suse_> and a lot of goodies will be ready
[08:26] <zyga-suse_> but first
[08:26] <zyga-suse_> coffee!!!
[08:27] <mvo> zyga-suse_: heh, fun! if I export the ping interface things work
[08:27] <mvo> zyga-suse_: oh well, I will update things
[08:30] <Chipaca> zyga-suse_: did you see the guy that had generics implemented via unicode and generators?
[08:34] <pedronis> mvo: there was no joy with the fedora tests btw, still failed in prepare in strange ways, are we tuning ip6 on fedora as well?
[08:35] <zyga-suse_> mvo: things work?
[08:35] <zyga-suse_> Chipaca: I think I don't actually want to know anymore :D
[08:35] <zyga-suse_> pedronis: probably not, it's behind ubuntu spread test flag
[08:37] <pedronis> anyway something is off and makes those even more unstable than usual
[08:37] <Chipaca> zyga-suse_: bottom line: it looked like “type ImmutableTreeListᐸElementTᐳ struct {”
[08:37] <pedronis> or the fedora infra itself is flakier, no clue
[08:37] <mvo> pedronis: I have not looked at the details for fedora unfortunately
[08:37] <mvo> zyga-suse_: yeah, ping works once the interface is exported via xml, no code needed, I will update in a bit (working on tests right now)
[08:38] <zyga-suse_> woot!
[08:38] <zyga-suse_> nice :)
[08:38] <zyga-suse_> ah
[08:38] <zyga-suse_> right
[08:38] <zyga-suse_> because introspection is how dfeet knows about it
[08:38] <zyga-suse_> though odd that this is not done by gdbus itself
[08:40] <mup> PR snapd#2837 closed: interfaces/apparmor: allow reading from ecryptfs <Blocked> <Decaying> <Created by zyga> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2837>
[08:44] <zyga-suse_> thank you :'-(
[08:44] <zyga-suse_> though we _may_ have a way to solve that with what I'm working on
[08:45] <mup> PR snapd#3346 closed: [WIP] allow access to nm-dispatcher scripts <Decaying> <Created by felicianotech> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3346>
[08:50] <Chipaca> hmm, i've got to test stuff that involves rebooting. I'll be pestering you with in/out messages soon :-)
[08:51] <zyga-suse_> Chipaca: VMs/
[08:52] <Chipaca> zyga-suse_: i'm too close to my memory limit :-(
[08:52] <Chipaca> (this is a test that needs a full desktop)
[08:52] <Chipaca> brb
[08:53] <zyga-suse_> aww
[08:53]  * zyga-suse_ has apparmor on opensuse :)
[08:53] <zyga-suse_> and we can now probably also enable reexec
[08:53] <zyga-suse_> there's still a few things missing but I think it's very very closenow
[08:54] <zyga-suse_> mvo: is the PR ban still in effect?
[08:59] <Chipaca> morphis_: zyga-suse_: so it looks like moving /etc/X11/Xsession.d/65snappy to e.g. /etc/profile.d/snappy.sh will DTRT in both X and Wayland (might need some tweaks, but basically it'll work)
[09:00] <Chipaca> morphis_: zyga-suse_: I know RH/fedora are slightly different wrt profile.d, but afaik it boils down to it getting loaded more, not less; can you confirm?
[09:00] <zyga-suse_> Chipaca: if you test it, +1
[09:00] <zyga-suse_> Chipaca: I think we want to dedupe those files
[09:00] <Chipaca> this is me looking at snapd#3398
[09:00] <mup> PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398>
[09:00] <zyga-suse_> Chipaca: there's one in every distro packaging
[09:00] <zyga-suse_> Chipaca: and then we want to call it sanely, say snapd.sh
[09:01] <zyga-suse_> Chipaca: and keep it in data/
[09:01] <Chipaca> zyga-suse_: i tested it on ubuntu, but as i said i don't have the space to test it on other things
[09:01] <zyga-suse_> Chipaca: I see
[09:01] <Chipaca> bah. i might be able to get this fedora running
[09:01] <Chipaca> should work with 1G, right?
[09:01] <zyga-suse_> Chipaca: I can test on all of them but I'd prefer to do that in the afternoon with less sharp mind
[09:01] <Chipaca> yeah no probs
[09:01] <zyga-suse_> Chipaca: nah
[09:01] <zyga-suse_> try 2G
[09:01] <Chipaca> sigh, ok
[09:01] <zyga-suse_> how much ram do you have?
[09:01] <Chipaca> lots of swapping ahead for me :-)
[09:01] <zyga-suse_> I have a _physical_ fedora box with 2GB and it's a pain
[09:02] <zyga-suse_> I added 1GB stick to make it work
[09:02] <Chipaca> zyga-suse_: free right now? 1G
[09:02] <zyga-suse_> OMG
[09:02] <zyga-suse_> and in general?
[09:02] <Chipaca> zyga-suse_: 4G total
[09:02] <zyga-suse_> darn
[09:02] <zyga-suse_> no way to expand?
[09:02] <Chipaca> i had 8 but one of the sticks died
[09:02] <Chipaca> and the whole box is starting to die
[09:02] <Chipaca> so i'm just letting it
[09:02] <zyga-suse_> aha
[09:02] <zyga-suse_> thinkpad?
[09:02] <Chipaca> while saving up for its replacement
[09:02] <zyga-suse_> man, buy t430 for the price of a good meal
[09:02] <Chipaca> zyga-suse_: latitude e series
[09:02] <zyga-suse_> they are indestructible
[09:03] <zyga-suse_> and cost peanuts
[09:03] <Chipaca> it's ~8 years old
[09:03] <Chipaca> if i were to buy the same thing, it'd cost peanuts too
[09:03] <zyga-suse_> what are you saving for?
[09:03] <Chipaca> but these old cpus suck 45W when angry, i'll gladly pay to worry about that less
[09:03] <zyga-suse_> so what if you can get a battery with 11hrs of life?
[09:04] <Chipaca> zyga-suse_: probably a latitude e series :-)
[09:04] <zyga-suse_> and still buy three for the price of one new box
[09:04] <Chipaca> zyga-suse_: 15
[09:04] <Chipaca> zyga-suse_: this box had 15 hours battery life when it and the batteries were new
[09:04]  * zyga-suse_ chooses not to buy new laptops again
[09:04] <Chipaca> zyga-suse_: ah, it'd not be new, it'd be refurb
[09:04] <zyga-suse_> ah
[09:04] <zyga-suse_> +100 on that
[09:04] <zyga-suse_> it's worse than with used cars
[09:05] <Chipaca> i can't in good conscience justify the price nor environmental cost of new
[09:05] <zyga-suse_> you open the door and 30% is gone
[09:05] <zyga-suse_> yep
[09:05] <zyga-suse_> especially when new CPUs suck so badly lately
[09:05] <zyga-suse_> with less and less reliablity and features
[09:06] <zyga-suse_> I wonder when amd will show their mobile ryzen/threadripper units
[09:08]  * zyga-suse_ sees ants crawling over his keys
[09:08] <zyga-suse_> not ogod
[09:09] <ogra_> they probably just want to help
[09:10]  * zyga-suse_ plays bug squashing
[09:11] <zyga-suse_> Chipaca: buy this and run !ubuntu distro on it http://www.ebay.es/itm/Lenovo-ThinkPad-T530-i5-3210M-2x2-5GHz-8GB-128GB-SSD-UMTS-NVS5400-Webcam-WIN10-/253112700548?hash=item3aeeb14e84:g:KsAAAOSw01dZnrBX
[09:11] <zyga-suse_> Chipaca: and work on it 2/5 days a week
[09:11] <zyga-suse_> snapd must feel great everywhere
[09:12] <ogra_> well, if you want low-end, get a beaglebone :P
[09:12] <zyga-suse_> ogra_: ahem
[09:12] <zyga-suse_> ogra_: that's way more than sufficient for work
[09:12] <zyga-suse_> ogra_: and it has twice the RAM that Chipaca has now
[09:13] <zyga-suse_> it would be good if we had someone running centos
[09:13] <zyga-suse_> or if feeling less bold, just run opensuse or fedora where there's very good support already
[09:13] <zyga-suse_> ogra_: what are you using daily?
[09:13] <zyga-suse_> (h/w wise)
[09:14] <ogra_> well, depends where i sit
[09:15] <ogra_> in my office i have a "Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz" with 32G, 3TB raid, 500G SSD, triple head nvidia 970
[09:15] <ogra_> (+3x 22" LG HD monitors )
[09:15] <ogra_> in my living room my first gen XPS13
[09:16] <ogra_> (some early i7, i forgot which and 8GB)
[09:16] <Chipaca> zyga-suse_: http://www.morgancomputers.co.uk/c/512/IBM-Lenovo/
[09:16] <zyga-suse_> nice desktop setup!
[09:17] <Chipaca> OTOH i coould set up my bbb
[09:17] <Chipaca> i'd need bluetooth and wifi to be working on it though
[09:17] <zyga-suse_> punch-card speed IO
[09:17] <ogra_> hmm, then a pi3 rather ...
[09:17] <Chipaca> i thought io on the pi3 was slower than the bbb
[09:17] <ogra_> (though thats pretty powerful for an arm board)
[09:18] <zyga-suse_> no, nothing is slower than bbb
[09:18] <ogra_> well, pi3 is quad core 1.2GHz ...
[09:18] <zyga-suse_> Chipaca: pi3 when using HDD is very much usable
[09:18] <ogra_> bbb is single 800MHz
[09:18] <zyga-suse_> Chipaca: just get that fancy Pi drive and boot away
[09:18] <zyga-suse_> no SD cards needed
[09:18] <ogra_> as long as you dont use any other USB devices on it, yeah
[09:18] <zyga-suse_> (or any HDD with a usb cable)
[09:19] <zyga-suse_> it's good enough for coding IMO
[09:19] <ogra_> wired anetwork and HDD at the same time can already get nasty
[09:19] <ogra_> the USB hub gets saturated easily
[09:20] <zyga-suse_> it's limited but for the price it's really good
[09:21] <ogra_> well ... for the price, yeah
[09:32] <zyga-suse_> mvo: trivia PR pre-reviewed by jdstrand https://github.com/snapcore/snapd/pull/3807
[09:32] <mup> PR snapd#3807: cmd/snap-confine,packaging: import snapd-generated policy <Created by zyga> <https://github.com/snapcore/snapd/pull/3807>
[09:32] <zyga-suse_> I stated doing internal reviews with jamie so that we can start with a +1 and land things faster
[09:33] <mup> PR snapd#3807 opened: cmd/snap-confine,packaging: import snapd-generated policy <Created by zyga> <https://github.com/snapcore/snapd/pull/3807>
[09:33] <ogra_> hmm ...
[09:34] <mup> PR snapd#3791 closed: cmd/snap-confine: allow using additional libraries required by openSUSE <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3791>
[09:34] <mup> PR snapd#3792 closed: cmd/snap-confine: allow running snap-exec without confinement <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3792>
[09:34] <ogra_> why is my daily edge image installing core 2466 on first boot ?
[09:34] <zyga-suse_> 2466 feels 1000 builds too old
[09:34] <ogra_> yes
[09:35] <ogra_> especially for an edge build
[09:35] <ogra_> 2739 is the current core in armhf edge
[09:36] <ogra_> this smells like firstboot didnt set up the system properly
[09:36] <ogra_> :/
[09:36] <zyga-suse_> what's in /var/lib/snapd/snaps ?
[09:38] <ogra_> ogra@pi2:~$ snap list
[09:38] <ogra_> No snaps are installed yet. Try "snap install hello-world".
[09:38] <ogra_> ogra@pi2:~$
[09:38] <ogra_> grmpf
[09:38] <ogra_> ogra@pi2:~$ ls /var/lib/snapd/snaps/
[09:38] <ogra_> core_2466.snap  core_2739.snap  pi2-kernel_39.snap
[09:38] <ogra_> ogra@pi2:~$
[09:38] <ogra_> no gadget
[09:39]  * ogra_ starts over with a fresh flash to capture the log of the first boto
[09:39] <ogra_> *boot
[09:41] <zyga-suse_> Chipaca: did you see the new "dep" tool?
[09:41] <zyga-suse_> ogra_: super odd
[09:41] <Chipaca> zyga-suse_: in go?
[09:41] <zyga-suse_> ogra_: how did youget 2466? from ubuntu-image?
[09:41] <zyga-suse_> Chipaca: yes
[09:41] <ogra_> zyga-suse_, i didnt ..
[09:42] <ogra_> zyga-suse_, core_2739.snap
[09:42] <zyga-suse_> sure but 2466 is present there as well
[09:42] <ogra_> u-image did the right thing ... but the initial setup failed ... i usually install avahi as first thing after setting the hostname when testing ... that pulled core from stable
[09:43] <zyga-suse_> aha
[09:46] <ogra_> and this time it takes actually longer to get to "please press enter" ... last round this casme up immediately which indicates the key generation didnt take place
[09:47] <ogra_> ogra@localhost:~$ snap list
[09:47] <ogra_> Name        Version                   Rev   Developer  Notes
[09:47] <ogra_> core        16-2.27.4+git331.b672daf  2739  canonical  core
[09:47] <ogra_> pi2         16.04-0.18                39    canonical  gadget
[09:47] <ogra_> pi2-kernel  4.4.0.1070.70             39    canonical  kernel
[09:47] <ogra_> ogra@localhost:~$
[09:47] <ogra_> hrm ... so there was a race in the first run ... which is gone now :/
[09:51] <ogra_> i'm always surprised how different the memory usage between the different arm boards is
[09:52] <ogra_> on the nanopi-air htop shows 48.7MB used ... the pi2 with the same set of snaps installed and running uses 70.3MB
[09:53] <mup> PR snapd#3808 opened: apparmor,release: add better apparmor detection/mocking code <Created by zyga> <https://github.com/snapcore/snapd/pull/3808>
[09:53] <zyga-suse_> mvo: another small branch pre-approved with jdstrand
[09:53] <ogra_> (both armhf, both using the same core )
[09:53] <mvo> zyga-suse_: ok, looking
[09:53] <zyga-suse_> mvo: I have a tiny branch on top that will let debian and suse to enable apparmor
[09:53] <zyga-suse_> mvo: and that will let us enable reexec on suse :)
[09:54] <zyga-suse_> mvo: the last holdout of reexec will be distro layout (fixed with layouts) and /snap location (not covered by layouts yet)
[09:56] <ogra_> fgimenez, ppisati, any idea why all our stable kernels are like 6 revisions behind ?
[10:02]  * zyga-suse_ -> small break
[10:02] <zyga-suse_> everyone: please request my reviews on things you want me to look at
[10:03] <fgimenez> ogra_: nope, i don't know
[10:26] <pedronis> mvo: so the problem test seems a quirk of task without undo handlers, their change is ready "sooner", don't think it should block your branch, but I would like to explore not needed Overlord.Loop there
[10:37] <mvo> pedronis: aha, I see! I can add an undo handler for now as a workaround until we have time to explore further. thanks a lot for looking into this
[10:49] <Chipaca> mvo: if what's now /etc/profile.d/apps-bin-path.sh suddenly becomes /etc/profile.d/snapd.sh, does apt/dpkg/something freak out?
[10:53] <mup> PR snapd#3809 opened: tests: copy files with less verbosity <Created by zyga> <https://github.com/snapcore/snapd/pull/3809>
[10:53] <zyga-suse_> mvo: trivial for my modem woes ^
[10:53] <zyga-suse_> Chipaca: yes
[10:53] <zyga-suse_> you need to rm conffile
[10:58] <zyga-suse_> Chipaca: or in other words, you want to ship your computer to the arctic, move north and herd sheep
[10:59] <Chipaca> zyga-suse_: the name just strikes me as odd, especially now that it'll have XDG stuff in it :-)
[10:59] <Chipaca> but they are technically both paths
[10:59] <Chipaca> so ¯\_(ツ)_/¯
[10:59] <zyga-suse_> Chipaca: yeah, the name is bad
[10:59] <zyga-suse_> Chipaca: I'd like to have just "snapd.sh", period
[10:59] <Chipaca> that's what i was proposing above
[10:59] <zyga-suse_> Chipaca: new systemd (we cannot assume it though) has nicer way to do this
[11:00] <Chipaca> zyga-suse_: it does?
[11:00] <zyga-suse_> one sec
[11:00] <Chipaca> anyway, time for me to go run
[11:00]  * Chipaca waits
[11:00] <zyga-suse_> let me pull the discussion with systemd devs
[11:00] <mup> PR snapd#3810 opened: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>
[11:00] <zyga-suse_> from my blog ...
[11:01] <zyga-suse_> https://new.zygoon.pl/post/case-study-snapd-on-centos/
[11:01] <zyga-suse_> Chipaca: have a look there
[11:02] <zyga-suse_> there are links to a PR that has since landed in systemd: https://github.com/systemd/systemd/pull/5131
[11:02] <mup> PR systemd/systemd#5131: Environment generators <pid1> <Created by keszybz> <Merged by poettering> <https://github.com/systemd/systemd/pull/5131>
[11:03] <zyga-suse_> and while looking there, enjoy 102 open PRs for systemd
[11:03] <zyga-suse_> (we are not doing bad)
[11:03] <ogra_> well
[11:03] <zyga-suse_> though 806 contributors is x10 more than we have
[11:03] <ogra_> from our downstram POV thats not acgtually much different
[11:04] <ogra_> (environment.d vs profile.d ... )
[11:04] <ogra_> you still need to ship the snippet that assembles the variable
[11:04] <ogra_> just in another place
[11:04] <Son_Goku> environment.d happens earlier than profile.d
[11:04] <ogra_> sure sure
[11:04] <Son_Goku> though I hate putting things in either, really
[11:05] <ogra_> just saying that iit doesnt matter much regarding the naming of the fil ;)
[11:05] <ogra_> *fiile
[11:05] <ogra_> sigh ...
[11:05] <Son_Goku> that's okay, one day you'll get it :)
[11:05] <ogra_> my laptop keyboard slowly gives up
[11:06] <Son_Goku> zyga-suse_, we'll probably not have anywhere close to that number of contributors
[11:06] <zyga-suse_> Son_Goku: as I said, x10 less
[11:06] <zyga-suse_> Son_Goku: good to see you
[11:06] <zyga-suse_> Son_Goku: did you see my reply on the forum there?
[11:06] <Son_Goku> that would require rejiggering the project in a way that currently isn't possible :(
[11:07] <Son_Goku> the forum makes me angry, so I haven't looked since I posted yesterday
[11:07]  * zyga-suse_ hugs Son_Goku again
[11:08]  * Son_Goku sighs
[11:20] <mcphail> kyrofa: thanks for the 11.0.4 nextcloud update. Is 12.x on the roadmap? (I'm not complaing, btw. I don't even know what version 12 brings. Just curious!)
[11:33] <zyga-suse_> ogra_: what does it take to add /var/lib/snapd/apparmor/snap-confine.d to the core snap?
[11:33] <ogra_> two lines ?
[11:33] <ogra_> (assuming you want it writable, else one line)
[11:33] <zyga-suse_> yes, two lines
[11:33] <zyga-suse_> er
[11:33] <zyga-suse_> yes writable
[11:33] <zyga-suse_> where?
[11:33] <ogra_> heh
[11:34] <zyga-suse_> note that it's under /var/lib/snapd/apparmor which was writable before
[11:34] <zyga-suse_> does it need any work?
[11:34] <zyga-suse_> or do I just need to fix CI prep to mkdir that too
[11:34] <ogra_> zyga-suse_, https://github.com/snapcore/core/blob/master/live-build/hooks/20-extra-files.chroot for the mkdir -p ...
[11:35] <zyga-suse_> why there's no /var/lib/snapd/apparmor there/
[11:35] <ogra_> zyga-suse_, https://github.com/snapcore/core-build/blob/master/config/etc/system-image/writable-paths to make it writable
[11:35] <zyga-suse_> -> /var/lib/snapd auto persistent transition none
[11:35] <zyga-suse_> that's already present, so I think I'm good
[11:36] <ogra_> well, you want a mkdir somewhere ... if snap-confine creates it on startup or package install that should be sufficient
[11:36] <ogra_> else you need it in some of the build scripts like above
[11:36] <zyga-suse_> ogra_: the snapd package has that directory
[11:37] <ogra_> ok
[11:37] <zyga-suse_> ogra_: it's made and packaged in the deb
[11:39] <mup> PR snapd#3809 closed: tests: copy files with less verbosity <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3809>
[11:40] <zyga-suse_> mvo: thank you
[11:40] <zyga-suse_> mvo: please help me out with one thing
[11:40] <zyga-suse_> mvo: when I want to add a new directory under /var/lib/snapd/ (specifically /var/lib/snapd/apparmor/snap-confine.d) should I do anything more than just update packaging?
[11:41] <zyga-suse_> mvo: tests are failing and I assume it is because of this
[11:41] <zyga-suse_> mvo: I have a patch that looks like :
[11:41] <zyga-suse_> https://paste.gnome.org/pkhbjpoju
[11:42] <zyga-suse_> mvo: but I'm unsure if that will really hide the problem until release
[11:43] <ogra_> hmm
[11:43] <mvo> zyga-suse_: lets get to the bottom of this, the dir in the package should be enough, let me try to reproduce via spread
[11:44] <ogra_> you might have a problem if you need it on non-new systems ...
[11:44] <ogra_> since /var/lib/snapd is "transition" not synced
[11:44] <zyga-suse_> can you explain?
[11:45] <ogra_> transition only copies the dirs on the first run ...
[11:45] <ogra_> from core to writable
[11:45] <zyga-suse_> "transition"?
[11:45] <zyga-suse_> aha
[11:45] <zyga-suse_> I see
[11:45] <ogra_> so an upgraded ubuntu-image install wont simply add it
[11:45] <zyga-suse_> well
[11:45] <zyga-suse_> suggestions?
[11:46] <ogra_> systemd job ... or switch to "synced" but i'm not 100% sure about the latter
[11:46] <ogra_> (have to check the code)
[11:46] <willdeberry> when making a change to an interface, is building snapd cmd sufficient to pick up the changes? `go build -o /tmp/snapd github.com/snapcore/snapd/cmd/snapd`
[11:46] <zyga-suse_> ugh
[11:46] <zyga-suse_> willdeberry: yes, you need to re-start it though
[11:46] <zyga-suse_> willcooke: which backends are you changing
[11:47] <zyga-suse_> willdeberry: some things are not refreshed on startup
[11:47] <zyga-suse_> willcooke: (sorry, bad tab completion)
[11:47] <ogra_> zyga-suse_, for refrence http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html
[11:48] <zyga-suse_> ogra_: I just need an empty directory
[11:48] <zyga-suse_> but it _must_ be there
[11:48] <zyga-suse_> ogra_: and it may need to be there very early
[11:48] <zyga-suse_> ogra_: before apparmor profiles are loaded
[11:49] <zyga-suse_> and I think those are done before regular systemd units start
[11:49] <ogra_> well, given apparmor itself relies on writable-paths, that should be a given
[11:49] <ogra_> the issue is transition vs synced
[11:49] <ogra_>      WARNING:  This is a one-off operation which requires that the
[11:49] <ogra_>                  source  directory  on  the  writable  partition   not   exist
[11:49] <ogra_>                  initially: if this condition is satisfied, the directory will
[11:49] <ogra_>                  then be created and the data moved on  first  boot.  Although
[11:49] <ogra_>                  the  mountpoint  will be writable, note that subsequent boots
[11:49] <ogra_>                  will ignore any new files appearing or  disappearing  in  the
[11:49] <ogra_>                  original  read-only  rootfs  location  unless  you  perform a
[11:49] <ogra_>                  factory reset.
[11:49] <ogra_> (thats "transition" )
[11:50] <ogra_> note that subsequent boots
[11:50] <ogra_>                  will ignore any new files appearing
[11:50] <ogra_> that one specifically
[11:51]  * zyga-suse_ feels like not wanting to fight this fight on friday
[11:51] <willdeberry> zyga-suse_: still fighting on adding bluez interface to classic OS
[11:51] <zyga-suse_> but this is something he needs :/
[11:51] <zyga-suse_> willdeberry: which backends are you using in that interface?
[11:51] <ogra_> we might need to switch /var/lib/snapd to be "synced" to make your dir appear ... i'm just not sure what happens with existing files in the target dir
[11:52] <ogra_> alternatively a systemd unit that runs mkdir ...
[11:52] <zyga-suse_> yeah, I don't like that really :/
[11:52] <ogra_> which is surely the uglier option
[11:52] <willdeberry> zyga-suse_: i am not sure i am following. I am just needing to expose bluez as an interface on classic so my snap can connect to bluez as a plug
[11:53] <zyga-suse_> willdeberry: the bluez interface won't work as-is on classic
[11:53] <zyga-suse_> willdeberry: can you pastebin your diff from master please
[11:53] <willdeberry> https://github.com/willdeberry/snapd/commit/11001ff172e7ddc96f6109a0c8ff9b3e63595ad4
[11:55] <ogra_> zyga-suse_, why wouldnt bluez work as-iis on classic ? the files, devices and services it needs to access should be the same
[11:55] <zyga-suse_> ogra_: look at the diff
[11:55] <zyga-suse_> willdeberry: the diff look ok actually
[11:56] <zyga-suse_> willdeberry: can you please test both variants in each backend, ensuring that we don't get unexpected things?
[11:56] <zyga-suse_> ogra_: the confinement is very specific
[11:56] <ogra_> zyga-suse_, yeah, i meant more the interface itself ... not the conditions that make it available
[11:56] <zyga-suse_> ogra_: down to the point where peer is confined with a specific label
[11:56] <zyga-suse_> ogra_: and on classic that would be "unconfined"
[11:56] <ogra_> ah
[11:56] <zyga-suse_> ogra_: but the patch handles that so it looks correct
[11:57] <ogra_> yeah
[11:57] <willdeberry> zyga-suse_: right now, the bluez tests pass. the only tests i haven't fixed yet are the basedefinition tests which run when building the deb
[11:57] <zyga-suse_> willdeberry: they are in ../policy
[11:57] <zyga-suse_> just run them
[11:57] <willdeberry> k
[11:57] <zyga-suse_> (and fix)
[11:58] <ogra_> zyga-suse_, btw, do we have any mechanism for interfaces to check that the backend they allow access to is actually working/existing ?
[11:58] <zyga-suse_> ogra_: yes, implicitly
[11:58] <ogra_> imho bluez should be hidden on classic server installs that dont have BT installed/enabled
[11:58] <zyga-suse_> ogra_: interface methods specific to a backend are not used if the backend is not loaded
[11:59] <ogra_> ok
[11:59] <willdeberry> backend meaning the bluez service in regards to classic right?
[11:59] <zyga-suse_> ogra_: we don't do that distinction yet, I think it falls under hotplug a little, we should do it but it's fine to just have it, even if unsupplied
[11:59] <zyga-suse_> willdeberry: no, backend meaning one of the security backends in snapd
[11:59] <willdeberry> gotcha
[11:59] <ogra_> yeah, i meant the service backend actually
[11:59] <willdeberry> trying to map terminiology in my brain :)
[12:02]  * zyga-suse_ feels grumpy now
[12:13] <zyga-suse> pstolowski: review on 3810
[12:15] <pstolowski> zyga-suse, thanks
[12:15] <zyga-suse> pstolowski: if you want we can discuss the design here
[12:15] <zyga-suse> pstolowski: (standup may be hard with my data)
[12:16] <pstolowski> zyga-suse, I'll answer to comments on the PR first
[12:18] <zyga-suse> sure, thank you
[12:25] <zyga-suse> jdstrand: reviewed https://github.com/snapcore/snapd/pull/3805
[12:25] <mup> PR snapd#3805: 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>
[12:26] <zyga-suse> er. make that 3804
[12:29] <willdeberry> zyga-suse: just an fyi, this is what is currently failing and I will address before reach back out https://pastebin.com/8BdemMUD
[12:29] <zyga-suse> jdstrand: reviewed both now, I think we have a major problem to solve before this can land
[12:30] <zyga-suse> willdeberry: yeah, just adjust those tests
[12:31] <pstolowski> zyga-suse, replied. take a look at one of the interfaces in #3120 to see how this is used (best to look at an interface that uses some attributes)
[12:32] <pstolowski> zyga-suse, i'll be avail in ~10 minutes if you want to discuss in HO
[12:32] <zyga-suse> pstolowski: not sure if my data plan will allow it :)
[12:32] <zyga-suse> pstolowski: replied
[12:32] <zyga-suse> I'll brew some fresh coffee and I'll return to my woes
[12:34]  * genii 's ears perk up for a moment at the mention of coffee
[12:34] <Chipaca> ogra_: do we support this guy? http://beagleboard.org/black-wireless
[12:35] <zyga-suse> mvo: interesting https://paste.gnome.org/pu8sxtwdg
[12:35] <mup> PR snapd#3761 closed: Disable reexec on debian <Created by mwhudson> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3761>
[12:36] <ogra_> Chipaca, well, the bbb image should boot and run but no idea about the changed network bits
[12:36] <zyga-suse> saw that when 2017-08-25 11:51:20 Error executing autopkgtest:ubuntu-17.10-amd64:tests/main/config-versions :  failed
[12:36] <zyga-suse> mwhudson: ^ maybe interested in this
[12:36] <zyga-suse> runtime: address space conflict: map(0xc420100000) = 0x7f377c677000
[12:36] <zyga-suse> fatal error: runtime: address space conflict
[12:37] <jdstrand> zyga-suse: thanks, I've commented in both 3804 and 3805
[12:37] <zyga-suse> jdstrand: thank you
[12:37] <zyga-suse> jdstrand: offtopic, the /var/lib/snapd/apparmor/snap-confine.d is harder than anticiapted
[12:37] <zyga-suse> jdstrand: is there a way for apparmor-parser to ignore missing directories somehow?
[12:38] <jdstrand> zyga-suse: not without code changes. I doubt they would be upstreamable
[12:39] <ogra_> Chipaca, i see we have /boot/uboot/linux-generic-bbb*/dtbs/am335x-boneblack-wireless.dtb  .... so might need an adjusted own gadget
[12:39] <ogra_> so yes, we can easily support it :)
[12:39] <jdstrand> zyga-suse: why is it difficult? I saw something about core. we create directories in core all the time...
[12:39] <Chipaca> ogra_: maybe i should get one and use it as my laptop at the sprint
[12:39] <zyga-suse> jdstrand: replied
[12:39] <zyga-suse> jdstrand: apparently not all the time
[12:40] <zyga-suse> jdstrand: I need to think but merely adding the directory to snapd.deb is not enough
[12:40] <zyga-suse> jdstrand: (replied https://github.com/snapcore/snapd/pull/3805#discussion_r135248529 in case you want to see)
[12:40] <mup> PR snapd#3805: 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>
[12:42] <jdstrand> zyga-suse: going back to 3805> in a strict or devmode snap on core, the shadow gid matches (fine). on classic, /etc is one of the directories we bind mount from the host into the mount namespace. *not* /etc from core. therefore, the /etc/shadow in the mount namespace is /etc/shadow from the host
[12:42] <jdstrand> zyga-suse: are you saying something changed in this regard?
[12:42] <zyga-suse> jdstrand: ah, you are right
[12:42] <zyga-suse> jdstrand: but files from core snap will be owned by 42, not by 15
[12:43] <zyga-suse> jdstrand: this is a separate issue
[12:43] <jdstrand> zyga-suse: so?
[12:43] <zyga-suse> jdstrand: but still true
[12:43] <jdstrand> the snap never sees them
[12:43] <zyga-suse> jdstrand: shadow is maybe not the best example, I bet there are users/groups that _can_ be seen that don't match host's /etc/
[12:43] <jdstrand> the snap with account-control plugged will only modify the host. it can't get to the core snap
[12:43] <jdstrand> zyga-suse: no
[12:44] <jdstrand> zyga-suse: the have the same databases
[12:44] <jdstrand> they*
[12:44] <jdstrand> because we intentionally bind mount so it is that way
[12:44] <zyga-suse> jdstrand: my point is that the core snap has hardcoded values for each file
[12:44] <zyga-suse> jdstrand: right in the squashfs
[12:44] <jdstrand> zyga-suse: again, so?
[12:44] <jdstrand> we bind mount over them
[12:44] <zyga-suse> jdstrand: and any disagreements with the host will be confusing
[12:44] <jdstrand> it doesn't matter
[12:45] <jdstrand> this is precisely why we bind mount
[12:45] <zyga-suse> jdstrand: are all non-root files in the core hidden?
[12:45] <jdstrand> so they are the same. no disagreements
[12:45] <jdstrand> zyga-suse: of course not, but that is a different issue
[12:45] <zyga-suse> ok
[12:45] <jdstrand> zyga-suse: we aren't expsoing those files to the classic snap
[12:46] <zyga-suse> I agree about your reasoning on snap-seccomp now
[12:46] <jdstrand> certainly not for chown
[12:46] <jdstrand> since those files are readonly anyway
[12:47] <ikey> snaps are swiftly becoming a pain in my ass, just wanted to share that.
[12:48] <ikey> https://dev.solus-project.com/T4390
[12:48]  * zyga-suse looks
[12:48] <jdstrand> zyga-suse: this functionality isn't about weird esoteric permissions in the core snap vs classic. this is about 2 users and groups that are defined by the LSB to exist everywhere (root and daemon (daemon in a followup PR)) and shadow, which in practice exists everywhere (but we could adjust as needed (if NonCompliantDistro ; use othershadow)
[12:48] <zyga-suse> ikey: more classic snaps :/
[12:49] <jdstrand> zyga-suse: after that it is all about snapd-managed users
[12:49] <ikey> "Yay"
[12:49] <zyga-suse> ikey: we need a way to pester snap makers and improve snapcraft
[12:49] <jdstrand> I'll mention that in 3804
[12:49] <ikey> ya because id been down this ABI path with Ubuntu before
[12:49] <ikey> it's called Steam.
[12:49] <ikey> and frankly it aint worth it
[12:49] <jdstrand> actually, there is the calling user too
[12:50] <zyga-suse> jdstrand: calling user?
[12:50] <jdstrand> sudo foo, we may want to allow dropping to 1000
[12:51] <jdstrand> I need to think about that one
[12:51] <jdstrand> may not allow that. again, I'll think about it
[12:52] <jdstrand> that might be a straight snap-confine (not snap-seccomp) change
[12:52]  * zyga-suse really breaks now and goes to make that coffee
[12:52] <jdstrand> oh, we don't need Lookup and LookupGroup for that anyway
[12:53]  * genii hears something about coffee again, goes and gets one
[12:56] <ogra_> ikey, "snap run --shell atom" ... then grep LD_LIBRARY_PATH from the env ... i bet it doesnt prefix it correctly with the in-snap lib paths
[12:58] <zyga-suse> ogra_: that's not sufficient to test
[12:59] <zyga-suse> ogra_: the wrapper may set that
[12:59] <zyga-suse> ogra_: and --shell will not run it
[12:59] <ogra_> zyga-suse, and thats fine
[12:59] <ogra_> oh
[12:59] <ogra_> i didnt know that
[12:59] <zyga-suse> ogra_: it's still a bug in the snap
[12:59] <ogra_> yes
[12:59] <ogra_> well
[12:59] <ogra_> https://forum.snapcraft.io/t/libraries-not-found-in-classic-snaps/1033
[13:00] <ogra_> zyga-suse, i consider is a snapd/snap-confine bug TBH
[13:00] <zyga-suse> ogra_: I don't
[13:00] <zyga-suse> ogra_: I gave my reasoning why this cannot be set in snap-confine
[13:00] <ogra_> the env should be properly prefixed without needing a wrapper
[13:01] <ogra_> ikey, so close that bug and make them complain to the snap creator ;)
[13:07] <ogra_> flexiondotorg, /snap/atom/current/bin/electron-launch is missing paths for $SNAP/lib and $SNAP/lib/$TRIPLET ...
[13:07] <ogra_> (iirc atom was your snap)
[13:07] <ogra_> ikey, ^^^
[13:07] <ogra_> (it only defines $SNAP/usr/lib ... )
[13:10] <jdstrand> zyga-suse: fyi, https://github.com/snapcore/snapd/pull/3804#discussion_r135254236
[13:10] <mup> PR snapd#3804: cmd/snap-seccomp: support parsing 'u:' and 'g:' for username and groups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3804>
[13:16] <Son_Goku> zyga-suse, I think at some point we need a way to deal with the lack of extrausers outside of Ubuntu
[13:16] <zyga-suse> Son_Goku: aha, is that breaking in the field somehow?
[13:16] <zyga-suse> I thought that was used in the core only
[13:17] <jdstrand> mvo: regarding 'restore' in the wayland spread test, that is what I initially tried (see the comment in the test: "# If this is in 'restore', it hangs the test")
[13:17] <Son_Goku> well, weird things are happening already because snaps like docker snap don't work right without bounding back and forth
[13:17] <ogra_> flexiondotorg, https://github.com/snapcrafters/atom/pull/3 for you
[13:17] <mup> PR snapcrafters/atom#3: add $SNAP/lib, $SNAP/lib/$TRIPLET to library path <Created by ogra1> <https://github.com/snapcrafters/atom/pull/3>
[13:19] <zyga-suse> snapcraft should offer easy-to-use knobs for snaps using classic confinement *and* binary packages and don't expect to run host programs
[13:19] <zyga-suse> and should set LD_LIBRARY_PATH
[13:19] <zyga-suse> sergiusens: ^^
[13:19] <jdstrand> mvo: I think this has to do with backgrounding the daemon with '&'. execute would never return and the test would have to timeout before getting to restore
[13:19] <sergiusens> zyga-suse: no, the correct path is to compile
[13:19] <zyga-suse> I know
[13:19] <zyga-suse> but people shoot themselves in the foot repeatedly
[13:20] <zyga-suse> so let's add some aribags
[13:20] <sergiusens> if we set LD_LIBARARY_PATH we taint the environment by default
[13:20] <zyga-suse> *airbags
[13:20] <zyga-suse> I wouldn't set it by default
[13:20] <zyga-suse> but I would add a knob for classic confinement snaps
[13:20] <zyga-suse> and warn people if they didn't make any decision about it
[13:20] <sergiusens> if you do classic, you need to compile your runtime, period
[13:20] <jdstrand> mvo: now, I can try to use something like start-stop-daemon, but I didn't go that route because it isn't going to exist outside of Debian derived distros
[13:20] <jdstrand> mvo: granted, the test itself is only running on Ubuntu, but figured for futureproofing, did it this way
[13:21] <zyga-suse> sergiusens: should store reject snaps that dont?
[13:21] <jdstrand> mvo: but, what I could do is also have it in restore
[13:21] <sergiusens> zyga-suse: we shouldn't block people that know what they are doing
[13:21] <zyga-suse> sergiusens: yes but apparently people don't know
[13:21] <jdstrand> mvo: ok, let me do that
[13:21] <jdstrand> mvo: thanks for the chat :)
[13:21] <sergiusens> setting LD_LIBRARY_PATH is valid for some snaps that would never shell out
[13:22] <sergiusens> look at all the trouble I went through to get snapcraft to be classic. It is a lot more work, there are beneifts, but all these apps need to use a compiled electron and not the default build
[13:25] <zyga-suse> jdstrand: can you please look at and +1 https://github.com/snapcore/snapd/pull/3808 (you looked at the patches already)
[13:25] <mup> PR snapd#3808: apparmor,release: add better apparmor detection/mocking code <Created by zyga> <https://github.com/snapcore/snapd/pull/3808>
[13:26] <ogra_> sergiusens, how does compiled vs non-compiled have any effect here ?
[13:26] <ogra_> sergiusens, $SNAP/lib is simply not in LD_LIBRARY_PATH so shipped libs are not found ... that has nothing to do with the electron binary at all
[13:27] <mvo> jdstrand: hey, sorry, was in the standup
[13:27] <mvo> jdstrand: but it seems like you solved everything :)
[13:28] <sergiusens> ogra_: RPATH would be set for the binary
[13:29] <sergiusens> the whole concept of classic confined snaps is that you fix the linker and what libraries can load (and disabling LD_LIBRARY_PATH)
[13:29] <ogra_> is it ? ... it doesnt compllain about missing $SNAP/usr/lib
[13:29] <ogra_> (about files from there)
[13:29] <sergiusens> huh?
[13:30] <ogra_> only about the lib path that is missig from the launch wrapper
[13:30]  * sergiusens needs more words to make sense of that sentence
[13:30] <ogra_> sergiusens, https://github.com/snapcrafters/atom/pull/3
[13:30] <mup> PR snapcrafters/atom#3: add $SNAP/lib, $SNAP/lib/$TRIPLET to library path <Created by ogra1> <https://github.com/snapcrafters/atom/pull/3>
[13:31] <sergiusens> when we introduced classic we said it was supposed to be used by people who compile from source; we never made a promise about anything else
[13:31] <jdstrand> zyga-suse: sure
[13:31] <ogra_> sergiusens, starting the snap on a non-16.04 system simply fails because it doesnt find libs from $SNAP/lib
[13:31] <sergiusens> because atom (through electron) is not compiled in snapcraft
[13:31] <ogra_> sergiusens, nothing complains about any libs from $SNAP/usr/lib (which is inn LD_LIBRARY_PATH already
[13:31] <sergiusens> yes there are workarounds
[13:31] <ogra_> right
[13:31] <sergiusens> like LD_LIBRARY_PATH
[13:31] <ogra_> so we should have a "classic-wrapper" part ...
[13:31] <sergiusens> but, if you shell out, you get those libs picked first intead of those on the host
[13:32] <ogra_> that simply ships such a wrapper
[13:32] <ogra_> yes, thats what you want
[13:32] <sergiusens> no, no wrappers for classic was what we discussed in the forum months ago
[13:32] <ogra_> you never want to ever use any libs from the host
[13:32] <sergiusens> yes you do!
[13:32] <sergiusens> e.g.; asciinema
[13:32] <ogra_> then hell breaks loose
[13:32] <ogra_> you want to be able to **fall back* to them
[13:33] <sergiusens> e.g.; integrated shell in vscode (you want to use the python and pip on the system)
[13:33] <ogra_> but if you ship any lib in your snap you want that one to be used and preferred
[13:33] <sergiusens> test runner tools
[13:33] <sergiusens> anything useful, you want from the host
[13:33] <ogra_> yes, you want to carefully pick what you ship inside
[13:33] <sergiusens> for the application, yes, but not for what you invoke outside of the system
[13:33] <ogra_> but still
[13:33] <sergiusens> the only sane thing here is rpath
[13:33] <sergiusens> everything else is broken
[13:33] <ogra_> *if* you ship it it needs to be the preferred lib
[13:34] <sergiusens> and you are on your own should you choose to go down that path
[13:34] <ogra_> else classic will never function anywhere but 16.04
[13:34] <sergiusens> ogra_: compile and it works
[13:34]  * sergiusens is not discussing this anymore, seems to come back every two months
[13:35] <ogra_> well, wrap and it works too :P
[13:35] <sergiusens> half works
[13:35] <sergiusens> just wrappers and it doesn't work on trusty, try the asciinema in the store there and try to run something python and subsequently upload the video ;-)
[13:36]  * sergiusens reboots
[13:43] <ogra_> Chipaca, " ps eww of the toplevel process" ... is that Xorg ? gdm/lightdm ? systemd --user ? or bash ?
[13:43]  * ogra_ bets on the latter
[13:55]  * zyga-suse breaks for an hour
[14:05] <mvo> does anyone know if there is a way to skip an entire suite with gopkg.in/check.v1 ?
[14:05] <mvo> I mean, in SetupSuite(c *C) skip everything if e.g. a required binary is not available
[14:06] <pedronis> mvo: I think c.Skip in the SetUpSuite does that
[14:06] <pedronis> we even use it already I think
[14:06] <pedronis> mvo: see for example  asserts/gpgkeypairmgr_test.g
[14:07] <pedronis> o
[14:07] <mvo> pedronis: aha, it will still run teardownsuite, this is what confused me
[14:07] <mvo> pedronis: thanks!
[14:08] <Chipaca> ogra_: not bash
[14:08] <Chipaca> ogra_: ps fx, look for the topmost thing in the session (here it's upstart)
[14:08] <Chipaca> ogra_: for jwm it was jwm itself
[14:12] <jdstrand> mvo: ok, comments addressed in https://github.com/snapcore/snapd/pull/3759
[14:12] <mup> PR snapd#3759: add spread test for wayland <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3759>
[14:13] <Chipaca> ogra_: any ideas on how to find a case where it doesn't work?
[14:13] <ogra_> Chipaca, to exec ps you need a shell ... and even /dash reads profile
[14:14] <Chipaca> ogra_: yes, but i'm looking at the environment of a different process
[14:18] <ogra_> Chipaca, dunno if there is some gtk test app that prints the env ... i guess that'd be a question for the desktop team ...
[14:20] <mvo> jdstrand: thanks! approved, but one more nitpick/question related to the source of test-snapd-wayland
[14:27] <ogra_> flexiondotorg, seems the build badge markdown in README.md for atom points to https://build.snapcraft.io/user/snapcrafters/discord ... i guess you want to fix that to point to https://build.snapcraft.io/user/snapcrafters/atom
[14:28] <flexiondotorg> ogra_ ty Mr. popey is on it.
[14:28] <ogra_> heh, ok
[14:31] <ogra_> bah, it is odd that a change to README.md causes a rebuild of the snap ...
[14:31] <ogra_> we should have something like .snapbuild-ignore so that build.snapcraft.io doesnt pick up such changes
[14:34] <Chipaca> ogra_: well... if I were to build stuff using snapcraft in a repo, I'd use chunks of my README in the snap's description
[14:36] <ogra_> Chipaca, yeah, if you do that you want README changes to be used ...
[14:36] <ogra_> https://forum.snapcraft.io/t/build-snapcraft-io-should-not-always-rebuild/1850/1 ...
[14:36] <ogra_> but a .snapignore file could make that flexible
[14:38] <Chipaca> man, my xbill snap doesn't have a .desktop file
[14:38] <ogra_> heh
[14:38] <Chipaca> i need to fix this post haste
[14:38] <ogra_> complain at microsoft :P
[14:39] <Chipaca> worse, i don't know where i built it
[14:41] <ogra_> ikey, if you feel like you can tell your users to "snap refresh atom --edge" to test the fix ;) (and to show off how quick snaps can be fixed ;) )
[14:43]  * ogra_ hugs ikey ... the IRC-> bugtracker bot :)
[14:43] <ikey> lol
[14:46] <kyrofa> mcphail, oh definitely, v12 is quite simply not a good experience in the snap right now, which is why we haven't updated stable. Take a look at https://github.com/nextcloud/nextcloud-snap/pull/334
[14:46] <mup> PR nextcloud/nextcloud-snap#334: nextcloud: update to v12.0.1 <Created by pachulo> <https://github.com/nextcloud/nextcloud-snap/pull/334>
[14:48] <ogra_> pfft ... icons ... who needs them anyway :P
[14:53] <jdstrand> mvo: https://github.com/snapcore/snapd/pull/3759#discussion_r135275936
[14:53] <mup> PR snapd#3759: add spread test for wayland <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3759>
[14:59] <mcphail> kyrofa: thanks!
[15:01] <mvo> zyga-suse: some ideas for 3808, sorry that its a bit long, happy to discuss more if you want
[15:07] <kyrofa> zyga-suse, this is for you: https://bugs.launchpad.net/snapd/+bug/1712930
[15:07] <mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:New> <https://launchpad.net/bugs/1712930>
[15:08] <ogra_> just hold it upside down
[15:12] <mvo> pstolowski: the error in 3642 looks real, there is a unit test failure in transaction_test.go:168 - could you please have a look?
[15:12] <niemeyer> o/
[15:13] <pstolowski> mvo, sure
[15:13] <niemeyer> Will get a quick lunch and be here shortly
[15:13]  * Pharaoh_Atem sighs
[15:13] <Chipaca> xbill-xaw now has a desktop file, and it works and is light enough i can ask people to test stuff with it :-D
[15:14]  * Chipaca tries in his fedora with wayland, first
[15:14]  * Chipaca braces for thrashing
[15:17] <zyga-suse> re
[15:17] <zyga-suse> mvo: thank you, will look at 3808
[15:18] <mvo> jdstrand: 3759 looks ready, I will merge when tests are green
[15:18] <zyga-suse> kyrofa: looking, interesting from the title alone
[15:19] <Chipaca> ogra_: hah! dang, i just wasted some time. the rest of the world is _already_ doing this stuff from profile.d
[15:21] <jdstrand> mvo: thanks! :)
[15:22] <zyga-suse> mvo: nice, I'll iterate after dinner
[15:22] <zyga-suse> kyrofa: hey, have you tried 2.27?
[15:22] <zyga-suse> kyrofa: I'm pretty sure we handle / which isn't MS_SHARED up front
[15:23] <zyga-suse> kyrofa: reading the rest of the analysis now
[15:23] <kyrofa> zyga-suse, no, just latest stable. Happy to try though-- which channel?
[15:23] <zyga-suse> kyrofa: not sure if channels work now
[15:23] <zyga-suse> kyrofa: our release-breaks-edge process
[15:24] <zyga-suse> kyrofa: maybe proposed 2.27.4 would be nice
[15:24] <zyga-suse> but maybe not
[15:24] <zyga-suse> let me finish reading stgraber's analysis
[15:25] <zyga-suse> hmm, forum logged me out
[15:25] <zyga-suse> and ff doesn't know my password, what?
[15:25] <zyga-suse> ah
[15:25] <zyga-suse> this is not forum.snapcraft.io
[15:28] <ogra_> Chipaca, well, debian and ubuntu arent unless that changed recently
[15:29] <Chipaca> ogra_: correct
[15:29] <Chipaca> ogra_: but, it works
[15:29] <ogra_> well, good then :)
[15:29]  * ogra_ is afk for a bit
[15:30] <mup> PR snapd#3372 opened: tests: add basic lxd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3372>
[15:30]  * zyga-suse was a the sauna
[15:30] <zyga-suse> I should have been doing that all this week
[15:30] <zyga-suse> sergiusens_: saunas are fun
[15:30] <mvo> fgimenez: do you happen to know if the "nightly" suite of snapd is run currently? if so, is that part of spread-cron?
[15:34] <fgimenez> mvo: yes, according to https://travis-ci.org/snapcore/spread-cron/branches it was executed last night (the branch is called "snapd-nightly-suite")
[15:34] <fgimenez> mvo: this is the job executed currently https://github.com/snapcore/spread-cron/blob/snapd-nightly-suite/run-checks
[15:35] <mvo> fgimenez: great, thank you!
[15:35]  * Chipaca ~> walk
[15:36] <fgimenez> mvo: np :) i see that the unity test is still around, maybe better removing it completely and execute the whole nightly suite, that way it would be easier to add new tests there
[15:36] <Chipaca> jdstrand: we don't yet support running ia32 binaries on amd64, right?
[15:36] <mvo> pedronis: is the night extra-snap-assertions your baby? it looks its unhappy currently https://travis-ci.org/snapcore/spread-cron/builds/268207725#L715
[15:36] <mvo> fgimenez: +1 for removing that
[15:36] <pedronis> mvo: I don't even know what it is
[15:37] <mvo> fgimenez: I'm mostly interessted in this because of lxd, docker which are a bit heavy for the normal runs
[15:37] <mvo> pedronis: no worries, I have a look
[15:37] <zyga-suse> Chipaca: we do
[15:37] <Chipaca> ah! good :-D
[15:37] <Chipaca> now yes, /me -> walk
[15:37] <pedronis> mvo: doesn't mean I wasn't involved but  I don't remember
[15:38] <fgimenez> mvo: pedronis i added it, it checks for the feature of using extra-snaps with assertions to ubuntu-image
[15:39] <mvo> pedronis: your name does not come up in git blame, so I guess your memory is fine
[15:42] <pedronis> ConfigManager is weird, is not actually a StateManager :/
[15:50] <zyga-suse> I think it's only that because it handled hooks
[15:58] <jdstrand> roadmr: I noticed r922 is live. thanks!
[15:59] <jdstrand> stgraber: fyi, feel free to use reload-command
[15:59] <roadmr> jdstrand: oh yay! true, there was a deploy this morning
[16:00] <stgraber> jdstrand: yay!
[16:02] <sergiusens> zyga-suse: they are indeed
[16:03] <zyga-suse> sergiusens: your mainline kernel will soon-ish work
[16:14] <jdstrand> Chipaca: ia32 on amd64, do you mean i386 on amd64/x86 on x86_64? if so, snapd supports this. snapcraft (I don't think yet) makes that easy
[16:14] <zyga-suse> kyrofa: interesting, I'll need to ponder on this some more
[16:14] <zyga-suse> jdstrand: interesting bug there btw,
[16:14]  * jdstrand wanted to make sure you weren't talking about x32
[16:15] <jdstrand> I phrased the snapcraft bit weird. I don't think snapcraft helps at all there
[16:15] <mup> PR snapd#3793 closed: cmd: "make hack" now also installs snap-update-ns <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3793>
[16:15] <jdstrand> but I did this work a long time ago (now) for popey's use case of wine on amd64 being able to run 32 bit binaries
[16:16] <niemeyer> Hellos
[16:16] <jdstrand> and all that carried forward into recent snap-seccomp, etc
[16:16] <jdstrand> hey niemeyer :)
[16:16] <niemeyer> How're things going today?  Anything urgent to look after, or can I jump into the review board and reviews?
[16:23] <jdstrand> niemeyer: I've not seen anything scary in backscroll, but I'll defer to others
[16:24] <jdstrand> Chipaca: sudo snap install test-seccomp-compat --edge
[16:24] <jdstrand> Chipaca: test-seccomp-compat.true32
[16:24] <jdstrand> Chipaca: test-seccomp-compat.true64
[16:25] <jdstrand> Chipaca: oh, I forgot, cmd/snap-confine/spread-tests/main/test-seccomp-compat/task.yaml :)
[16:25] <zyga-suse> niemeyer: hey
[16:25] <zyga-suse> niemeyer: how are you doing?
[16:25] <zyga-suse> niemeyer: I think we're good
[16:25] <zyga-suse> jdstrand: nice snap!!!
[16:26] <niemeyer> jdstrand, zyga-suse: Sweet
[16:26] <jdstrand> zyga-suse: thanks :)
[16:26] <jdstrand> zyga-suse: the bug you mentioned earlier-- you meant snapcraft making it easy for compat archs?
[16:26] <zyga-suse> no, I mean the bug where snap-confine and / and MS_RSHARED and containers blow up
[16:26] <zyga-suse> https://bugs.launchpad.net/snapd/+bug/1712930
[16:27] <mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:In Progress by zyga> <https://launchpad.net/bugs/1712930>
[16:27] <zyga-suse> real stuff is on https://discuss.linuxcontainers.org/t/snapd-cant-remove-old-revisions-when-running-inside-lxd/452/3
[16:27] <jdstrand> ah, I didn't see that one yet
[16:27]  * zyga-suse loves this moment of the day
[16:27] <zyga-suse> sun is visible because it is below clouds
[16:27] <zyga-suse> and shines through moving trees
[16:28] <jdstrand> zyga-suse: sounds nice :)
[16:29] <jdstrand> we're looking forward to a bunch of thunderstorms this evening
[16:29] <zyga-suse> https://twitter.com/zygoon/status/901119350870036481
[16:49] <mup> PR snapd#3811 opened: interfaces/i2c: adjust sysfs rule for alternate paths <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3811>
[16:52] <jdstrand> zyga-suse: pretty :)
[17:01] <mup> PR snapcraft#1507 opened: many: simplify plugin loading <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1507>
[17:05] <niemeyer> mvo: snapd#3260 seems good to go for next week
[17:05] <mup> PR snapd#3260: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <https://github.com/snapcore/snapd/pull/3260>
[17:12] <willdeberry> finally got it showing! :) `:bluez`
[17:12] <willdeberry> thanks zyga-suse
[17:15] <Pharaoh_Atem> zyga-suse: I wish it was good day here
[17:15] <Pharaoh_Atem> I'm stuck inside an office working on backporting crap to old stuff :(
[17:15] <Pharaoh_Atem> I can't even see the sun from where I am :(
[17:37] <jdstrand> willdeberry: nice!
[17:39] <Chipaca> niemeyer: how can I edit somebody else's post in the forum?
[17:40] <Chipaca> wanting to indent a chunk of stuff so it'll be formatted properly
[17:43]  * Chipaca hugs Pharaoh_Atem 
[17:43] <Chipaca> Pharaoh_Atem: not long to go now
[17:45]  * Chipaca wonders why he's doing tech support in the forum
[17:46]  * Chipaca realises the distance between "snapd doesn't work" and "my system doesn't work" is invisible to users \o/
[17:50] <Pharaoh_Atem> FINALLY
[17:50] <Pharaoh_Atem> we're going to have the xdg-open replacement?
[17:51] <willdeberry> jdstrand: :) . I will be cleaning up and then sending over a PR sometime today for it
[17:51] <willdeberry> i did have to resort to build the deb and installing. doesn't seem like building snapd was enough
[17:53] <niemeyer> Chipaca: Hm
[17:53] <niemeyer> Chipaca: Not sure if you can while being a moderator
[17:54] <Chipaca> eh, never mind
[17:54] <niemeyer> Chipaca: ?
[17:54] <Chipaca> niemeyer: if it was easy and obvious, sure, but it's not important
[17:55] <niemeyer> If moderators can, then it's easy and obvious to give you that flag
[17:55] <Chipaca> ah!
[17:55] <Chipaca> niemeyer: i misread your "not sure if you can while being a moderator" as "afaik being a moderator you can't"
[17:56] <niemeyer> Ah, sorry.. it was more like "AFAIK I have no idea"
[17:57] <niemeyer> Chipaca: See if you can now
[17:57] <Chipaca> I do have a pencil now
[17:57] <niemeyer> Bingo
[17:57] <niemeyer> Chipaca: Be careful when tagging now.. you won't be constrained to our standard targs
[17:57] <niemeyer> targs is great
[17:58] <niemeyer> Wow.. it's even nicer than I expected.. "Targ or TARG may refer to: The Anti-Gravity Room"
[17:59] <Chipaca> mbuahaha
[17:59]  * Chipaca tags all the things
[17:59] <Chipaca> niemeyer: if you want you can bump me down again :-)
[17:59] <jdstrand> willdeberry: re building the deb-- that's definitely going to be more robust. glad that worked for you
[18:00] <niemeyer> Chipaca: Will keep you up.. hopefully you can actually help on the moderation :)
[18:00] <Chipaca> niemeyer: with great power come great tee shirts, right?
[18:00] <niemeyer> (unlike zyga, which after a few days had half a dozen random tags, posts painted yellow, etc /o\)
[18:00] <niemeyer> :P
[18:02] <niemeyer> jdstrand: Do you have a moment to quickly cover the desktop interface PR?
[18:03] <jdstrand> niemeyer: yeah
[18:03] <niemeyer> jdstrand: Ok.. so the thing I'm trying to figure after the extensive conversation we had there is whether we're still solving a problem worth solving for the price of the added complexity
[18:04] <niemeyer> jdstrand: I miss some technical pieces, so would like to talk live about it.. can we have a quick hangout?
[18:04] <jdstrand> ok
[18:06] <jdstrand> niemeyer: where?
[18:06] <Pharaoh_Atem> mvo: it feels weird to see mvo@ubuntu.com in the fedora changelogs: https://koji.fedoraproject.org/koji/buildinfo?buildID=956399 :D
[18:06] <niemeyer> jdstrand: hangouts.google.com/hangouts/_/canonical.com/desktop-interface?authuser=0
[18:07] <Pharaoh_Atem> mvo: but it seems people appreciate the fuller changelogs, so we'll keep rolling with it
[18:07] <jdstrand> sigh, the camera stopped
[18:07] <jdstrand> gimma a sec
[19:03] <Dee__> Hey all! Dee here, New to using Snaps
[19:10] <kyrofa> Hey Dee__, welcome
[19:22] <niemeyer> Bye Dee :)
[19:23] <genii> heh
[19:30] <kyrofa> I guess I wasn't the person to whom Dee wanted to talk
[20:18] <mvo> Pharaoh_Atem: heh, I can offer more addresses if you want :)
[20:19] <mvo> niemeyer: re 3260> yeah, I'm quite happy with it now after the last refactor and added tests
[20:20] <mvo> Pharaoh_Atem: I will also fix your point in 3260
[20:28] <mvo> Pharaoh_Atem: I reverted the snapd.spec file changes as you requested, will check tomorrow if tests are still happy. thanks for the review!
[21:13] <willdeberry> one last thing i am still dealing with is the randomness of error: `/snap/bjarkan/52/usr/bin/python3: 1: /snap/bjarkan/52/usr/bin/python3: Syntax error: word unexpected (expecting ")")`
[21:13] <willdeberry> i can rebuild on snapcraft.io and the next build will not have any issues
[21:13] <willdeberry> not sure what is causing this
[21:14] <willdeberry> makes me wonder if there is a bug in the python plugin for building
[21:20] <kyrofa> Hey niemeyer, can we get your thoughts on this? https://bugs.launchpad.net/snapcraft/+bug/1712061
[21:20] <mup> Bug #1712061: snapcraft restricts version field too much <Snapcraft:New> <https://launchpad.net/bugs/1712061>
[21:31] <mup> PR snapcraft#1508 opened: schema: version should have a max length of 32 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1508>
[21:49] <niemeyer> kyrofa: Sure, will look in a moment
[22:05] <mup> PR snapcraft#1507 closed: many: simplify plugin loading <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1507>
[23:35] <mup> PR snapcraft#1509 opened: project_loader: process stage package grammar <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1509>
[23:47] <niemeyer> kyrofa: Done
[23:48] <kyrofa> Thanks niemeyer. Why are you still here?!
[23:49] <niemeyer> kyrofa: My day started a bit late today.. kid was a bit under the weather last night and I went to sleep when I supposed to be waking up.. so it all shifted forward a bit
[23:49] <kyrofa> Ah, poor kid. We just finished a round of the stomach flu, I know how you feel
[23:50] <niemeyer> Yeah.. wonders of being in a school with other children
[23:50] <niemeyer> I guess that's how they improve their immune system
[23:50] <niemeyer> (and ours :P)_
[23:55] <kyrofa> No kidding