[00:28] <diddledan> kyrofa: I like the "potentially bonkers" comment :-D
[00:29] <diddledan> I'm sat here giggling to myself over that :-p
[02:10] <mup> Bug #1745528 opened: snap icon available <Snappy:New> <https://launchpad.net/bugs/1745528>
[02:58] <bashfulrobot> Anyone around for a few (hopefully) quick questions?
[02:59] <bashfulrobot> If not, I'll pop back in the AM (PST).
[02:59] <bashfulrobot> TY
[05:17] <ikey> mornin
[05:56] <mborzecki> morning
[06:56] <zyga-ubuntu> good morning
[06:56] <zyga-ubuntu> FYI, I need to take today off,
[06:56] <zyga-ubuntu> last day of winter holidays for kids and I need to spend some time with them
[06:58] <mup> PR snapd#4532 closed: store: use the "publisher" when populating the "publisher" field  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4532>
[06:58] <mborzecki> zyga-ubuntu: hey, morning
[06:59] <zyga-ubuntu> hey!
[06:59] <zyga-ubuntu> I slept for hoooours
[06:59] <zyga-ubuntu> I woke up later at night and just briefly wandered here
[06:59] <mborzecki> yeah, today is monday you know? :)
[06:59] <zyga-ubuntu> man, I missed that sleep
[06:59] <zyga-ubuntu> haha!
[06:59] <zyga-ubuntu> good one :) I tried to fool our daughter a moment ago
[06:59] <mborzecki> haha
[07:00] <mborzecki> my kids are starting the break on monday ;)
[07:01] <zyga-ubuntu> oh, right :)
[07:01] <mborzecki> zyga-ubuntu: btw. sent you a small PR for snapd aur package: https://github.com/bboozzoo/aur-snapd/pull/1, nothing fancy
[07:01] <mup> PR bboozzoo/aur-snapd#1: snapd: fix generation of systemd unit files, use /etc/default/snapd as environment file <Created by bboozzoo> <https://github.com/bboozzoo/aur-snapd/pull/1>
[07:03] <zyga-ubuntu> looking
[07:03] <zyga-ubuntu> done
[07:04] <mborzecki> zyga-ubuntu: can you belive that indent is no longer package in arch?
[07:04] <mborzecki> i played with arch CI yday and i was like 'wtf?' when it failed on installing indent
[07:08] <zyga-ubuntu> mborzecki: indent is a weird tool, I'd like to migrate away from it
[07:08] <zyga-ubuntu> and use clang-format
[07:08] <zyga-ubuntu> not only more widely available but much better output
[07:08] <mborzecki> zyga-ubuntu: briefly thought about dumping autotools in favor of cmake or meson, though the latter is not availble in 14.04 :/
[07:11] <mborzecki> `yaml.reader.ReaderError: unacceptable character #xdce2: special characters are not allowed` on arch tests/main/snap-info
[07:21] <zyga-ubuntu> mborzecki: I cannot stand cmake syntax, I think ultimately what we have is bad but the alternatives are not widely available or are not fantastically better
[07:21] <zyga-ubuntu> mborzecki: that's a curious one
[07:21] <zyga-ubuntu> I ran into it 100s of times
[07:21] <zyga-ubuntu> but it's a race somewhere
[07:21] <zyga-ubuntu> memory is corrupted
[07:21] <zyga-ubuntu> I dumped the yaml text when this happened
[07:22] <zyga-ubuntu> and I got random stuff all the time
[07:22] <zyga-ubuntu> it only ever surfaced on arch
[07:22] <zyga-ubuntu> perhaps due to a combination of compiler settings not used by other distributions
[07:22] <zyga-ubuntu> I didn't get to the bottom of it
[07:28] <zyga-ubuntu> try printing the buffer, I'm curious what you will get
[07:28] <mborzecki> zyga-ubuntu: found a related debian bug reported by Chipaca https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806826
[07:29] <mborzecki> anyways, reading the patch explains why pretending we're using a utf8 locale fixes the problem
[07:29] <mborzecki> `LC_ALL=en_US.utf8 python3 check.py < out` works just fine
[07:46] <zyga-ubuntu> mborzecki: how does python come into the picture?
[07:46] <zyga-ubuntu> mborzecki: I thought this was from golang
[07:46] <zyga-ubuntu> mvo: hey
[07:46] <zyga-ubuntu> mvo: I'm off today
[07:46] <zyga-ubuntu> need to leave in a few minutes anyway
[07:47] <mborzecki> zyga-ubuntu: no it's python3, there's a check.py script in tests/main/snap-info, we basically dump `snap info` output and then verify it with the script, and it chokes on the unicode up arrows
[07:49] <mvo> zyga-ubuntu: hey, enjoy your day off
[07:49] <mborzecki> i still think that we should not produce any unicode output if locale does not support unicode
[07:50] <mvo> mborzecki: not knowing much context I agree
[07:50] <mvo> mborzecki: but that seems to be a broader issue, iirc our progress is also quite liberal with non ascii chars
[07:52] <mborzecki> mvo: the tests are using LANG=C.UTF-8 which is in a patched glibc, this does not work on arch, so the default ends up being C, `snap info` uses unicode characters in the output, the script checking `snap info`'s output is python3 which does magic behind the scenes depending on your locale, part of it i have already fixed, the other part makes pyyaml throw an exception when reading yaml input (ie.. snap info
[07:52] <mborzecki> output dump)
[07:54] <zyga-ubuntu> mborzecki: not the same bug then
[07:56]  * zyga-ubuntu -> afk
[07:56] <mborzecki> zyga-ubuntu: not exactly, the patch does more than is written in the bug report :P
[08:00] <mvo> mborzecki: right, yeah, python is unhappy if the encoding does not match, I'm not surprised. a shames that C.utf-8 is not standarized
[08:05] <mborzecki> pstolowski: morning
[08:05] <pstolowski> hey!
[08:20] <kalikiana> o/
[08:20] <kalikiana> morning, mborzecki
[08:21] <mborzecki> kalikiana: hey
[08:53] <Chipaca> mo'in
[08:53] <ikey> rawr
[08:54] <Chipaca> if you say so
[09:02] <mvo> hrm, hrm, looks like master is broken right now
[09:02] <mvo> search test failing
[09:06] <Chipaca> mvo: D:
[09:06] <mvo> Chipaca: unless you are looking into this already I will do so now
[09:06] <Chipaca> mvo: I was not
[09:22] <mborzecki> store related tests are randomly failing?
[09:27] <mup> PR snapd#4549 opened: tests: update "searching" test to match store changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/4549>
[09:29] <mvo> mborzecki: hopefully not randomly but yes, everything is broken right now
[09:29] <mvo> mborzecki: see PR above
[09:30] <mborzecki> mvo: i've restarted #4487 5-6 times already, not counting the searching thing, there's failures in fetching snaps (either in prepare, or some refresh tests)
[09:30] <mup> PR #4487: cmd/snap: snap refresh --time with new and legacy schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>
[09:30] <mvo> mborzecki: oh, more? sucks
[09:31] <mvo> mborzecki: sounds like a reason to talk to the good people from the store team :)
[09:31]  * mvo looks at the results
[09:34] <mborzecki> mvo: regarding 4549, database is no longer listed in sections :/ any clue why?
[09:35] <mvo> mborzecki: yeah, I just talked to the store team - it just got removed, there is a set of new sections
[09:36] <mborzecki> hm can they confirm that all the sections are listed in `snap find --section`?
[09:39] <mvo> mborzecki: I think that is the case
[09:41] <mvo> mborzecki: in your current run it is just "searching" what failed so far
[09:41] <mvo> mborzecki: so fingers crossed :)
[09:41] <mborzecki> mvo: btw: maciek@corsair:github.com/snapcore/snapd (git)-[master] ./test-snap find --section=foobar
[09:41] <mborzecki> No matching snaps for ""
[09:41] <mvo> yeah, we should tweak the error
[09:41] <mvo> to include that the search was in a section
[09:41] <mborzecki> mvo: i can look into it
[09:42] <mvo> and/or show that there is no such section
[09:42] <mvo> not sure what metadata we get from the store
[09:42] <mvo> thanks mborzecki
[09:44] <Deknos> aloha, is there a bugtracker for snaps anywhere?
[09:45] <Deknos> i tried minikube and kubectl snaps on ubuntu 17.10 and debian, but it did not work. manual installation works, though. any idea how to write a issue/bug for snap?
[09:51] <mvo> Deknos: is this a issue with the snaps themself? or an issue with the snapd, i.e. can you not use any snaps on your system? if the former, there is a "contact" field in the "snap info" output that you can use to get in touch with the snap provider
[09:51] <mvo> Deknos: there is also forum.snapcraft.io where a lot of the snap developers hang around
[10:03] <Deknos> well it seems to have to do sth with the installation since manual installation works, but via snaps setup of the vms crash
[10:03] <Deknos> thanks, i'll try the forum.
[10:04] <mup> Bug #1669012 changed: Can't reinstall a snap already installed switching confinement mode <amd64> <apport-bug> <xenial> <snapd:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1669012>
[10:09] <mvo> Deknos: good luck!
[10:22] <mborzecki> mvo: do you think a separate error message if no matches in section were found makes sense? https://paste.ubuntu.com/26463360/
[10:23] <mvo> mborzecki: this looks good to me
[10:24] <mborzecki> mvo: well i'm counting on sections being cached (which they seem to be) as this does an additional cli.Sections() call :)
[10:48] <mup> PR snapd#4549 closed: tests: update "searching" test to match store changes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4549>
[11:04] <niemeyer> Mornings
[11:04]  * ikey plays "Walking on sunshine" in response to "morning"
[11:10] <niemeyer> ikey: I don't think I had ever seen that
[11:11] <ikey> https://www.youtube.com/watch?v=iPUmE-tne5U
[11:11] <ikey> ^^
[11:12] <ogra_> ♬ ♪♩♬
[11:13] <mup> PR snapd#4550 opened: cmd/snap: improve output when snaps were found in a section or the section is invalid <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4550>
[11:17] <niemeyer> ikey: Yeah, I just watched it.. not sure what to take from it.. my life will probably never be the same again
[11:17] <ikey> most welcome lol
[11:19] <ikey> so i tried jdstrand's recommendations this morning with snapd/apparmor
[11:19] <ikey> apparmor was most unhappy
[11:19] <ikey> gonna have to bite the bullet and just suck it up with the whole 4.8 requirement
[11:37] <ogra_> niemeyer, would you mind adding a "yes this is right/no, nonsense" answer to https://forum.snapcraft.io/t/what-happens-if-an-architectures-all-snap-becomes-arch-specific/3675 ?
[11:38] <niemeyer> ogra_: Will have a look
[11:38] <ogra_> thanks
[11:38] <niemeyer> mborzecki: About your question on arch yesterday,
[11:38] <niemeyer> mborzecki: we never had our own arch image, I believe
[11:38] <niemeyer> mborzecki: What likely happened was that you were using an arch image provided by Linode, which was obsoleted
[11:38] <mborzecki> niemeyer: yes, that was the case, fortunately spread -vv contains all the info about machine templates i need ;)
[11:39] <niemeyer> mborzecki: I find a bit surprising to be honest
[11:39] <niemeyer> mborzecki: I mean, anyway using that image is now broken
[11:39] <niemeyer> anyone
[11:39] <niemeyer> Looking at https://www.linode.com/distributions, the current one seems to be 2018.01.02
[11:40] <mborzecki> niemeyer: switched to that version already
[11:54] <cachio_> mvo, https://paste.ubuntu.com/26461903/ https://paste.ubuntu.com/26461941/
[11:54] <cachio_> mvo I see those errors on rpi2 and 3 when I refresh from stable to beta
[11:56] <mvo> cachio_: thanks, looking
[11:58] <mvo> cachio_: *hrm* smells like an issue with writable-path, let me dig
[12:00] <mvo> cachio_: out of curiosity, this did not happen on an x86 core device?
[12:00] <cachio_> mvo, no
[12:01] <cachio_> mvo, just on the pi
[12:01] <mvo> interessting
[12:01] <mvo> cachio_: and you said you refreshed from the previous stable, correct? a fresh image from stable and then refresh to beta?
[12:02] <cachio_> mvo, I used the stable from http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
[12:02] <cachio_> mvo, the factory one
[12:02] <mvo> cachio_: thank you, I give it a go
[12:05] <Chipaca> I'm not going to be here for the standup; I'm off to a school meeting (that'll probably extend into the afternoon) (I'll retroactively file for pto if it does)
[12:07] <mvo> Chipaca: thanks and see you
[12:08] <Chipaca> mvo: still here for another little while though :-)
[12:08] <Chipaca> meeting is 13:30, google says 30 minutes of driving (but midday rush is a thing)
[12:11] <mup> Issue snapcraft#1886 opened: Support for yarn --extra-args <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1886>
[12:21] <mvo> cachio_: confusing, I just did install of the stable image, refreshed mnaully to beta rebooted and systemctl list-timers hows me the timer
[12:21] <mvo> cachio_: can you ssh into the board and run "systemctl list-timers --all" and paste that please?
[12:21] <cachio_> sure
[12:21] <mup> PR snapd#4551 opened: interfaces: do not auto-connect manually disconnected interfaces <Created by stolowski> <https://github.com/snapcore/snapd/pull/4551>
[12:22] <cachio_> mvo, https://paste.ubuntu.com/26463820/
[12:25]  * kalikiana going to go for an earlier lunch in a few
[12:33] <mup> PR snapd#4552 opened: testutil: do not use echo for printing potentially conflicting arguments <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4552>
[12:33] <mvo> cachio_: hm, how strange. in a meeting now, lets talk in a bit
[12:36] <cachio_> mvo, np
[12:40] <mup> PR snapd#4547 closed: snap: fix race in `snap run --strace` <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4547>
[12:47] <ikey> will we have a jdstrand around today? primarily so i know in order to get my best begging face on
[12:47]  * ikey readies a spray bottle for the fake tears
[13:21] <diddledan> ikey: https://youtu.be/elmwnUOtxu8?t=76
[13:22] <ikey> hah perfect
[14:00] <mvo> cachio_: what is the output of "systemctl status snapd.snap-repair.timer" on the pi2?
[14:00] <mvo> cachio_: (or pi3)
[14:01] <pstolowski> cachio_, do you have any gsettings branch I can look at? or can describe the test case you want to achieve?
[14:01] <cachio_> https://paste.ubuntu.com/26464226/
[14:01] <cachio_> pstolowski, yes, on sec
[14:02] <cachio_> pstolowski, https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings
[14:02] <cachio_> there is a snap already uploded to the store
[14:03] <cachio_> mvo,  https://paste.ubuntu.com/26464226/
[14:10] <pstolowski> cachio_, thanks, i'll have a lunch now and will take a look afterwards
[14:10]  * pstolowski lunch
[14:13] <cachio_> pstolowski, sure, just ping me
[14:18] <mvo> cachio_: thanks, I'm on it
[14:22] <mvo> cachio_: I think I found the issue and pushed a fix to the core build, will be part of ~rc2
[14:22] <mup> PR core#79 opened: 26-fixup-core.chroot: fix snapd.snap-repair.timer enable symlink <Created by mvo5> <https://github.com/snapcore/core/pull/79>
[14:23] <cachio_> mvo, great
[14:23] <cachio_> mvo, which is the problem that you found?
[14:24] <mvo> cachio_: its a problem with the writable-path stuff: https://github.com/snapcore/core/pull/79/commits
[14:24] <mup> PR core#79: 26-fixup-core.chroot: fix snapd.snap-repair.timer enable symlink <Created by mvo5> <https://github.com/snapcore/core/pull/79>
[14:25] <cachio_> mvo, ohh, tx
[15:19] <kalikiana> kyrofa: Hey
[15:20] <kalikiana> kyrofa: Can I pick your brain on the checker callable used in the grammar? I was looking into "to" for strings, ie. the source property, and it adds ":armhf" and such because ToStatement doesn't know about packages or other properties
[15:26] <kyrofa> kalikiana, hahaha
[15:26] <kyrofa> Yeah we probably don't want that eh?
[15:27] <kyrofa> kalikiana, do you want to HO?
[15:28] <kalikiana> kyrofa: Yeah, we can have a quick chat now if you have time
[15:30] <kyrofa> kalikiana, I do
[15:30] <kalikiana> kyrofa: Shall we use the weekly?
[15:30] <kyrofa> weekly?
[15:30] <kyrofa> Yep
[15:30] <kyrofa> Oh wait, no
[15:30] <kyrofa> kalikiana, any chance you have skype?
[15:30] <kyrofa> I'm so stinking sick of chrome
[15:30] <kalikiana> kyrofa: I'm seeing a trend here :-D
[15:30] <kyrofa> Let's use that. Or talky
[15:31] <kyrofa> Is talky better?
[15:31] <kyrofa> I really don't care. Just something that doesn't require me to open chroem
[15:31] <kalikiana> kyrofa: Either one works for me
[15:31] <kalikiana> lol
[15:31] <kyrofa> Let's try talky. Hold on
[15:38] <pstolowski> cachio_, test-snapd-gsettings is the snap you meant?
[15:38] <cachio_> yes
[15:38] <cachio_> pstolowski,
[15:41] <pstolowski> cachio_, oh wow, that snap is huge
[15:42] <cachio_> pstolowski, yes :s
[15:46] <pstolowski> cachio_, I see more plugs than just gsettings in its snap.yaml; is this intended to be used for many tests?
[15:47] <cachio_> it is pluggin also desktop
[15:47] <cachio_> pstolowski, it is because it needs to access to destop files
[15:51] <bloodearnest> hey folks, is there any way to call setuid() at all from a strictly confined snap? E.G. to switch to the 'daemon' or 'nobody' user, which is in the core snap, I don't need to create a user (just can't run as root)
[15:51] <mup> Issue snapcraft#1887 opened: Update to ROS2 Ardent <Created by kyrofa> <https://github.com/snapcore/snapcraft/issue/1887>
[15:52] <bloodearnest> I thought there was some seccomp/apparmor provision for this, but I can't find any documentation on it
[15:55] <kyrofa> bloodearnest, no, it's in the design phases as I understand it, jdstrand will know more/all
[16:03] <pstolowski> cachio_, I think you could get rid of python-gi dependency (which already pulls a lot of stuff). glib comes with a gsettings cli that can query and set settings db
[16:05] <pstolowski> kyrofa, hey, where can I lookup the definition of desktop-gtk3 part? I knew it but forgot..
[16:06] <kyrofa> pstolowski, snapcraft define
[16:06] <kyrofa> pstolowski, or do you want to update it?
[16:06] <pstolowski> kyrofa, no, just check it out
[16:06] <kyrofa> Yeah, that should work
[16:06] <pstolowski> kyrofa, thanks!
[16:09] <jdstrand> bloodearnest: not yet. it is on the roadmap. I suggest you keep an eye on https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461
[16:10] <bloodearnest> kyrofa: jdstrand: ok, thanks
[16:10] <bloodearnest> fwiw, this make squid and postgres very difficult to run, as they both refuse to run as uid 0
[16:10] <jdstrand> bloodearnest: note this is something I'd really like to see done, but it isn't prioritized high atm. the design is there and approved (which is good), but it is slow going
[16:11] <jdstrand> bloodearnest: but we'll get to it
[16:11] <jdstrand> bloodearnest: I think someone posted in the forum what to do with postgresql
[16:11] <jdstrand> bloodearnest: there is also the snapcraft preload plugin which LD_PRELOADs to make them no-ops
[16:12] <jdstrand> but like you say, the correct thing is to have this support. we'll get there
 pstolowski, ok, I'll try that
 pstolowski, apart of that, any idea about hot make it work on linode?
 it was failing trying to create many directories
 but then can't access to the gsettings user keys
 it is just reading the values that come inside the snap
 but when I try to update and see the change, the values have not been changed
