=== JanC is now known as Guest15321
=== JanC_ is now known as JanC
=== chihchun_afk is now known as chihchun
[05:15] <mup> PR snapd#3437 opened: tests: apt autoclean <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3437>
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[06:53] <zyga> good morning!
[06:53] <zyga> mvo: hey, did you see the resolution of the lock bug?
[06:53] <icey> any idea why a snap would not list its aliases in `snap aliases`?
[06:58] <zyga> icey: that's something pedronis would know
[06:58] <icey> to expand a bit, the app in the snapcraft.yaml hasthe alias listed (aliases: [rg]), but it isn't listed at all with the snap installed
[07:01] <mvo> hey zyga - good morning
[07:01] <mvo> zyga: yeah, looks like the root cause is found which is great
[07:03] <mup> PR snapd#3436 closed: tests: fix econnreset on staging <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3436>
[07:04] <mup> PR snapd#3432 closed: tests: clean journalctl logs on trusty <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3432>
[07:12] <mup> PR snapd#3414 closed: tests: show available entropy on error <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3414>
[07:34] <mvo> morphis: which PR did you asked me to review yesterday? sorry, forgot about it and want to do it now
[07:52] <mvo> apw: hey, good morning! are there any blockers for 2.26.4 into -propsed left? the artful arm build failure is fixed and afaics autopkgtests on artful are also happy
[08:11] <morphis> mvo: hey!
[08:12] <morphis> mvo: https://github.com/snapcore/snapd/pull/3365 and https://github.com/snapcore/snapd/pull/3222 are the most relevant ones
[08:12] <mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
[08:12] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[08:12] <morphis> mvo: where I would really like to get #3222 merged as its pending for nearly 1.5 months now
[08:12] <mvo> if someone could do a second review on #3348 that would be great
[08:12] <mvo> morphis: thanks, checking
[08:13] <morphis> mvo: let me look at
[08:13] <morphis> #3348
[08:13] <mvo> morphis: isn't 3365 blocking on a second gustavo review?
[08:14] <morphis> mvo: it is
[08:14] <morphis> mvo: both PRs are
[08:15] <morphis> but I hope we can spot all minor things until he has time to look again
[08:17] <mvo> morphis: :) makes sense
[08:18] <morphis> mvo: thanks for the review on the suse PR
[08:46] <morphis> mvo: fixed the things you pointed out in https://github.com/snapcore/snapd/pull/3406
[08:46] <mup> PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>
[08:49] <mvo> thanks morphis
[08:52] <morphis> np
[08:54]  * zyga will soon have time to do some reviews
[09:01] <Chipaca> Tribaal: i like where (i imagine) you're going with your 'how to make a very simple deb package' post :-)
[09:13] <zyga> oookay
[09:13]  * zyga has 93 patches
[09:21] <mup> PR snapd#3111 closed: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3111>
[09:23] <mvo> zyga: 93 patches for what?
[09:27] <zyga> mvo: for allowing base declaration to be declared alongside each interface
[09:29] <mvo> zyga: once you did that, I would love to talk about base-snaps and snap-confine, the next step for 3317 is snap-confine support
[09:29] <zyga> excellent
[09:30] <zyga> ho in 10 min?
[09:33] <mvo> zyga: yeah, something like this, I'm in the middle of a branch myself, so make that ~15min :)
[09:41] <apw> mvo, so do i take it the build failure was triggered by an external artful specific issue which has been fixed and those builds retried ?
[09:42] <Chipaca> pedronis: is this https://forum.snapcraft.io/t/auto-aliasing-and-duplicate-aliases/907 a question for you?
[09:43] <mvo> apw: correct, arm/armhf is now building with PIC by default and that required a non-change rebuild of apparmor, I did that and things are fine
[09:43] <apw> mvo, then no i don't think there are any blockers, and i'll go sort that out
[09:45] <mvo> apw: yay, thanks a lot!
[09:46] <morphis> zyga: can you add your PRs for snap-confine to https://forum.snapcraft.io/t/including-snapd-in-the-opensuse-factory-branch/863 ?
[09:48] <zyga> morphis: I haven't pushed them yet but I will do, I'm adding the last part of the base-policy work
[09:48] <morphis> zyga: didn't you push at least the spread test one?
[09:49] <zyga> morphis: then I'll have a call with mvo and then I'll resume snap-confine work, sorry for keeping you waiting
[09:49] <morphis> I am sure I saw one
[09:49] <morphis> zyga: np
[09:49] <zyga> morphis: ah, yes, that one landed I think
[09:49]  * zyga looks
[09:49] <pedronis> Chipaca: yes,  have bookmarked will answer to it
[09:49] <Chipaca> pedronis: ok
[09:50] <zyga> morphis: done
[09:51] <morphis> zyga: thanks!
[10:06] <zyga> Chipaca: hey, how to use http to POST some data to /v2/debug endpoint
[10:07] <zyga> Chipaca: I try the naive "http snapd:///v2/debug '...'" but this fails on invalid header name
[10:07] <Chipaca> 1 sec, let me try it here :-)
[10:07] <zyga> Chipaca: should I redirect the actual input via < and make it look like a http request?
[10:07] <zyga> Chipaca: I added a new debug method and I want to play with it
[10:07] <zyga> Chipaca: if you can post things like "ensure-state-soon" that's enough
[10:08] <zyga> Chipaca: ah, I got it
[10:08] <Chipaca> zyga: http snapd:///v2/debug action=ensure-state-soon
[10:09] <zyga> :D
[10:09] <zyga> thanks!
[10:09] <Chipaca> np!
[10:09] <zyga> I used more brute force way
[10:09] <zyga> << EOF
[10:09] <zyga> and then I typed the JSON
[10:09] <Chipaca> yes, that also works
[10:09] <Chipaca> but http knows about json body POSTs
[10:09] <Chipaca> :-)
[10:09] <mvo> zyga: I need to have lunch soon, so we need to postpone the HO
[10:09] <zyga> mvo: sure
[10:09] <mup> PR snapd#3438 opened: daemon: make snapd a "Type=notify" daemon and notify when startup is done <Created by mvo5> <https://github.com/snapcore/snapd/pull/3438>
[10:09] <zyga> mvo: I'm in the HO for some time, just join me when you can :)
=== ogra_ is now known as ogra
[11:01] <zyga> mvo: one more thing
[11:02] <zyga> mvo: to get base snaps to work on core systems we will need to treat them the same way as we do on classic
[11:02] <zyga> mvo: with pviot root and what not
[11:02] <zyga> mvo: (which is actually nice)
[11:02] <zyga> mvo: I won't make that change today
[11:04] <Saviq> hey all, any idea where did https://developer.ubuntu.com/snappy/guides/mir-snaps go?
[11:08] <ogra> Saviq, i think davidcalle was working on getting it back
[11:11] <zyga> mvo: ok, I have a branch with the --base snap option
[11:11] <zyga> mvo: now to glue it to snap-exec
[11:11] <zyga> mvo: did you land your branch that adds information about the base snap to snap info?
[11:18] <zyga> mvo: ^ pushed as 3439
[11:18] <zyga> mvo: let's land your earlier branch and iterate
[11:19] <mup> PR snapd#3439 opened: cmd/snap-confine: add support for --base snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3439>
[11:45] <davidcalle> Saviq: should be online by EOD or tomorrow
[11:58] <zyga> mvo, Chipaca: can you please +1 a trivial 3440
[11:58] <zyga> I'll merge it when it goes green, I have some stuff I want to propose on top
[11:59] <mup> PR snapd#3440 opened: interfaces: move base declaration to the policy sub-package <Created by zyga> <https://github.com/snapcore/snapd/pull/3440>
[12:00] <mup> PR snapcraft#1314 closed: catkin plugin: add support for rosinstall files <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1314>
[12:01] <pedronis> Chipaca: I tried to answer
[12:03] <mup> PR snapcraft#1357 opened: tests: do not break a systems `bzr whomai` <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1357>
[12:08]  * Chipaca ~> lunch
[12:15] <morphis> mvo: looks like we don't have .vendor.tar.* tarballs for the 2.26.4, right?
[12:15] <morphis> only see one for 2.26.1 on https://github.com/snapcore/snapd/releases
[12:16] <jdstrand> ogra: hi! friendly ping that 4.4.0-79 is out for bbb
[12:16] <ogra> jdstrand, friendl pong that edge already has the new package ;)
[12:16] <jdstrand> I see it is in edge (nice!)
[12:16] <ogra> (waiting for my bbb to auto-upgrade
[12:16] <ogra> )
[12:16] <jdstrand> ah
[12:16] <ogra> (because i want to test something alongside)
[12:16] <jdstrand> ogra: curious if edge is auto-uploaded?
[12:17] <ogra> once i see it boots i'll push it to the other channels
[12:17] <ogra> yeah, it is
[12:17] <jdstrand> nice
[12:17] <ogra> with my work on split-initrd i plan to re-ork the whole process to actually use build.snapcraft.io though
[12:17] <ogra> *re-work
[12:18] <ogra> and move linux-generic-bbb to GH
[12:18] <mvo> morphis: 2.26.4 is missing indeed, I take care of it today
[12:18] <morphis> mvo: thanks!
[12:19] <zyga> Chipaca, pedronis: 3441 is for you
[12:19] <mup> PR snapd#3441 opened: cmd,daemon: add debug command for displaying the base policy <Created by zyga> <https://github.com/snapcore/snapd/pull/3441>
[12:19] <mvo> zyga: re one more thing> indeed, it will behave like on classic right now
[12:19] <zyga> mvo: yes, I agree
[12:20] <mvo> zyga: ta
[12:20] <mvo> zyga: and thanks for the branch!
[12:20] <zyga> mvo: I think it's not a big deal (less code actually) but some stuff will need to change
[12:20] <mvo> zyga: I check it out now
[12:20] <zyga> mvo: I will do that but not today, I need to work on stuff for openSUSE for morphis first
[12:20] <zyga> mvo: and then I want to return to the core/base snap staleness issue
[12:20] <zyga> mvo: but if you are blocked by anything please ping me, it should be easy :)
[12:20] <mvo> zyga: yeah, I think we need richer yam (as we talked about) in the medium term
[12:21] <mvo> zyga: no worries, thanks! lets aim for EOW for some progress with bases
[12:21] <zyga> mvo: I'm pretty sure we can run stuff today if you land your other branch that has the name of the base snap in snap info, and pull the base snap on install
[12:21] <zyga> mvo: I can quickly patch snap run to pass --base next
[12:22] <mvo> zyga: no worries, I can do the --base PR
[12:22] <mvo> zyga: I will also need to look at some 2.26.4 releated release work :/
[12:23] <zyga> oh? more fun?
[12:24] <mvo> zyga: yeah, need to investigate a potential trusty bug
[12:24] <zyga> mvo: oh, anything I can help with?
[12:24] <zyga> mvo: is it related to rshare of /snap/
[12:26] <mvo> zyga: the snap confine profile rewrite is looking for "snap.confine.real" but on trusty it looks like we don't call it .snap-confine.real :/
[12:26] <mvo> zyga: andy spotted this while reviewing the diff
[12:28] <zyga> mvo: oh, interesting
[12:28] <mvo> zyga: I have not looked at the details yet, I will finish 3438 and continue then
[12:28] <zyga> mvo: I changed that later to always call it .real
[12:28] <zyga> mvo: at least in testing
[12:28] <zyga> mvo: but hmm hmm, indeed
[12:28] <mvo> zyga: plus it looks like a test for this is missing or incorrect (in spread)
[12:28] <zyga> mvo: are you talking about maintainer script or the code in snapd that relates to core and reexec
[12:28] <mvo> zyga: feel free to grab it if you want :)
[12:29] <mvo> zyga: core and re-exec
[12:29] <mvo> zyga: but like I said, I have not looked into the details yet, just got word from andy that it may be fishy
[12:29] <zyga> mvo: hmm, but isn't the core always 16.04 so the profile name is fixed?
[12:29] <zyga> aha
[12:29] <zyga> I'm jumping into a slot of calls, I can look with you after the standup
[12:33] <mvo> zyga: aha, indeed, i think you are right, will double check
[12:56] <mup> PR snapd#3412 closed: tests: fix for snapd-reexec test cheking for restart info on debug log <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3412>
[12:59] <Saviq> davidcalle, thanks
[13:07] <Chipaca> HO is having one of those days it seems
[13:42] <didrocks> jdstrand: hey, I'm having a weird issue/question on apparmor vs desktop snap
[13:42] <didrocks> jdstrand: so, there are some theme properties (like dark theme) which are in a file ~/.config/gtk-3.0/settings.ini
[13:43] <didrocks> it's basically gtk-application-prefer-dark-theme=1
[13:43] <didrocks> I was going to test before adding access to that file in the unity7 interface
[13:43] <didrocks> the snap is a confined one (gtk3-demo), which has the home plug. I create a symlink at launch in SNAP_USER_DATA/.config/gtk-3.0/settings.ini
[13:43] <didrocks> if I snap run --shell
[13:44] <didrocks> and $ cat $SNAP_USER_DATA/.config/gtk-3.0/settings.ini
[13:44] <didrocks> cat: /home/didrocks/snap/gtk3-demo/x1/.config/gtk-3.0/settings.ini: Permission denied
[13:44] <didrocks> as expected (as you told, .* are forbidden by default in the apparmor profile)
[13:44] <didrocks> same with direct cat /home/didrocks/.config/gtk-3.0/settings.ini
[13:45] <didrocks> however, running gtk3-demo, it applies the dark and white themes based on that file!
[13:45] <didrocks> if gtk-application-prefer-dark-theme=1 in settings.ini -> running gt3-demo -> dark
[13:45] <didrocks> if gtk-application-prefer-dark-theme=0 in settings.ini -> running gt3-demo -> white
[13:45] <didrocks> and that's the only thing I change!
[13:46] <didrocks> I'm wondering how come I can't cat it, but in some way, gtk is able to read it (and wonder if we don't have some security apparmor profile issues)
=== cpaelzer_ is now known as cpaelzer
[13:55] <zyga> didrocks: reading is done differently than writing in gsettings, no?
[13:57] <didrocks> zyga: this isn't gsettings, it's a plain file
[13:57] <didrocks> (that's why I'm giving file path above, not gsettings schema path ^)
[13:58] <zyga> didrocks: can you show the apparmor denial you are getting?
[13:58] <didrocks> zyga: there is none in sudo snappy-debug.security scanlog
[14:00] <didrocks> when launching gtk3-demo
[14:00] <didrocks> but if I cat in snap run gtk3-demo --shell, I'm getting the expected:
[14:00] <didrocks> Log: apparmor="DENIED" operation="open" profile="snap.gtk3-demo.gtk3-demo" name="/home/didrocks/.config/gtk-3.0/settings.ini" pid=21903 comm="cat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[14:00] <didrocks> File: /home/didrocks/.config/gtk-3.0/settings.ini (read)
[14:00] <zyga> didrocks: dmesg | grep DENIED
[14:00] <zyga> aha
[14:00] <zyga> right
[14:01] <didrocks> so, basically, gtk has access to this file content, which sounds weird…
[14:03] <zyga> didrocks: note that dot-files in the real home are forbidden
[14:03] <zyga> didrocks: but in the remapped home you can do anything
[14:04] <morphis> mvo: updated https://github.com/snapcore/snapd/pull/3222
[14:04] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[14:04] <didrocks> zyga: yes, but that doesn't explain why gtk3 can read the original file in real ~/ though
[14:05] <zyga> is it getting that via dbus perhaps?
[14:05] <didrocks> nope
[14:05] <didrocks> as told above, the only change is done via that file between 2 launchs that are applied
[14:05] <zyga> well, that doesn't rule out dbus
[14:10] <didrocks> zyga: no, it can clearly access the file
[14:11] <didrocks> [pid 22370] access("/home/didrocks/.config/gtk-3.0/settings.ini", F_OK) = 0
[14:11] <didrocks> [pid 22370] open("/home/didrocks/.config/gtk-3.0/settings.ini", O_RDONLY) = 10
[14:17] <jdstrand> didrocks: it sounds like the one where it reads the file is not running under confinement
[14:18] <jdstrand> didrocks: how are you launcing it? when it is running, what does 'ps auxwwZ' tell you the profile name is for that process?
[14:19] <didrocks> jdstrand: ohhhhhhhhhhhhhhhh, sorry to have bothered you, the snap path is still after the system one, well, scratch that…
[14:20] <jdstrand> heh, that would do it :)
[14:21] <didrocks> jdstrand: I was soooooooooooooooo puzzled
[14:21] <jdstrand> hehe :)
[14:23] <Tribaal> Chipaca: shhhh don't spill the beans about my master plan (yet) :)
[14:41] <cachio_> zyga, I left  a comment on https://github.com/snapcore/snapd/pull/3433
[14:41] <mup> PR snapd#3433: tests: restoring the /etc/environment and service units config for each test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3433>
[14:44] <cachio_> zyga, in the state dir we can store the snapd state, and also en env file and other stuff that could be needed independently
[14:57] <mvo> morphis: do you have a suse or fedora vm where snapd is not started by default? if you run there: "snapctl is-active snapd.service", what output do you get?
[14:59] <mvo> zyga: or you maybe -^ ?
[15:01] <psftw> is there an official AMI or method to produce one for ubuntu core?
[15:02] <psftw> I've googled a bit and saw this was announced in 2014, but couldn't actually find an AMI today
[15:03] <Pharaoh_Atem> mvo: why do we use /etc/environment for the snapd units in Ubuntu?
[15:04] <Pharaoh_Atem> in Fedora, we use /etc/sysconfig/snapd
[15:04] <Pharaoh_Atem> (if it exists)
[15:04] <Pharaoh_Atem> the Debianish counterpart would be /etc/default/snapd
[15:05] <Pharaoh_Atem> (though imo, /etc/default is a horrible name for this directory and what it does)
[15:06] <morphis> mvo: let me check
[15:07] <mvo> Pharaoh_Atem: this is used for a systemd environment, a typical use case is a system-wide proxy environment. its typically set there on debian/ubuntu. is /etc/environment not used in fedora at all?
[15:07] <mvo> morphis: thank you
[15:07] <Pharaoh_Atem> mvo: it exists, it's just empty
[15:07] <Pharaoh_Atem> in Fedora, we don't really use it
[15:08] <morphis> mvo: https://paste.ubuntu.com/24801073/
[15:08] <mvo> Pharaoh_Atem: if someone wants to configure a systemwide proxy (e.g. via http_proxy=http://proxy.internal) - whats the typcial way to do that?
[15:08] <cachio_> zyga, at the end I am implementing what you suggested
[15:08] <mvo> morphis: thank you
[15:08] <morphis> mvo: that is on opensuse
[15:09] <Pharaoh_Atem> mvo: you can set that in NetworkManager
[15:09] <Pharaoh_Atem> it applies network wide
[15:09] <Chipaca> Pharaoh_Atem: how?
[15:09] <mvo> Pharaoh_Atem: do people use this on server too via nmcli? mostly curious
[15:09] <Pharaoh_Atem> mvo: Yep
[15:09] <Pharaoh_Atem> it's the preferred way to manage networking since RHEL 7 / Fedora 16
[15:10] <Chipaca> Pharaoh_Atem: i mean, how does it set things "network wide", such that e.g. curl picks it up?
[15:10] <mvo> Pharaoh_Atem: thank you! yeah, my next question is the one that Chipaca already asked, i.e. what do we need to do in snapd to honor this :)
[15:10] <Pharaoh_Atem> afaik, it's exposed via pacrunner?
[15:11] <Pharaoh_Atem> and libproxy
[15:11] <Pharaoh_Atem> and a few other means
[15:13] <mvo> Pharaoh_Atem: thanks, sounds like we need to research that a bit deeper then, we definitely want to have seamless proxy support for nm
[15:14] <Pharaoh_Atem> I moved the snapd units to read /etc/sysconfig/snapd because you can set things other than proxy stuff to have snapd process it
[15:14] <Pharaoh_Atem> and since snapd doesn't support a config file, it's the best I have
[15:16]  * mvo nods
[15:16] <Chipaca> we'll have a config file someday
[15:17] <Chipaca> … but not today
[15:17] <Pharaoh_Atem> mvo: not to mention, I can also forbid things other than snapd from manipulating the file
[15:17] <Pharaoh_Atem> through SELinux (or in your case, AppArmor)
[15:17] <mvo> Pharaoh_Atem: heh, indeed!
[15:18] <Pharaoh_Atem> the SELinux policy module already does this by default for distros that use /etc/sysconfig (RH, SUSE, Gentoo, Arch) and /etc/default (Debian, Ubuntu)
[15:18]  * Pharaoh_Atem wishes /etc/default was renamed to /etc/sysconfig, as he thinks it's more accurate in purpose
[15:32] <mup> PR snapd#3440 closed: interfaces: move base declaration to the policy sub-package <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3440>
[15:34] <zyga> cachio_: thanks, I'll chek that out
[15:34] <morphis> Pharaoh_Atem: btw. you made any progress on snap-mgmt.sh?
[15:34] <zyga> mvo: let me check
[15:34] <zyga> mvo: I'm typing from suse :)
[15:34] <morphis> Pharaoh_Atem: mvo brought this up at https://forum.snapcraft.io/t/share-code-between-debian-postrm-purge-and-snap-mgmt-sh/915/2 earlier today
[15:34] <Pharaoh_Atem> morphis: I made changes but no one tested to tell me if it's all good yet
[15:35] <Pharaoh_Atem> morphis: I submitted updates to snapd in Fedora that have been sitting in updates-testing with more changes
[15:35] <morphis> Pharaoh_Atem: ah nice! based on 2.26.4?
[15:35] <Pharaoh_Atem> not yet
[15:35] <Pharaoh_Atem> I wanted to know whether snap-mgmt.sh does all the things right first
[15:36] <Pharaoh_Atem> if there's something to fix, I was going to bundle it with snapd 2.26.4 update
[15:36] <Pharaoh_Atem> snapd-2.26.3-3.fc{24,25,26} is the current build
[15:36] <Pharaoh_Atem> the last time you gave me feedback was a month ago
[15:38] <zyga> pedronis: hey, I'm looking at the assertion response but I think it was actually easier first time around
[15:38] <zyga> pedronis: it seems that now I cannot just use Client().Debug() as I need to poke at headers and fire a custom decoder
[15:38] <morphis> Pharaoh_Atem: hm, then I forgot to press the button
[15:38] <zyga> pedronis: where all I want is the simple string for security team to review
[15:38] <morphis> but I've tested 2.26.3 and it was working but left an empty /var/lib/snapd dir
[15:38] <zyga> pedronis: I adapted the code to load assertion from the state as suggested
[15:39] <zyga> pedronis: am  I missing something simple that lets me just access the response data as-is?
[15:39] <Pharaoh_Atem> morphis: even 2.26.3-3?
[15:40] <morphis> zyga, mvo, Pharaoh_Atem: can you guys give a vote on https://github.com/snapcore/snapd/pull/3365 by your EOD?
[15:40] <mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
[15:40] <morphis> Pharaoh_Atem: hm, let me power up my fedora VM and check
[15:40] <coreycb> is there any way to share files among different parts in a snap?  for example I want to use the dump plugin to dump patches. and then in another part use those patches to patch upstream code.
[15:40] <zyga> morphis: maybe, I'll try :/
=== chihchun is now known as chihchun_afk
[16:06] <coreycb> ok i answered my question. yes it's possible to share files amoung parts. was having trouble getting it going due to my own error.
[16:09] <mup> PR snapd#3442 opened: snap: ensure security polices are re-created <Created by mvo5> <https://github.com/snapcore/snapd/pull/3442>
=== mpt_ is now known as mpt
[16:37]  * zyga feels so-so and goes back to sleep
[16:38] <pedronis> zyga: sorry, I forgot about Client.Debug, what you were doing make sense, though you probably want to add a level more of indirection
[16:38] <pedronis> {"base-declaration": ... } or something
[16:49] <cachio_> zyga, change pushed
[16:50] <cachio_> zyga, question, how do you usually set a dependency between branches?
[16:56] <Chipaca> so... i have a first pass at the services branch
[16:56] <Chipaca> https://github.com/snapcore/snapd/compare/master...chipaca:snap-services
[16:56] <Chipaca> one thing i'm unsure about
[16:56] <Chipaca> is the lack of overlord in that code :-)
[16:56] <Chipaca> niemeyer: is that ^ how you imagined it working, or were you thinking that this would happen via tasks?
[16:57] <niemeyer> Chipaca: Sounds like we can start without tasks, and move there if/when we need to
[17:11] <Chipaca> niemeyer: excellent
[17:11] <Chipaca> but now eod
=== JanC_ is now known as JanC
[17:26] <morphis> Pharaoh_Atem: 2.26.3-3 still gives me the empty /var/lib/snapd
[17:26] <Pharaoh_Atem> anything in the logs that indicate why?
[17:27] <morphis> niemeyer: you have time to approve https://github.com/snapcore/snapd/pull/3365 today?
[17:27] <mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
[17:27] <morphis> Pharaoh_Atem: not really
=== chihchun_afk is now known as chihchun
[17:30] <morphis> Pharaoh_Atem: will have a more close look tomorrow morning
[17:30] <Pharaoh_Atem> okay, cool, thanks
[17:33] <kyrofa> sdrobertw, I know how that goes! Thanks for keeping me on the loop :)
[17:34] <kyrofa> sdrobertw, the idea was raised to put the series on https://www.96boards.org/projects/ . What do you think?
[17:36] <sdrobertw> There is an AWS live stream going on right now (around IoT) for anyone who is interested: https://live.awsevents.com/IoTevent
[17:40] <ogra> jdstrand, https://dashboard.snapcraft.io/dev/snaps/7788/rev/1/ one for you :)
[17:41] <ogra> (finally an ubuntu core board with proper SATA and gigabit ethernet ;) )
[17:41] <ogra> (and it uses linux-generic-bbb!)
[18:26] <jdstrand> ogra: done
[18:27] <ogra> whee !
[18:27] <ogra> i guess auto-approavl only after the next review-tools update as usual ?
[18:28] <niemeyer> morphis: Yes, I can look again
[18:28] <niemeyer> morphis: What's the status there?  I've seen conversations about it in the last couple of days
[18:29] <jdstrand> ogra: yes. I updated the tools, but ping me until it auto-updates
[18:29] <jdstrand> (we need a store sync)
[18:29] <ogra> jdstrand, no hurry, i'm fine with waiting
[18:34] <sdrobertw> kyrofa: would love to have the series on project page.
[18:35] <sdrobertw> kyrofa, is there any way you could send me an email with all links/resources consolidated into one place? robert.wolff@linaro.org
[18:36] <sdrobertw> This would make things much easier for me
[18:37] <kyrofa> sdrobertw, sure, though that sounds like the stuff that will be contained in the pull request I make to get it into projects. Want me to just do that?
[18:38] <kyrofa> (happy to send an email as well)
[18:41] <sdrobertw> kyrofa: sure! That work just fine actually. Please let me know if I can help with anything. You will be second person to test this process.
[18:42] <sdrobertw> It is all very new
[18:42] <kyrofa> sdrobertw, seems well-documented so far
[18:42] <sdrobertw> :)
[18:46] <niemeyer> morphis: LGTM... tests are broken with an error that seems real
[19:15] <morphis> niemeyer: yeah saw that already, comes from a merge with master, will fix tomorrow
[19:16] <morphis> niemeyer: thanks!
[19:46] <niemeyer> morphis: np, and thanks for pushing it forward
=== chihchun is now known as chihchun_afk
[21:19] <sergiusens_> niemeyer: hey, if you are still on, can I get your insight on this one https://forum.snapcraft.io/t/snapcraft-build-on-hint-for-builders/939?u=sergiusens ? I am trying to be future proof here and the build.snapcraft.io guys are interested in this to start supporting more arches out of the box
=== sergiusens_ is now known as sergiusens
=== akash_ is now known as akash
=== psftw_ is now known as psftw
=== TinoGuest_ is now known as TinoGuest
=== cargonza_ is now known as cargonza
=== diddledan_ is now known as diddledan
=== tvoss_ is now known as tvoss
=== ulkesh_ is now known as ulkesh
[22:13] <mup> PR snapcraft#1349 closed: plugins: clarify wording of cross-compilation unsupported error <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1349>
[22:28] <mup> PR snapcraft#1356 closed: common: find data files via sys.prefix <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1356>