[07:00] <janisozaur> hi
[07:01] <janisozaur> has anyone been successful in establishing opengl context from a snap on Arch Linux?
[07:01] <janisozaur> yesterday I tried and nothing really worked, not even glxinfo
[07:02] <janisozaur> it either crashed (on a host with nvidia + binary drivers) or reported an error (host with Intel GPU)
[07:02] <janisozaur> the very same snap worked, however, in a ubuntu artful VM
[07:05] <janisozaur> I tried specifying LIBGL_DRIVERS_PATH to the correct ($SNAP/usr/lib/x86_64-linux-gnu/dri) directory, but that didn't help
[07:17] <janisozaur> has anyone been able to run e.g. glxgears on Arch? How can I help debug?
[07:35] <janisozaur> hmm, perhaps my Arch system did not offer OpenGL slot properly?
[08:10] <Chipaca> janisozaur: I think the guy that knows (or remembers) most about that is zyga
[08:10] <Chipaca> s/guy/person/
[08:11] <janisozaur> yeah, i saw his comments on issue trackers
[08:12] <janisozaur> can he be met round these parts?
[08:13] <zyga-ubuntu> re!
[08:13] <zyga-ubuntu> man, I thought it is Saturday
[08:13] <janisozaur> hi zyga-ubuntu
[08:13] <zyga-ubuntu> hey
[08:14] <janisozaur> I'm having issues running opengl snaps on my Arch systems
[08:14] <zyga-ubuntu> using nvidia proprietary drivers or anything else?
[08:15] <janisozaur> one machine with Intel reports errors in glxinfo, the other with nvidia just segfaults
[08:15] <zyga-ubuntu> can you please describe this in detail on forum.snapcraft.io
[08:15] <zyga-ubuntu> the nvidia issue is probably more well known
[08:15] <zyga-ubuntu> the intel issue new to me
[08:15] <janisozaur> I'm not around these machines right now, but I'm available for debugging in the evening
[08:15] <zyga-ubuntu> there are some people working on improving opengl snap support (alberto) but it's not even a PR yet
[08:16] <zyga-ubuntu> janisozaur: if you can stick around for some time (days) and help us understand the issue I'll make sure the solution is working and tested on arch
[08:16] <zyga-ubuntu> unfortunately many opengl problems are hard to test for us (lots of distros and virtualization complexity)
[08:16] <zyga-ubuntu> also the design we have now is pretty old and we learned about some of the issues
[08:17] <zyga-ubuntu> so we really need people with hands-on access to the given distribution and hardware
[08:17] <zyga-ubuntu> your help can be really invaluable to us
[08:17] <janisozaur> sure, i'll try helping with that
[08:18] <janisozaur> is there any debugging FAQ for snaps?
[08:18] <janisozaur> I only started using them yesterday
[08:18] <zyga-ubuntu> some but some issues are more complex than others
[08:18] <zyga-ubuntu> as a few hints:
[08:19] <zyga-ubuntu> you can look at the output of snapd systemd unit
[08:19] <zyga-ubuntu> (journalctl -u snapd)
[08:19] <zyga-ubuntu> that tells a lot about what is going on in the background
[08:19] <zyga-ubuntu> you can also set SNAP_CONFINE_DEBUG=yes to see what's going on at application startup
[08:19] <zyga-ubuntu> lastly snap version is the key thing many people will ask about
[08:19] <zyga-ubuntu> the arch maintainer is, I believe, not updating the package lately,
[08:20] <zyga-ubuntu> we don't have automatic regression tests for arch yet so we don't know if it's working really
[08:20] <zyga-ubuntu> if you want to help in any of that it's all something I can guide you with
[08:20] <zyga-ubuntu> we have automatic regression tests for debian, ubuntu, fedora and opensuse now
[08:20] <zyga-ubuntu> and arch is not far away
[08:20] <janisozaur> sounds like something i could maybe look into
[08:20] <zyga-ubuntu> btw, what is the current version of snapd on arch?
[08:21] <zyga-ubuntu> I have an arch VM and I can dual-boot on one of my laptops
[08:21] <zyga-ubuntu> and I was working on small updates to the package
[08:21] <janisozaur> the snap i was creating worked fine in ubuntu artful VM
[08:21] <zyga-ubuntu> now with 2.26.14 released and upcoming 2.27 I think it would make sense to update everything
[08:21] <janisozaur> it probably was using swrast, though
[08:21] <zyga-ubuntu> yes, I suspect so
[08:21] <janisozaur> https://www.archlinux.org/packages/community/x86_64/snapd/
[08:22] <janisozaur> 2.26.1
[08:22] <zyga-ubuntu> not too far off
[08:22] <zyga-ubuntu> but the package can use some love
[08:22] <zyga-ubuntu> as we added some new features lately
[08:22] <zyga-ubuntu> and last time I looked they were not supported in arch yet
[08:22] <zyga-ubuntu> how about this, let's talk later today or over weekend
[08:22] <zyga-ubuntu> let's start a thread in the forum
[08:22] <zyga-ubuntu> on arch package update
[08:22] <zyga-ubuntu> and on opengl
[08:23] <zyga-ubuntu> I'll let you start the one on opengl and I'll quickly start the one on arch package update
[08:23] <zyga-ubuntu> and we can discuss there
[08:23] <zyga-ubuntu> the forum is really nice, works paritally like a mailing list and partially like IRC (being in real time) and it scales better than IRC (timezones/offline problems)
[08:23] <janisozaur> sure, i should be available at ~1730 CEST
[08:23] <zyga-ubuntu> how does that sound?
[08:23] <zyga-ubuntu> perfect
[08:24] <zyga-ubuntu> I should be available all day (I'm in europe too), just may be offline for some moments
[08:24] <janisozaur> great!
[08:28] <zyga-ubuntu> janisozaur: https://forum.snapcraft.io/t/updates-to-snapd-package-on-arch/1467
[08:28] <zyga-ubuntu> janisozaur: feel free to comment there!
[08:29] <zyga-ubuntu> note that I used the "snapd" category as this involves snapd itself
[08:29] <zyga-ubuntu> and "arch" tag (along with some other tags I use to organize my tasks)
[08:29] <zyga-ubuntu> so if you create a post about opengl you can also use the "arch" tag to group posts this way
[08:30] <jamesh> Is there any way to get the CI tests to rerun for my pull request?  I got a failure onlinode:ubuntu-14.04-64:tests/main/econnreset and it isn't clear how my changes could have caused that
[08:31] <zyga-ubuntu> jamesh: I think it's not your fault, I think that test is flaky
[08:31] <zyga-ubuntu> jamesh: but to answer your question, if you look for that id (ubuntu-14.04-64....) in the log you will see a *fold* that has the details of the error
[08:32] <zyga-ubuntu> jamesh: and just below it another fold that has lots of debug information
[08:32] <jamesh> zyga-ubuntu: right.  I read the CI log, and couldn't see how my changes impacted it
[08:32] <zyga-ubuntu> jamesh: I think though, as I said, that that test is racy and sometimes fails incorrectly
[08:32] <zyga-ubuntu> jamesh: if you re-run it it will likely pass
[08:33] <zyga-ubuntu> though today master feels broken (on autopkgtests) as something odd has regressed in one of the upgrade tests after the 2.26.14 stable release
[08:33] <zyga-ubuntu> I've been investigating that last night but no conclusions yet
[08:33] <jamesh> zyga-ubuntu: do I need to make a trivial commit to get it to rerun, or is there a button to trigger it again?
[08:33] <zyga-ubuntu> jamesh: what's the PR URL?
[08:33] <zyga-ubuntu> jamesh: you can re-trigger from the UI
[08:33] <Chipaca> jamesh: you don't have a "restart" at the top of the travis output?
[08:33] <jamesh> zyga-ubuntu: https://github.com/snapcore/snapd/pull/3581
[08:33] <mup> PR snapd#3581: Add polkit authorization support to /v2/login <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3581>
[08:33] <zyga-ubuntu> (or maybe you cannot but I can help)
[08:34] <zyga-ubuntu> jamesh: all tests passed there
[08:34] <Chipaca> um
[08:34] <Chipaca> yeah
[08:34] <jamesh> Chipaca: no.
[08:34] <Chipaca> jamesh: tests are all green
[08:35] <jamesh> doh.  Hadn't reloaded the page.
[08:35] <jamesh> so many other things seem to auto-update on github, but that didn't.
[08:36] <jamesh> sorry for the noise
[08:36] <Chipaca> jamesh: the auto-update breaks if the network hiccups, apparently
[08:37] <jamesh> Chipaca: I guess the restart button only shows up for core developers?
[08:37] <Chipaca> jamesh: maybe you need to log into travis?
[08:38] <jamesh> Chipaca: I am logged in
[08:38] <Chipaca> ah
[08:38] <Chipaca> then maybe
[08:38] <jamesh> It's not a big deal
[08:52]  * zyga-ubuntu hits the road, will be off IRC today often
[09:08] <zyga-ubuntu> Chipaca: hey
[09:08] <Chipaca> zyga-ubuntu: wut
[09:08] <Chipaca> zyga-ubuntu: hey :-)
[09:08] <zyga-ubuntu> Chipaca: I plan to spend the day 1/3 on reviews 1/3 on master regression and 1/3 on mvo's SPDX parser
[09:08] <zyga-ubuntu> do you need my help on anything?
[09:10] <Chipaca> zyga-ubuntu: how do you divide 8 hours into thirds
[09:10] <zyga-ubuntu> Chipaca: easy, just start with 12 hours
[09:10] <zyga-ubuntu> everything is easy to divide then D:
[09:10] <Chipaca> zyga-ubuntu: aw :-(
[09:11] <zyga-ubuntu> I like languages with rational numbers
[09:11] <Chipaca> zyga-ubuntu: the right answer is that it divides into 3 2-hour chunks, and a spanish lunch break
[09:11] <zyga-ubuntu> 8/3 is such a nice construct
[09:11] <Chipaca> zyga-ubuntu: other than a review, which is already on your list, i don't think i need anything
[09:12] <zyga-ubuntu> Chipaca: the logs PR? or something else as well?
[09:12] <Chipaca> zyga-ubuntu: sorry about my commit messages falling in quality. The first pass at this work I took the effort of doing them properly.
[09:12] <zyga-ubuntu> Chipaca: I know that's extreme but I really like LKLM style commits
[09:12] <Chipaca> the second pass i also did a fairly good job at keeping the commits tight and the messages clean
[09:13]  * Chipaca looks for a link to show he isn't making it up (maybe)
[09:14] <Chipaca> gah
[09:14] <Chipaca> i might've been making that up after all
[09:14] <Chipaca> https://github.com/snapcore/snapd/pull/3549/commits
[09:14] <mup> PR snapd#3549: many: expose services commands for snap services <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3549>
[09:16] <Chipaca> anyway
[09:16] <Chipaca> zyga-ubuntu: i'm aware of making them better, and I'll continue improving them
[09:16] <Chipaca> some days it's harder than others
[09:16] <zyga-ubuntu> Chipaca: thanks, that's all I ask for :)
[09:16] <mup> PR snapd#3631 closed: tests: apply underscore convention for SNAPMOUNTDIR variable <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3631>
[09:16] <Chipaca> :-)
[09:16] <zyga-ubuntu> Chipaca: I was just wondering if we can land "snap logs" today
[09:16] <zyga-ubuntu> that shiny green button there
[09:17] <Chipaca> zyga-ubuntu: just a simple matter of reviews and addressing issues found therein
[09:17] <zyga-ubuntu> I mean do we have enough +1 votes with mvo and gustavo being off
[09:18] <zyga-ubuntu> Chipaca: on that topic, I have one monster PR https://github.com/snapcore/snapd/pull/3619
[09:18] <mup> PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619>
[09:20] <Chipaca> ah yes
[09:21] <Chipaca> i was 3/8 through that the other day :-p
[09:24] <zyga-ubuntu> that's a monster PR, sorry
[09:24] <zyga-ubuntu> but you can go patch-by-patch
[09:25] <zyga-ubuntu> it's actually easier to follow this way
[09:25] <Chipaca> zyga-ubuntu: you mean commit-by-commit?
[09:26] <zyga-ubuntu> Chipaca: yes
[09:27] <Chipaca> zyga-ubuntu: you're aware it's 12 commits?
[09:28] <Chipaca> if I +1 a commit, is github smart enough or does it think I +1'd the PR?
[09:30] <zyga-ubuntu> Chipaca: GH doesn't support that (not gerrit) *but* you can open 12 tabs and just read one by one
[09:30] <zyga-ubuntu> and only give +1 if you found nothing wrong
[09:31] <Chipaca> yeah, doing that
[09:31] <zyga-ubuntu> but you can easily comment on each patch and GH handles that nicely
[09:31] <zyga-ubuntu> thanks, I'm reading logs now
[09:32] <Chipaca> zyga-ubuntu: is there a reason the repo itself doens't do the ensureSlotIfaceMatch(iface, slot) before calling SanitizeSlot?
[09:32] <zyga-ubuntu> Chipaca: yes, read on
[09:32] <Chipaca> ok
[09:32] <zyga-ubuntu> Chipaca: it's rolled into {plug,slot}.Sanitize
[09:33] <zyga-ubuntu> and also somewhat silly since repo does plug.Interface lookup
[09:33] <zyga-ubuntu> so it's a no-op test if the compiler is smart enough
[09:33] <pedronis> zyga-ubuntu: which btw reminds, checking if a slot is for a given snap types is also done by base declaration, so maybe is something else that can go away, but that I think you should discuss with jdstrand
[09:33] <zyga-ubuntu> pedronis: I think it's fine to keep as is, we don't check base declaration for sideloaded snaps, do we?
[09:34] <zyga-ubuntu> pedronis: and the check is really really small now, just two lines in all of the tree
[09:34] <pedronis> we don't indeed
[09:35] <zyga-ubuntu> pedronis: and I'm very happy I took your suggestion: so much code got removed
[09:35] <zyga-ubuntu> pedronis: vast majority of sanitize functions are out
[09:37] <zyga-ubuntu> I think pawel will be happy as there will be less things for him to edit
[09:38] <zyga-ubuntu> (really, going through 190 files to do one change is heart wrenching)
[09:39] <pedronis> zyga-ubuntu: why did you change the errors to say operating system ? instead of core ?
[09:39] <zyga-ubuntu> oh, not sure, I think I just unified it (it said various things)
[09:39] <pedronis> mmh
[09:39] <zyga-ubuntu> but we can now tweak it either way easily
[09:40] <pedronis> I think  we need to say either "core snap"  or operating system (without snap)
[09:40] <pedronis> but I fear that becomes a Gustavo's question
[09:40] <zyga-ubuntu> aha, indeed
[09:40] <zyga-ubuntu> I'm fine with core snap for now and I'll ask gustavo next week
[09:40] <Chipaca> zyga-ubuntu: +1'ed with a suggestion
[09:40] <zyga-ubuntu> I'll finish the review for chipaca and then I'll update
[09:41] <zyga-ubuntu> Chipaca: woot, thank you!
[09:41] <zyga-ubuntu> (that was fast!)
[09:41] <Chipaca> zyga-ubuntu: reading the commits indeed made it fast
[09:41] <Chipaca> a lot of it was repepepetititve
[09:41] <Chipaca> zyga-ubuntu: and i know logs would've been easier to read in (at least) three separate commits :-(
[09:42] <zyga-ubuntu> and all hand made, I tried to automate it but then just decided not to as the result wasn't perfect
[09:42] <Chipaca> zyga-ubuntu: what are the autopackage failures on your pr about?
[09:45] <pedronis> zyga-ubuntu: it's also interesting  that some had the comment "s allowed only by a gadget or os snap" but then allowed only os
[09:45] <pedronis> zyga-ubuntu: maybe it would be good to cross check with the base decl?
[09:46] <pedronis> actually there should be a way to write a generic test helper like that
[09:46] <pedronis> maybe
[09:47] <zyga-ubuntu> Chipaca: no idea, I'm checking that
[09:47] <zyga-ubuntu> something broke with hooks
[09:47] <zyga-ubuntu> not sure yet, I cannot reproduce, I plan to check if hook handler names changed lately
[09:48] <zyga-ubuntu> pedronis: yes, but I choose to keep the semantics of the code now, I think we can review who can do what
[09:48] <zyga-ubuntu> pedronis: good idea about cross checking with base declaration
[09:53] <pedronis> zyga-ubuntu: actually I alread had a test like that
[09:53] <pedronis> :)
[09:54] <pedronis> zyga-ubuntu:  func (s *baseDeclSuite) TestSlotInstallation logic about compareWithSanitize seems to do that
[09:54] <pedronis> or at leat a part of that
[09:54] <pedronis> now that I read better
[09:55] <pedronis> anyway seems something could be done there
[09:56] <pedronis> or based on that
[09:59] <pedronis> zyga-ubuntu: btw I just noticed that the various definer interfaces in the backends have the same problem Chipaca mentioned
[09:59] <zyga-ubu1tu> pedronis: aha, thank you, I will check it out
[10:00]  * zyga-ubu1tu looks at Chipaca's review
[10:00] <zyga-ubu1tu> pedronis: I started with public interfaces but Gustavo at the time wanted private ones
[10:00] <pedronis> we have a bunch of essentially secret interfaces atm
[10:00] <zyga-ubu1tu> pedronis: if they were public I'd have an easier life in some tests
[10:01] <zyga-ubu1tu> pedronis: I can make a RFC PR with just the private -> Public switch for htem
[10:01] <pedronis> I'm not sure what the reasoning was
[10:01] <zyga-ubu1tu> I don't remember anymore
[10:01] <pedronis> usually secret interfaces are for tightly coupled internal helpers
[10:01] <zyga-ubu1tu> I think it was not perceived as necessary as they were only used by the backends
[10:01] <pedronis> and usually then the methods are also private
[10:01] <zyga-ubu1tu> I see
[10:01] <pedronis> well, but the interfaces need to implement them
[10:02] <pedronis> and the doc don't have a signature of what they need to implement
[10:02] <pedronis> I find it strange as Chipaca did here
[10:02] <zyga-ubu1tu> right, I think they could be public
[10:03] <zyga-ubu1tu> eh, IRC, the protocol for wired mainframes
[10:05] <pedronis> zyga-ubuntu: at least  the various methods would need to mention them in the docs
[10:06] <pedronis> also the docs look strange
[10:06] <pedronis> in the backends, like copy-paste strange
[10:06] <zyga-ubuntu> yes, many of the interfaces have copy pasted stuff
[10:06] <zyga-ubuntu> just little by little :)
[10:06] <pedronis> like mount-specific  in apparmor?
[10:06] <zyga-ubuntu> I'd happily remove useless docs
[10:07] <zyga-ubuntu> I think I even noticed that a few months ago when doing a pass
[10:07] <zyga-ubuntu> just forgot to correct it at the time
[10:10] <pedronis> zyga-ubuntu: anyway +1 apart "core snap" and agreeing with Chipaca
[10:11] <zyga-ubuntu> ack, thank you
[10:17] <popey> ogra_: finaly got my serial cable hooked up to my nano pi. it only sees eth0 and not the wireless interface :(
[10:17] <popey> ogra_: any ideas how I can get in and get it on the wifi, as I'm stuck in subiquity right now
[10:19] <popey> lornajane: heya, couchdb landed in the snap store last night :)
[10:19] <lornajane> popey: so twitter tells me :)  But I tried to install it and now I have questions
[10:20] <lornajane> when I install a snap, how can I tell whether it has created me some commands, and what those are/do?
[10:21] <lornajane> if it starts daemon things, how can I tell what those are and what services I can now start/stop?
[10:21] <zyga-ubuntu> lornajane: Chipaca can help you!
[10:21]  * Chipaca hides
[10:22] <ogra_> popey, stop the boot at the uboot countdown
[10:22] <lornajane> awesome :)  Long-time ubuntu user, but new to snaps and not really a sysadmin so I think my questions are newbie ones - but I promise to blog what I learn so hopefully will head off future newbie questions
[10:22] <zyga-ubuntu> lornajane: \o/
[10:22] <Chipaca> lornajane: _right_ now, there's not a super simple way. For services, systemctl status snap.<tab> should help.
[10:22] <zyga-ubuntu> lornajane: also we have a very nice forum on forum.snapcraft.io
[10:23] <ogra_> popey, then: setenv mmcargs 'setenv bootargs "console=ttyS0,115200 root=${mmcroot} init=/bin/bash"'
[10:23] <ogra_> popey, then: saveenv; reset
[10:23] <Chipaca> lornajane: really soon (1 or at most 2 releases away) there'll be a simplified interface so you don't need to look at systemctl unless you want to
[10:23] <ogra_> popey, that should give you a prompt after boot
[10:23] <Chipaca> but, today, that's what there is
[10:23] <lornajane> I can manage systemctl, and I did realise there was a process running
[10:24] <lornajane> it's not attached to the port I would expect though, and I don't know how to help it
[10:24] <Chipaca> lornajane: and once you know the unit name, journalctl -u <that name> will show you logs
[10:24] <Chipaca> lornajane: ah, that's down to the individual snap i'm afraid
[10:24] <Chipaca> some'll let you configure it, some won't
[10:24] <lornajane> oh poor thing is stuck in a loop
[10:25] <Chipaca> aw
[10:26] <lornajane> or maybe looped a bit when it started?  Hmm.  I notice that I have a couchdb command now but that is also unhappy
[10:31] <popey> ogra_: ok, will play with taht thanks!
[10:32] <lornajane> OK.  I'm not sure what to do next but I think it's couchdb-specific so I'll wander back over there and see if they can assist.  I'm so pleased though to see snappy stuff taking over the world :)
[10:33] <popey> ogra_: yay, got a console prompt, now what? :)
[10:40] <ogra_> popey, cat /proc/net/dev ... do you see a wlan device there ?
[10:42] <popey> ogra_: no
[10:43] <ogra_> popey, modprobe brcmfmac
[10:43] <ogra_> and check in dmesg
[10:47] <zyga-ubuntu> Chipaca: reviewed
[10:54] <Chipaca> zyga-ubuntu: int((^uint(0)) >> 1) is only math.MaxInt64 on 64 bits
[10:54] <Chipaca> zyga-ubuntu: there isn't a MaxInt
[10:54] <Chipaca> :-(
[10:55] <Chipaca> anyway, i'll comment on the PR when i get back from a run
[10:55]  * Chipaca getting ready to go afk for a bit
[10:55] <zyga-ubuntu> ah, Isee
[10:55] <zyga-ubuntu> enjoy!
[10:55] <zyga-ubuntu> I'll get to your feedback now
[10:56] <Chipaca> uh, that println was debugging i needed to nuke
[10:56]  * Chipaca goes afk
[10:56] <popey> ogra_: [ 1247.038733] usbcore: registered new interface driver brcmfmac
[11:00]  * zyga-ubuntu needs wording help
[11:00] <zyga-ubuntu> pedronis:
[11:00] <zyga-ubuntu> +// PlugSanitizer describes an interface that can sanitize plug instances.
[11:00] <zyga-ubuntu> +type PlugSanitizer interface {
[11:00] <zyga-ubuntu> WDYT?
[11:00] <zyga-ubuntu> or just "that can sanitize plugs"
[11:00] <ogra_> popey, any change in /proc/net/dev ? (or ifconfig)
[11:08] <morphis_> zyga-ubuntu: there seems to be a problem on debian with latest snap-confine from 2.26.14
[11:08] <morphis_> zyga-ubuntu: see https://github.com/anbox/anbox/issues/386
[11:08] <morphis_> "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks"
[11:09] <pedronis> zyga-ubuntu: PlugSanitizer can be implemented by Interfaces that have a need to sanitize their plugs  ?
[11:10] <pedronis> or "have reasons"
[11:10] <zyga-ubuntu> morphis_: that machine must have apparmor enabled
[11:10] <zyga-ubuntu> pedronis: nice, thank you!
[11:11] <zyga-ubuntu> morphis_: (via boot command line argument)
[11:11] <zyga-ubuntu> morphis_: but I'm aware of "something being off" on debian since we published the last stable snap, I intend to keep digging today, I cannot reproduce the problem yet (which drives me nuts)
[11:12] <zyga-ubuntu> morphis_: we also know that once you are in the wedged state you are also affected by lack of reverse reexec
[11:12] <morphis_> zyga-ubuntu: afaik we do --disable-apparmor on debian
[11:13] <zyga-ubuntu> morphis_: no, that's not even it
[11:13] <zyga-ubuntu> morphis_: the thing is that that message is *only* shown when the kernel has apparmor enabled (not just built but actually active) *and* snap-confine is not confined
[11:13] <zyga-ubuntu> morphis_: may be a misalignment with snapd's appamror profile generation for core's snap-confine
[11:14] <morphis_> zyga-ubuntu: but actually if we build snap-confine on debian with --disable-apparmor should that be respected when we re-exec?
[11:14] <zyga-ubuntu> morphis_: but I haven't seen it before
[11:14] <zyga-ubuntu> morphis_: no, remember that when we re-exec we use the one from core
[11:14] <morphis_> right
[11:14] <zyga-ubuntu> morphis_: so the compile time build option is not relevant
[11:14] <morphis_> but it was the distro decision to disable AppArmor
[11:15] <zyga-ubuntu> morphis_: can you reproduce that problem?
[11:15] <morphis_> zyga-ubuntu: I can't, it's an anbox bug report from a user
[11:15] <zyga-ubuntu> morphis_: is /sys/kernel/security/apparmor around?
[11:15] <zyga-ubuntu> aha
[11:15] <zyga-ubuntu> well, must be that then
[11:15] <morphis_> feel free to comment on the report
[11:15] <morphis_> it's just an hour old
[11:15] <zyga-ubuntu> doing that now
[11:15] <morphis_> thanks!
[11:16] <pedronis> zyga-ubuntu: still lgtm,  don't know if Chipaca wants to chime in on the wording.
[11:18] <zyga-ubuntu> morphis_: done
[11:18] <zyga-ubuntu> pedronis: updated to what you suggested
[11:18] <zyga-ubuntu> pedronis: I think chipaca might be back by the time tests finish
[11:21] <morphis_> zyga-ubuntu: thanks
[11:43] <popey> ogra_: nothing
[11:45] <ogra_> popey, then i fear there is something missing in the devicetree file, the nanopi-air should use an ampak AP6212 http://linux-sunxi.org/Wifi AFAIK ... i guess the HW isnt properly initialized ... i'll have to dig a bit
[11:47] <popey> ogra_: ok. lemme know if there's anything I can get off the device :)
[11:47] <ogra_> popey, theer we go https://github.com/armbian/build/blob/master/patch/kernel/sun8i-dev/add-nanopi-neoair.patch
[11:48] <popey> ogra_: so you need to make a new image with that patch?
[11:48] <ogra_> popey, re-building my hackish allwinner kernel will take a while though, it is very fiddly ... but that seems to be the right patch top enable the AP6212
[11:48] <popey> ok, great
[11:48] <ogra_> s/top/to/
[11:48] <ogra_> yeah, i need to make a new kernel
[11:49] <popey> ok, I'l put him back in his box for now then :)
[11:49] <popey> gimme a ping when you need me to test again :)
[11:49] <ogra_> yeah, i'll try to get this done on the weekend
[11:49] <popey> nice, thanks
[11:49] <popey> beer++
[11:49] <ogra_> :)
[11:49] <Chipaca> pedronis: zyga-ubuntu: wording of what?
[11:50]  * Chipaca still not fully back (mostly thinking about lunch right now)
[11:50] <pedronis> Chipaca: zyga's branch,  doc comments for the new public interfaces
[11:50] <Chipaca> ah, i thought that was to be separate because it needed discussion
[11:55] <pedronis> Chipaca: ?
[11:58] <Chipaca> pedronis: i thought as gustavo had originally said no to the public interfaces, zyga was going to make a separate pr to discuss it
[11:58] <pedronis> Chipaca: in a different context
[11:58] <pedronis> anyway pawel will need to redo this anyway
[11:59] <pedronis> so another chance to argue one way or another
[12:01] <zyga-ubuntu> re
[12:01]  * zyga-ubuntu writes user docs
[12:04] <zyga-ubuntu> Chipaca: just this https://github.com/snapcore/snapd/pull/3619/commits/f6fb74af3fcbcea7caa72ee645c169f9f33f962d
[12:04] <mup> PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619>
[12:04] <Chipaca> zyga-ubuntu: hmmm
[12:05] <Chipaca> zyga-ubuntu: i guess there's no way around interfaces vs interfaces :-)
[12:05] <Chipaca> zyga-ubuntu: +1
[12:06] <pedronis> yes, that is our self impose loss in the terminology battle
[12:07] <zyga-ubuntu> hehe
[12:07] <zyga-ubuntu> let's also add Channel so that we can have more confusion
[12:08]  * zyga-ubuntu resumes writing docs
[12:08] <zyga-ubuntu> writing docs is *fun*
[12:08] <Chipaca> zyga-ubuntu: next feature we add is being able to expose only a subset of the full store to a device, something like a gadget-set filter
[12:08] <Chipaca> zyga-ubuntu: we'll call that a "slice"
[12:09]  * Chipaca runs for the hills
[12:09] <zyga-ubuntu> Chipaca: slice and dice
[12:12] <pedronis> interface, channel, slice       , map next?
[12:12] <pedronis> we'll we dare to go where nobody has gone, and have features called "integers" and "bools"
[12:13] <zyga-ubuntu> LOL :D
[12:13] <zyga-ubuntu> map:\n\tbool:\n\t5
[12:15] <Chipaca> registers and pointers, that's what's next
[12:26]  * zyga-ubuntu writes stuff at https://forum.snapcraft.io/t/feature-snap-layouts/1471/2
[12:27] <zyga-ubuntu> actually, I think this is a very good moment to take a break and eat lunch
[12:58] <mup> PR snapcraft#1426 opened: tests: adapt opencv's test expectations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1426>
[12:58]  * Chipaca hunts for tea
[13:01] <zyga-ubuntu> are we doing the standup today?
[13:02] <Chipaca> yes
[13:02] <Chipaca> omw
[13:02] <Chipaca> bah, i think we are :-)
[13:05] <Chipaca> pedronis: standup?
[13:05] <cachio> pedronis, joining standup?
[13:05] <Chipaca> pedronis: https://www.youtube.com/watch?v=pZG7IK99OvI !
[13:13] <zyga-ubuntu> cachio: I'm reading your pastebin
[13:14] <cachio> zyga-ubuntu, the failover tests are the one to see
[13:15] <fgimenez_> cachio: about the test error in https://paste.ubuntu.com/25188524/ you should remove auto-refresh from the job definitions for the dragonboard executions on the lab, the post has the details
[13:15] <fgimenez_> https://forum.snapcraft.io/t/core-snap-validation-process-at-beta-channel/1454
[13:15] <zyga-ubuntu> error: cannot copy request into temporary file: write
[13:15] <zyga-ubuntu>        /tmp/snapd-sideload-pkg-627586801: no space left on device
[13:15] <zyga-ubuntu> This doens't look like that error
[13:15] <zyga-ubuntu> looks like you ran out of space
[13:16] <ogra_> not really out of space but out of ram
[13:16] <cachio> fgimenez_, ok, the failover tests could be failed because of that?
[13:16] <ogra_> since /tmp is a tmpfs
[13:17] <ogra_> use TMPDIR and point to some place on disk
[13:18] <fgimenez_> cachio: not sure, i ended up removing it because the whole suite started to fail after the auto-refresh error
[13:19] <zyga-ubuntu> ogra_: indeed
[13:20] <Chipaca> zyga-ubuntu: what would you call the const for the journal timestamp key?
[13:21] <zyga-ubuntu> const magic = "__STUFF"
[13:21] <zyga-ubuntu> as long as it is used >1
[13:21] <zyga-ubuntu> the name isn't as relevant if it can stay private
[13:24] <Chipaca> zyga-ubuntu: only other use is in the tests
[13:29] <cachio> fgimenez_, zyga-ubuntu  I am running again the suite without the auto-refresh test
[13:29] <cachio> i'll keep you updated
[13:29] <kjackal_> hi everyone, how do I specify daemon dependencies? I want mysnap daemon to start after an optional service eg lxd.service
[13:29] <ogra_> i dont think thats possible yet
[13:29] <ogra_> (ICBW though)
[13:30] <fgimenez_> cachio: great, by default tpr splits the suite in 4 parts, you need only to modify the part that includes auto-refresh (removing it) the rest of executions should be fine with the generated testflinger job definitions
[13:30] <cachio> fgimenez_, yes, I forgot that :(
[13:31] <kjackal_> ogra_: is there a way to manualy edit the systemd unit file?
[13:31] <ogra_> nope
[13:31] <ogra_> but you could use a wrapper script
[13:31] <ogra_> i.e. have a single systemd unit that invokes the wrapper ... and have the wrapper start the daemons in the right order
[13:32] <ogra_> ... as a workaround until such a feature is provided by snapd
[13:32] <fgimenez_> cachio: np, the good thing of having the suite splitted in four is that you can run the dragonboard tests in parallel, so that it doesn't take >6h, each part takes 1-2h
[13:34] <kjackal_> thanks ogra_
[13:35] <fgimenez_> cachio: and because those are executed in the lab you can run other kvm and board tests locally
[13:35] <cachio> yes
[13:35] <cachio> fgimenez_, starting now with the pi's
[13:37] <kjackal_> ogra_: is there a way to say i want my-snapped-service to start after all other services? like the Type=idle on systemd?
[13:37] <fgimenez_> cachio: cool! let me know how it goes
[13:38] <ogra_> kjackal_, not sure ... perhaps Chipaca knows, he played with systemd stuff a lot recently
[13:38] <ogra_> but i think the bits we can define for systemd units are still pretty limited
[13:39] <Chipaca> kjackal_: no, there isn't ordering yet
[13:39] <ogra_> again though ... you can have a wrapper, use the system-observe interface to watch if something you wait for runs and sleep until it gets up
[13:40] <Chipaca> kjackal_: and no support for Type=idle right now (although it _might_ work if you're sideloading)
[13:40] <ogra_> (though that means manually connecting the interface)
[13:40] <Chipaca> (I'd have to check)
[13:44] <Chipaca> kjackal_: confirmed daemon: idle does not work
[13:46] <kjackal_> Chipaca: ogra_: Just for some context, the questions I am asking have to do with this issue: https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/357 Where the kubernetes bundle will not work after rebooting the machine hosting a deployment of the bundle on lxd
[13:47] <kjackal_> seems snap services should start after the lxd.service (if present) but they do not
[13:47] <Chipaca> kjackal_: do you need a fix for the general problem, or for the particular instance?
[13:47] <Chipaca> kjackal_: because you could drop a unit snipped in there
[13:48] <ogra_> kjackal_, bug 1687079 ??
[13:48] <mup> Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:Confirmed> <https://launchpad.net/bugs/1687079>
[13:49]  * zyga-ubuntu solicits feedback on https://forum.snapcraft.io/t/feature-snap-layouts/1471/2
[13:50] <kjackal_> ogra_: the bug is most probably related to what I see
[13:50] <ogra_> yep
[13:50] <ogra_> thats why i posted it :)
[13:51] <kjackal_> Chipaca: since there are a bunch of services affected I would rather go for a generic solution (it affects practicaly all services)
[13:52] <Chipaca> kjackal_: the lxd service the snap services are running are not part of the same snap?
[13:54] <kjackal_> no, as I understand it, you have an lxd container that runs its services (including and lxd.service) and inside that container you want to deploy a snapped service eg etcd
[13:58] <Chipaca> kjackal_: so you have lxd, and inside lxd you have snapd, and install a snap with it?
[13:58] <Chipaca> that should just work, i don't see how it's a dependency
[14:00] <kjackal_> Chipaca: it is not the install that fails. The failure comes after rebooting the host. After the reboot the mysnapped-daemon comes before the lxd.service (both running inside the lxd container)
[14:02] <Chipaca> kjackal_: how can the mysnapped-daemon come up before the lxd service? the mysnapped-daemon is inside a container started by lxd
[14:07] <kjackal_> Chipaca: wait, I am not explaining this correctly. Inside the lxd container there is an lxd service running.
[14:07] <kjackal_> Chipaca: have alook here: http://pastebin.ubuntu.com/25190796/
[14:07] <kjackal_> I ssh on a machine on AWS
[14:07] <mup> PR snapcraft#1426 closed: tests: adapt opencv's test expectations <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1426>
[14:07] <kjackal_> and then I juju ssh on an etcd/0 and ask for the lxd.service
[14:09] <Chipaca> with you so far
[14:40] <cachio> fgimenez_, the failover tests still failing after remobe the auto-refresh test
[14:40] <cachio> fgimenez_, I'll dig into those
[14:45] <cachio> niemeyer, there?
[14:45] <fgimenez_> cachio: maybe something has changed in the lab, if they are the only failing tests you can run them locally on your db
[14:51] <zyga-ubuntu> wat
[14:51] <zyga-ubuntu> why is master not broken anymore
[14:51] <zyga-ubuntu> WTF is going on :/
[14:51] <kjackal_> Chipaca: ogra_: if I set the restart option to always is there a way to also set the delay between restarts (RestartSec=??? on systemd)
[14:51]  * zyga-ubuntu merged interface sanitize change, cannot wait to patch other PRs now
[14:51] <kjackal_> ?
[14:52] <ogra_> zyga-ubuntu, want me to break it so you feel better ?
[14:52] <zyga-ubuntu> ogra_: if you can break it the same way it used to be broken a moment ago? please !
[14:52] <Chipaca> kjackal_: no
[14:52] <mup> PR snapd#3619 closed: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3619>
[14:52] <ogra_> zyga-ubuntu, nah, thats not very creative ...
[14:52] <Chipaca> kjackal_: you kinda wandered off mid-explanation back there
[14:53]  * ogra_ would only break it in new and unexpected ways
[14:53] <kjackal_> Chipaca: sorry about that there was the daily standup
[14:53] <zyga-ubuntu> ogra_: indeed, it would be exactly very repetetive
[14:53] <ogra_> cachio, fginther just run them with TMPDIR=/var/tmp ...
[14:53]  * zyga-ubuntu looks at ondra's PR
[14:53] <ogra_> err
[14:54] <ogra_> s/fginther/fgimenez/
[14:55] <kjackal_> Chipaca: So we were at the point where, inside an AWS machine I have an lxd container. Inside the container I have a snaped etcd running next to lxd.service
[14:55] <Chipaca> kjackal_: i think we didn't get that far
[14:55] <Chipaca> kjackal_: you ssh'd to a host, juju-ssh'd to another, and showed me the lxd.service
[14:56] <Chipaca> i asusme juju-ssh is to a container
[14:56] <kjackal_> Chipaca: Yes exactly (http://pastebin.ubuntu.com/25190796/)
[14:57] <Chipaca> you also showed me that there wasn't an lxd.service in the "outside" host
[14:57] <kjackal_> Chipaca: yes
[14:57] <Chipaca> kjackal_: and it's in the "juju-ssh" container that you snap install something?
[14:58] <kjackal_> Chipaca: I suspect the lxd on the host is packaged with the conjure-up snap
[14:58] <kjackal_> Chipaca: yes
[14:59] <Chipaca> kjackal_: and that thing you snap install depend son the lxd.service that runs on that same container?
[14:59] <kjackal_> yes
[14:59] <Chipaca> kjackal_: so you you "systemctl stop lxd.service", it dies?
[14:59] <kjackal_> Chipaca: depends in the sence of a service/daemon
[14:59] <Chipaca> it == the thing in the snap
[15:00] <Chipaca> kjackal_: so, to be clear, I doubt very much there's going to be a way to be able to express this dependency in snapd any time soon
[15:02] <kjackal_> Chipaca: I see so... what else can we do?
[15:03] <kjackal_> Chipaca: thowing ideas, "Type=idle", "RestartSec=X"?
[15:03] <zyga-ubuntu> ondra: hey
[15:03] <ogra_> wrappers ;)
[15:03] <zyga-ubuntu> ondra: I pushed to https://github.com/snapcore/snapd/pull/3624
[15:03] <mup> PR snapd#3624: rework for avahi interface <Created by kubiko> <https://github.com/snapcore/snapd/pull/3624>
[15:03] <Chipaca> kjackal_: does Type=idle fix the thing for you?
[15:03] <ondra> zyga-ubuntu hey :)
[15:03] <zyga-ubuntu> ondra: please look at my feedback and ping me if you want to talk
[15:03] <ondra> zyga-ubuntu sorry I was off yesterday
[15:03] <Chipaca> kjackal_: that might be the easiest
[15:03] <kjackal_> Chipaca: it is a workaround
[15:03] <Chipaca> clearly
[15:03] <zyga-ubuntu> ondra: use go fmt, I changed 2/3 of your files after just saving them in vim :)
[15:03] <Chipaca> but then, what you're wanting to do isn't supported
[15:03] <ondra> zyga-ubuntu yeah I read then all good
[15:04] <Chipaca> ¯\_(ツ)_/¯
[15:04] <zyga-ubuntu> ondra: I resolved conflict after landing a small API change in master
[15:04] <zyga-ubuntu> ondra: so you should be all good now
[15:04] <ondra> zyga-ubuntu I have alerdady changes even
[15:04] <ondra> zyga-ubuntu ahh you did it as well?
[15:04] <Chipaca> kjackal_: but my question is whether it's a workaround that _works_ :-)
[15:04] <zyga-ubuntu> ondra: well, I just said so on the PR :)
[15:04] <zyga-ubuntu> ondra: pull, you should be fine
[15:04] <Chipaca> if it's a workaround that leads to a race condition, then it's no good either
[15:04] <kjackal_> Chipaca: tested it with etcd service and it works, yes
[15:04] <zyga-ubuntu> (or rebase on top)
[15:05] <Chipaca> kjackal_: but you said you had "a bunch"
[15:05] <Chipaca> kjackal_: what happens if the whole bunch are all idle?
[15:06] <zyga-ubuntu> ondra: feel free to iterate or stop as you see fit, I cna iterate on that next week as well
[15:06] <ondra> zyga-ubuntu let's have a look next week
[15:06] <kjackal_> Chipaca: If we identify this as a potential solution then I will need to test that before we commit to a fix/feature implementation
[15:07] <ondra> zyga-ubuntu I did changes as per your comments, but then two of my tests were paninckin
[15:07] <ondra> zyga-ubuntu and I was not able to figure out why
[15:07] <zyga-ubuntu> ondra: ok, put a comment on the PR or here if you want some insta-hints
[15:07] <kjackal_> Chipaca: can I ping you on monday with what I have? I am almost at EOD here
[15:08] <Chipaca> kjackal_: so, the Type=idle thing is easy to implement at our end, but that's still a month away from you being able to use it
[15:08] <zyga-ubuntu> Chipaca: unless edge
[15:08] <zyga-ubuntu> Chipaca: then it's tomorrow :)
[15:08] <Chipaca> kjackal_: so I think we can talk about whether allowing snaps to specify arbitrary After= lines is reasonable
[15:09] <Chipaca> kjackal_: that's a day of discussion probably, but over a week away because our architect is on holiday
[15:10] <Chipaca> I don't think it'd break anything conceptually to allow snaps to say After=bananas
[15:10] <Chipaca> it's not a dependency, it doesn't pull in anything, it's just ordering
[15:10] <ogra_> as long as the service is included in your snap at least
[15:10] <Chipaca> although it can break a system :-(
[15:10] <Chipaca> gah
[15:10] <Chipaca> it can break a system by creating a loop
[15:11] <ondra> zyga-ubuntu so those changes you pushed, are those just formatting changes?
[15:11] <kjackal_> Chipaca: ogra_: After=?? would also need for Wants=???
[15:11] <Chipaca> kjackal_: why? all you want is After=
[15:11] <Chipaca> kjackal_: lxd is already being started, you just want to tweak the order
[15:11] <Chipaca> anyway, it's for discussion with our architect, not for irc
[15:11] <Chipaca> (and it's not super-obvious that it'll work)
[15:11] <zyga-ubuntu> ondra: no, I resolved conflicts, fixed one more non-compiling-after-merge conflict (that git wasn't complaining about), re-formatted, dropped the Sanitize methods (empty, no longer needed)
[15:12] <Chipaca> Wants= is super obvious to me that it's wrong for snaps
[15:12] <zyga-ubuntu> ondra: that's all
[15:12] <zyga-ubuntu> morphis: I'm going to push some changes to https://github.com/snapcore/snapd/pull
[15:12] <morphis> zyga-ubuntu: which pull request?
[15:12] <ondra> zyga-ubuntu so shall I rebased on your commit and to changes based on comments on top of that?
[15:13] <kjackal_> Chipaca: sounds good Chipaca should we talk again towards the end of next week to setup a meeting?
[15:13] <zyga-ubuntu> oh
[15:13] <zyga-ubuntu> man
[15:13] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/3623
[15:13] <mup> PR snapd#3623: interfaces/builtin: implement broadcom-asic-control interface <Created by morphis> <https://github.com/snapcore/snapd/pull/3623>
[15:13] <zyga-ubuntu> how did that happen
[15:13] <Chipaca> kjackal_: sounds good
[15:13] <zyga-ubuntu> ondra: yep, that sounds perfect
[15:13] <morphis> zyga-ubuntu: what kind of changes?
[15:13] <kjackal_> Thank you both Chipaca and ogra_
[15:14] <ogra_> well, i was only shouting from the side-line ...
[15:14] <zyga-ubuntu> morphis: I'll resolve conflicts and do small tweaks in line with recently landed huge interface cleanup PR
[15:14] <morphis> ok
[15:14] <Chipaca> ogra_: take your internet thank yous! they're tradeable for beer!!
[15:14] <morphis> zyga-ubuntu: thanks!
[15:14] <ogra_> Chipaca, noted ...
[15:14]  * ogra_ puts in his bag
[15:14] <zyga-ubuntu> just so that you and others don't have to wonder what to do after their branches break
[15:15] <zyga-ubuntu> morphis: and rename the files, man, nobody noticed that !
[15:15] <morphis> which files?
[15:15] <ogra_> the wrongly named ones
[15:15] <ogra_> :P
[15:16] <zyga-ubuntu> morphis: dashes instead of underlines in filenames
[15:16] <morphis> did that change recently?
[15:18] <zyga-ubuntu> morphis: no, I think we never used dashes in filenames
[15:22] <zyga-ubuntu> morphis: pushed
[15:26]  * zyga-ubuntu moves to another PR
[15:30]  * zyga-ubuntu moves to a coffee break
[15:30]  * genii cartwheels by without spilling his coffee
[15:58] <ogra_> fgimenez, the pi2-kernel in edge is behind the rest once again, are you fie with me bumping it to the version of beta/candidate ?
[15:59] <fgimenez> ogra_: sure, we are currently not doing any testing of pi2 in edge, cachio, ok to have them in sync?
[16:01] <janisozaur> zyga-ubuntu: jestem
[16:11] <mup> PR snapd#3632 opened: asserts,overlord/assertsstate: auto refresh account-keys <Created by pedronis> <https://github.com/snapcore/snapd/pull/3632>
[16:49]  * zyga-ubuntu EODs
[16:49] <zyga-ubuntu> ttyl
[16:49] <zyga-ubuntu> o/
[16:58] <mup> PR snapd#3633 opened: overlord/devicstate: fix, don't assume that the serial is backed by a 1-key chain <Created by pedronis> <https://github.com/snapcore/snapd/pull/3633>
[18:49] <mup> PR snapcraft#1427 opened: Add cx_Freeze options targeting bin/snapcraft <Created by alextnewman> <https://github.com/snapcore/snapcraft/pull/1427>
[19:28] <mup> PR snapcraft#1428 opened: core: reexec as root for `os` snaps if necessary <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1428>
[21:27] <mup> PR snapd#3634 opened: interfaces/many, cmd/snap-confine: miscellaneous policy updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3634>
[22:59] <mup> PR snapcraft#1429 opened: cli: properly handle exceptions in lifecycle <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1429>