[16:14] <pstolowski> cachio_, and you depend on desktop-gtk3 path to have the entire environment and schemas set, correct?
[16:14] <bloodearnest> jdstrand: ok, I'll check the forums for that. I don't think the preload plugin helps here - postgres has a hard coded if (geteuid() == 0), it doesn't try to drop privs itself, but forces you to do it
[16:14] <cachio_> pstolowski, I got disconnected, sorry
[16:14] <cachio_> pstolowski, yes
[16:14] <jdstrand> bloodearnest: someone specifically patched postgresql for the postgresql snap
[16:14] <cachio_> I copied that from the gnome-calculator app
[16:14] <jdstrand> bloodearnest: so yes, you might have to patch. for now. but we'll get there
[16:15] <pstolowski> cachio_, so I think you should try to remove it as it pulls half of the desktop stuff obviously, and take a look at https://github.com/Ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports
[16:15] <pstolowski> cachio_, this is part of the desktop-launch script afaict
[16:15] <pstolowski> cachio_, look at the gsettings stuff there
[16:15] <pstolowski> cachio_, you can basically replicate it
[16:16] <cachio_> pstolowski, ok, but the problem is that all the desktop part is not in the linode images
[16:17] <cachio_> pstolowski, so, the mappings in this script don't work
[16:17] <pstolowski> cachio_, yeah but we don't need it afaict
[16:18] <blackboxsw> pedronis: hi any suggestions on https://forum.snapcraft.io/t/seed-yaml-documentation/3050/4     maybe --classic snaps can't be seeded ?
[16:18] <pstolowski> blackboxsw, he is off, back next week
[16:19] <blackboxsw> ahh excellent pstolowski thanks for the heads up
[16:20] <cachio_> pstolowski, ok, I'll try to clean this but first I need to figure out how to fix the current issue
[16:20] <cachio_> pstolowski, for example
[16:20] <pstolowski> cachio_, afaiu the snap should have glib as the base dependency. all the schema stuff is build in $SNAP_USER_DATA/.local/share (we should replicate this part of the script)
[16:21] <pstolowski> cachio_, and the test could use gsettings binary from the snap, no custom python to query gsettings data
[16:22] <pstolowski> cachio_, we should be able to test gsettings with just cli tools, no need for gtk and all the desktop stuff
[16:22] <cachio_> pstolowski, ok, I'll try this
[16:23] <pstolowski> cachio_, i'm not sure about the dconf part of the interface, it has a dbus snippet
[16:23] <pstolowski> cachio_, there is a dconf binary that can also query settings. but i don't know if it touches dbus
[16:24] <cachio_> pstolowski, no idea
[16:24] <ikey> so jdstrand to clarify, how am i going to move forward with the steam thing?
[16:24] <pstolowski> cachio_, if not, then we can use dbus-send cli or something else (not to pull python)
[16:25] <ikey> cuz that much i failed as yet to discern
[16:25] <ikey> but gathered "pending voodoo" being the trend
[16:26] <pstolowski> cachio_, well, just the bare python itself is not too bad, problems start when we pull too much stuff
[16:27] <cachio_> pstolowski, yes, agree
[16:27] <cachio_> pstolowski, I tried to simulate what the desktop team do but it is so complex for our tests
[16:30] <jdstrand> ikey: I'd like to get some feedback on cx vs px. I also want to come up with the rules to give you, then tell you the course forward
[16:30] <jdstrand> ikey: I have some work to do to give you all that
[16:30]  * jdstrand is in meetings today, but hopes to pick this up this afternoon
[16:31] <pstolowski> cachio_, $SNAP/usr/bin/gsettings cli is a good enough test as it uses the same glib API that gui apps would use
[16:34] <pstolowski> cachio_, but as I say I don't know about the dbus part of the policy for dconf and what would be a good test for it (other than sending a dbus message manually with dbus-send or some such), perhaps someone from desktop team can explain
[16:37] <ikey> jdstrand, ok
[16:37] <ikey> i think ill have to pull my snaps out of the store
[16:37] <ikey> as i cant update them
[16:38] <jdstrand> ikey: ? why?
[16:38] <cachio_> pstolowski, ok, I'll start researching on this
[16:38] <ikey> because to develop them any further i need working strict confinement, and they're bugged out in their current state
[16:38] <ikey> and nobody else will have the interface they need to run them properly
[16:38] <ikey> etc
[16:38] <jdstrand> ikey: you could set 'grade: devel' and not push them to stable
[16:39] <ikey> ive not pushed to stable
[16:39] <ikey> because of my permanent chicken / egg cycle with this snap :P
[16:39] <jdstrand> I don't know if that is helpful or not, but an option
[16:41] <ikey> basically because i cant update them i cant testify to their security status
[16:41] <ikey> and would be more comfortable with withdrawing them entirely
[16:41] <ikey> as it reflects poorly on solus
[16:41] <cachio_> pstolowski, another question
[16:42] <cachio_> pstolowski, https://paste.ubuntu.com/26465150/
[16:42] <cachio_> hidraw should be just for gadgets?
[16:42] <jdstrand> well, regardless, I'll be working on this to give you what you need
[16:42] <cachio_> pstolowski, or it should be visible in any core?
[16:43] <cachio_> pstolowski, based on that declaration
[16:43] <mup> PR core#79 closed: 26-fixup-core.chroot: fix snapd.snap-repair.timer enable symlink <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/79>
[16:43] <ikey> jdstrand, how would i go about unpublishing snaps..?
[16:43] <ikey> if such a concept exists
[16:45] <ikey> alternatively ill refresh the snaps without any of the new interfaces.. but ofc they remain broken
[16:45] <ikey> this is too much thinking for a friday -_-
[16:45] <jdstrand> ikey: I'm not sure tbh. perhaps roadmr or sergiusens can comment?
[16:47] <ikey> what would need to be done on your side out of interest?
[16:47] <ikey> re: enabling the globbing stuffs
[16:48] <pstolowski> cachio_, this declaration says the slot can be on gadget or core, but i've no idea whether this is correct or not
[16:51] <roadmr> ikey: the best way IIRC is to push a new snap and release that to the channel where the snap-you-want-unpublished is
[16:52] <roadmr> ikey: effectively superseding it really. Once it's not published on any channels, it'll be uninstallable for anyone, not even by specifying --revision
[16:52] <ikey> i mean like all revisions
[16:53] <roadmr> ikey: oh like just removing them from existence entirely? I don't think that can be done :( sorry
[16:53] <ikey> ah ok
[16:53] <roadmr> ikey: another way is to close all channels. snapcraft close stable
[16:53] <ikey> so ill need to push a gimped build then
[16:53] <ikey> roadmr, unfortunately i dont have a stable channel
[16:53] <roadmr> same for beta, edge, candidate.
[16:54] <roadmr> ikey: if the snap is on e.g. edge, you can close that too
[16:54] <ikey> ok ty
[16:58] <mup> PR snapd#4553 opened: many: add io.snapcraft.Settings to `snap userd` <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4553>
[16:59]  * kalikiana going to wrap up for the week shortly
[17:04] <pstolowski> eow, o/
[17:06] <mup> PR snapd#4554 opened: test build - ignore <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4554>
[17:08] <cachio_> ogra_, hey
[17:08] <cachio_> could you please confirm if the hidraw interface is available on any core device
[17:09] <cachio_> ogra_, this is the declaration https://paste.ubuntu.com/26465150/
[17:09] <mup> PR snapd#4553 closed: many: add io.snapcraft.Settings to `snap userd` <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4553>
[17:09] <mup> PR snapd#4554 closed: test build - ignore <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4554>
[17:10] <mvo> cachio_: I get dinner now, but the failure in 4073 is strange still :/
[17:11] <cachio_> mvo, checking
[17:12] <mup> PR snapd#4538 closed: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <Closed by ikeydoherty> <https://github.com/snapcore/snapd/pull/4538>
[17:22] <ogra_> cachio_, nops, uhid is there but not hidraw
[17:23] <ogra_> cachio_, so core does not have it declared atm
[17:23] <ogra_> (the core snap that is)
[17:26] <cachio_> ogra_, ok
[17:26] <cachio_> ogra_, tx
[17:26] <ogra_> s/declared/exposed/
[17:26] <ogra_> np
[17:29] <cachio_> ogra_, not sure why not
[17:29] <cachio_> ogra_, it should
[17:29] <ogra_> ogra@localhost:~$ snap interfaces|grep hid
[17:29] <ogra_> :uhid
[17:29] <ogra_> well, thats what i get
[17:30] <ogra_> (on all core devices running here)
[17:30] <niemeyer> This is looking smooth... https://travis-ci.org/snapcore/snapd/jobs/333816377
[17:50] <kyrofa> jdstrand, got a question for you. I have a user who's snap needs to be disabled/enabled _every boot_, otherwise every daemon prints this: "cannot change profile for the next exec call: No such file or directory"
[17:50] <kyrofa> jdstrand, can you think of a reason for this?
[17:50] <kyrofa> zyga-ubuntu, that ^ may interest you as well
[17:51] <zyga-ubuntu> kyrofa: ack
[17:51] <zyga-ubuntu> kyrofa: daemon should not do that
[17:51] <zyga-ubuntu> kyrofa: on restart we reload profiles
[17:51] <zyga-ubuntu> kyrofa: this smells like a container with apparmor disabled
[17:51] <zyga-ubuntu> kyrofa: fighting over apparmor from the parent host
[17:52] <zyga-ubuntu> kyrofa: if I'm right I'll get a t-shirt with some silly container stacking apparmor text
[17:52] <kyrofa> zyga-ubuntu, all I know so far is that it's hosted on aruba.it
[17:52] <zyga-ubuntu> yeah
[17:52] <kyrofa> zyga-ubuntu, if you're up for jumping into the discussion, it's here: https://github.com/nextcloud/nextcloud-snap/issues/425
[17:52] <zyga-ubuntu> looks like it
[17:52] <mup> PR snapd#4553 opened: many: add io.snapcraft.Settings to `snap userd` <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4553>
[17:52] <mup> PR snapd#4554 opened: test build - ignore <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4554>
[17:52] <kyrofa> (including logs)
[17:53] <mup> PR snapd#4554 closed: test build - ignore <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4554>
[17:55] <kyrofa> Thanks zyga-ubuntu :)
[17:55] <zyga-ubuntu> my pleasure :)
[17:56] <zyga-ubuntu> I'm off today but back at my PC doing stuff so I can look for activity on that thread
[18:13] <mup> PR snapd#4553 closed: many: add io.snapcraft.Settings to `snap userd` <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4553>
[18:17] <mup> PR snapd#4546 closed: snap: tidy up top-level help output <Created by cjwatson> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4546>
[18:18] <mup> PR snapd#4555 opened: test -ignore <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4555>
[18:18] <zyga-ubuntu> mvo: what are you testing?
[18:19] <mup> PR snapd#4552 closed: testutil: do not use echo for printing potentially conflicting arguments <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4552>
[18:20] <mvo> zyga-ubuntu: I don't get why 4073 is failing
[18:23] <cachio_> mvo, debugging it
[18:23] <cachio_> mvo, it'll take a while
[18:23] <cachio_> mvo, everithing is slowwww
[18:25] <cachio_> mvo, https://paste.ubuntu.com/26465771/
[18:26] <cachio_> it is like we create the ubuntu core, something happens to the user
[18:26] <cachio_> I stopped the test just after we reboot the machine
[18:27] <cachio_> and I get that
[18:27] <cachio_> and before it works
[18:27] <mvo> cachio_: oh, interessting
[18:28] <mvo> cachio_: I wonder what in this PR broke it, it does not touch any of this
[18:31] <cachio_> mvo, the test user is not in cat /var/lib/extrausers/passwd | grep test
[18:31] <cachio_> not sure why
[18:36] <mvo> zyga-ubuntu: just fyi - I updated http://people.canonical.com/~mvo/tmp/snap-boot.svg this time with snaps, it shows that snap.mount runs before the two snaps (core, hello) are mount. the mountinfo file is https://paste.ubuntu.com/26465825/
[18:37] <jdstrand> kyrofa: I've not seen that, but it sounds like snap-confine is running and trying to change profile to the snap's profile, but that profile is not loaded
[18:37] <mvo> cachio_: its super strange, I had issue with my local spread (gustavo helped me fixing it) and now I will try to get to the bottom of it
[18:38] <zyga-ubuntu> mvo: oh, great, let me see
[18:38] <jdstrand> kyrofa: if it is happening on boot, that could be that the snap is starting before snapd starts and the apparmor init/unit isn't loading /var/cache/apparmor
[18:38] <cachio_> mvo, I am waiting to get a debug session
[18:38] <mvo> cachio_: thank you, keep me updated please, curious if you hvae any ideas
[18:38] <zyga-ubuntu> jdstrand: can we detect apparmor is not stacked inside a container?
[18:38] <jdstrand> kyrofa: restarting snapd should cause snapd to load all the profiles
[18:38] <cachio_> it is like for some reason the test user is not being added as a user in the files group gshadow passwd shadow
[18:38] <mvo> zyga-ubuntu: still two mounts though
[18:38] <zyga-ubuntu> inspecting
[18:38] <jdstrand> zyga-ubuntu: can you rephrase?
[18:39] <zyga-ubuntu> jdstrand: sure, sorry, let's say I use a privileged lxd container that doesn't use apparmor stacking, can I detect that somehow from inside the container?
[18:39] <jdstrand> kyrofa, zyga-ubuntu: *if* the snap is running in a container, it certainly seems plausible that the detection logic is not working right
[18:40] <zyga-ubuntu> mvo: question about the graph, what determines the width of a row?
[18:40] <zyga-ubuntu> they all seem to have the same width
[18:40] <zyga-ubuntu> is it "starting" or "finished"
[18:40] <zyga-ubuntu> is it possible that our tweaks on post-start run in parallel with snap mounts?
[18:41] <jdstrand> zyga-ubuntu: aiui, not as well as we should be able to. /lib/apparmor/functions has is_container_with_internal_policy() which is a hacky way of determining this
[18:41] <mvo> zyga-ubuntu: thats an interessting idea
[18:41] <zyga-ubuntu> jdstrand: thank you, let me read it
[18:43] <mvo> zyga-ubuntu: the man page claims that the ordering will be correct if one mount unit is below/above the mount hirarchy
[18:45] <mup> PR snapd#4555 closed: test -ignore <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4555>
[18:47] <jdstrand> kyrofa, zyga-ubuntu: this seems similar to https://irclogs.ubuntu.com/2018/01/09/%23ubuntu-devel.html#t03:34
[18:47] <jdstrand> I think jjohansen developed a patch for that for artful
[18:47] <jdstrand> kyrofa: what kernel was that on?
[18:48] <kyrofa> jdstrand, uncertain, I'll ask for a `snap version` run
[18:52] <zyga-ubuntu> mvo: yes but what about the extra scripts that run after that are defined in one mount unit
[18:55] <mvo> zyga-ubuntu: there is currently no extra script, its just shared,bind in the options
[18:57] <zyga-ubuntu> mvo: ahh
[18:58] <zyga-ubuntu> hmm hmm hmm
[18:58] <zyga-ubuntu> this makes litlte sense
[18:58] <zyga-ubuntu> would it bother you to drop the "shared" flag and rerun?
[18:58] <zyga-ubuntu> and see what we get in mountinfo please?
[18:58] <zyga-ubuntu> I'm suprprised you saw shared, in my testing shared was not working
[18:58] <zyga-ubuntu> can you tell me how to reproduce your setup?
[19:01] <mvo> zyga-ubuntu: sure, one sec
[19:02] <mvo> zyga-ubuntu: here the same without shared https://paste.ubuntu.com/26465983/
[19:02] <mvo> zyga-ubuntu: this is all on 16.04 classic
[19:06] <zyga-ubuntu> hmmm
[19:06] <zyga-ubuntu> odd
[19:06] <zyga-ubuntu> 137 89 7:0 / /snap/core/3887 ro,nodev,relatime shared:117 - squashfs /dev/loop0 ro
[19:06] <zyga-ubuntu> 138 23 7:0 / /snap/core/3887 ro,nodev,relatime shared:117 - squashfs /dev/loop0 ro
[19:06] <zyga-ubuntu> 143 89 7:1 / /snap/hello/20 ro,nodev,relatime shared:122 - squashfs /dev/loop1 ro
[19:06] <zyga-ubuntu> 144 23 7:1 / /snap/hello/20 ro,nodev,relatime shared:122 - squashfs /dev/loop1 ro
[19:06] <zyga-ubuntu> how come you get this?
[19:06] <zyga-ubuntu> thoey are all shared
[19:06] <zyga-ubuntu> is this running in a container on top of your 16.04?
[19:17] <zyga-ubuntu> mvo: ^ ?
[19:20] <mvo> zyga-ubuntu: this is a regular vm
[19:20] <mvo> zyga-ubuntu: sorry for the delay
[19:21] <zyga-ubuntu> mvo: no worries, I'm mostly wondering how this is possible
[19:21] <zyga-ubuntu> mvo: is there any part of test prep code that makes /snap or / rshared?
[19:21] <zyga-ubuntu> maybe this is an artefact
[19:21] <zyga-ubuntu> was this done via spread
[19:22] <zyga-ubuntu> I was doing it in a boxes VM (so just plain KVM) on 16.04 with lxd and it was not getting the sharing
[19:22] <mvo> zyga-ubuntu: this is all done manual, I used a stock 16.04 vm and added the mount unit manually
[19:22] <zyga-ubuntu> I see
[19:23] <mvo> zyga-ubuntu: but no lxd here
[19:23] <zyga-ubuntu> hmm hm :)
[19:23] <zyga-ubuntu> curious
[19:23] <zyga-ubuntu> oh/
[19:23] <mvo> zyga-ubuntu: this is the pure vm
[19:23] <zyga-ubuntu> wait
[19:23] <zyga-ubuntu> but pure 16.04 vm doesn't have this problem
[19:23] <zyga-ubuntu> it's shared by default already
[19:23] <mvo> zyga-ubuntu: I know, but if the fix produces double mounts thats a problem, no? or do we not care?
[19:23] <zyga-ubuntu> (the duplication is a curious issue but it's not the main problem in containers)
[19:23] <zyga-ubuntu> yeah, we may care
[19:23] <zyga-ubuntu> I wonder what is really going on
[19:23] <zyga-ubuntu> ok, this made me curous
[19:23] <zyga-ubuntu> *curious
[19:24] <zyga-ubuntu> I will explore
[19:24] <mvo> zyga-ubuntu: ok, I will do the mount unit generated via postinst script step next
[19:59] <mvo> cachio_: I know what breaks it - I added a zenity recommends that seems to cause the failure, I will dig into the details monday, peace of mind in the end :)
[20:00] <cachio_> mvo, heehhe
[20:00] <cachio_> mvo, ok
[20:01] <cachio_> mvo, btw, I have doctor app on monday, not sure if I'll be at home for the standup
[20:01] <mvo> cachio_: no worries
[20:01] <mvo> cachio_: thanks for letting me know
[20:01] <cachio_> tx
[20:15] <Chipaca> sergiusens: question: is snapcraft validating snap version strings?
[20:16] <mup> PR snapd#4544 closed: spread: remove more EOLed releases <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4544>
[20:23] <kyrofa> Chipaca, yeah, to ^[a-zA-Z0-9.+~-]+$ and max length of 32
[20:23] <Chipaca> kyrofa: k thx
[20:24] <kyrofa> Chipaca, is that okay? Has it changed?
[20:24] <Chipaca> kyrofa: snapd doesn't care :-) but i'm writing code in snapd that cares a little bit
[20:24] <kyrofa> Gotcha
[20:25] <Chipaca> i mean, if the version is valid, i'll use it in a filename
[20:25] <Chipaca> if it's not, ¯\_(ツ)_/¯
[20:26] <Chipaca> looking at that regexp, me, I wouldn't let versions end in ~, but again ¯\_(ツ)_/¯
[20:26] <Chipaca> i mean, a version of 4.~1~ would be somewhat confusing
[20:27] <Chipaca> at least to those of us used to VERSION_CONTROL=numbered
[20:27] <kyrofa> Heck, same goes for the rest probably
[20:29] <Chipaca> I could see people ending it in +
[20:29] <Chipaca> still, very minor friday-what-am-i-doing-at-the-keyboard nitpick
[20:29]  * Chipaca ponders beer
[20:40] <cachio_>  Chipaca, any idea why the hidsraw interface is not visible?
[20:43] <Chipaca> cachio_: no. visible where?
[20:44] <Chipaca> cachio_: I don't have a hidsraw in my tree (but i haven't synced today)
[20:48] <cachio_> Chipaca, hidraw
[20:49] <Chipaca> cachio_: do you have /dev/hidraw*?
[20:50] <cachio_> yes
[20:51] <Chipaca> cachio_: dunno, then :-)
[20:52] <cachio_> Chipaca, hehe, np
[20:52] <cachio_> do you have the interface?
[21:11] <diddledan> so one crazy SOB just got wine running
[21:12] <diddledan> just rebuilding my snap to be sure I wasn't dreaming
[21:22]  * Chipaca EODs
[21:22]  * Chipaca EOWs
[21:22]  * Chipaca EOLs
[21:49] <mup> PR snapcraft#1888 opened: elf: make patchelf a dependency <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1888>
[22:27] <Son_Goku> need testing for snapd 2.30 update for Fedora 26: https://bodhi.fedoraproject.org/updates/FEDORA-2018-798e0f02ff