[00:28] kyrofa: I like the "potentially bonkers" comment :-D [00:29] I'm sat here giggling to myself over that :-p [02:10] Bug #1745528 opened: snap icon available [02:58] Anyone around for a few (hopefully) quick questions? [02:59] If not, I'll pop back in the AM (PST). [02:59] TY [05:17] mornin [05:56] morning [06:56] good morning [06:56] FYI, I need to take today off, [06:56] last day of winter holidays for kids and I need to spend some time with them [06:58] PR snapd#4532 closed: store: use the "publisher" when populating the "publisher" field [06:58] zyga-ubuntu: hey, morning [06:59] hey! [06:59] I slept for hoooours [06:59] I woke up later at night and just briefly wandered here [06:59] yeah, today is monday you know? :) [06:59] man, I missed that sleep [06:59] haha! [06:59] good one :) I tried to fool our daughter a moment ago [06:59] haha [07:00] my kids are starting the break on monday ;) [07:01] oh, right :) [07:01] zyga-ubuntu: btw. sent you a small PR for snapd aur package: https://github.com/bboozzoo/aur-snapd/pull/1, nothing fancy [07:01] PR bboozzoo/aur-snapd#1: snapd: fix generation of systemd unit files, use /etc/default/snapd as environment file [07:03] looking [07:03] done [07:04] zyga-ubuntu: can you belive that indent is no longer package in arch? [07:04] i played with arch CI yday and i was like 'wtf?' when it failed on installing indent [07:08] mborzecki: indent is a weird tool, I'd like to migrate away from it [07:08] and use clang-format [07:08] not only more widely available but much better output [07:08] zyga-ubuntu: briefly thought about dumping autotools in favor of cmake or meson, though the latter is not availble in 14.04 :/ [07:11] `yaml.reader.ReaderError: unacceptable character #xdce2: special characters are not allowed` on arch tests/main/snap-info [07:21] 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] mborzecki: that's a curious one [07:21] I ran into it 100s of times [07:21] but it's a race somewhere [07:21] memory is corrupted [07:21] I dumped the yaml text when this happened [07:22] and I got random stuff all the time [07:22] it only ever surfaced on arch [07:22] perhaps due to a combination of compiler settings not used by other distributions [07:22] I didn't get to the bottom of it [07:28] try printing the buffer, I'm curious what you will get [07:28] zyga-ubuntu: found a related debian bug reported by Chipaca https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806826 [07:29] anyways, reading the patch explains why pretending we're using a utf8 locale fixes the problem [07:29] `LC_ALL=en_US.utf8 python3 check.py < out` works just fine [07:46] mborzecki: how does python come into the picture? [07:46] mborzecki: I thought this was from golang [07:46] mvo: hey [07:46] mvo: I'm off today [07:46] need to leave in a few minutes anyway [07:47] 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] zyga-ubuntu: hey, enjoy your day off [07:49] i still think that we should not produce any unicode output if locale does not support unicode [07:50] mborzecki: not knowing much context I agree [07:50] mborzecki: but that seems to be a broader issue, iirc our progress is also quite liberal with non ascii chars [07:52] 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] output dump) [07:54] mborzecki: not the same bug then [07:56] * zyga-ubuntu -> afk [07:56] zyga-ubuntu: not exactly, the patch does more than is written in the bug report :P [08:00] 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] pstolowski: morning [08:05] hey! [08:20] o/ [08:20] morning, mborzecki [08:21] kalikiana: hey [08:53] mo'in [08:53] rawr [08:54] if you say so [09:02] hrm, hrm, looks like master is broken right now [09:02] search test failing [09:06] mvo: D: [09:06] Chipaca: unless you are looking into this already I will do so now [09:06] mvo: I was not [09:22] store related tests are randomly failing? [09:27] PR snapd#4549 opened: tests: update "searching" test to match store changes [09:29] mborzecki: hopefully not randomly but yes, everything is broken right now [09:29] mborzecki: see PR above [09:30] 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] PR #4487: cmd/snap: snap refresh --time with new and legacy schedules [09:30] mborzecki: oh, more? sucks [09:31] mborzecki: sounds like a reason to talk to the good people from the store team :) [09:31] * mvo looks at the results [09:34] mvo: regarding 4549, database is no longer listed in sections :/ any clue why? [09:35] mborzecki: yeah, I just talked to the store team - it just got removed, there is a set of new sections [09:36] hm can they confirm that all the sections are listed in `snap find --section`? [09:39] mborzecki: I think that is the case [09:41] mborzecki: in your current run it is just "searching" what failed so far [09:41] mborzecki: so fingers crossed :) [09:41] mvo: btw: maciek@corsair:github.com/snapcore/snapd (git)-[master] ./test-snap find --section=foobar [09:41] No matching snaps for "" [09:41] yeah, we should tweak the error [09:41] to include that the search was in a section [09:41] mvo: i can look into it [09:42] and/or show that there is no such section [09:42] not sure what metadata we get from the store [09:42] thanks mborzecki [09:44] aloha, is there a bugtracker for snaps anywhere? [09:45] 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] 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] Deknos: there is also forum.snapcraft.io where a lot of the snap developers hang around [10:03] 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] thanks, i'll try the forum. [10:04] Bug #1669012 changed: Can't reinstall a snap already installed switching confinement mode

[10:09] Deknos: good luck! [10:22] mvo: do you think a separate error message if no matches in section were found makes sense? https://paste.ubuntu.com/26463360/ [10:23] mborzecki: this looks good to me [10:24] mvo: well i'm counting on sections being cached (which they seem to be) as this does an additional cli.Sections() call :) [10:48] PR snapd#4549 closed: tests: update "searching" test to match store changes [11:04] Mornings [11:04] * ikey plays "Walking on sunshine" in response to "morning" [11:10] ikey: I don't think I had ever seen that [11:11] https://www.youtube.com/watch?v=iPUmE-tne5U [11:11] ^^ [11:12] ♬ ♪♩♬ [11:13] PR snapd#4550 opened: cmd/snap: improve output when snaps were found in a section or the section is invalid [11:17] ikey: Yeah, I just watched it.. not sure what to take from it.. my life will probably never be the same again [11:17] most welcome lol [11:19] so i tried jdstrand's recommendations this morning with snapd/apparmor [11:19] apparmor was most unhappy [11:19] gonna have to bite the bullet and just suck it up with the whole 4.8 requirement [11:37] 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] ogra_: Will have a look [11:38] thanks [11:38] mborzecki: About your question on arch yesterday, [11:38] mborzecki: we never had our own arch image, I believe [11:38] mborzecki: What likely happened was that you were using an arch image provided by Linode, which was obsoleted [11:38] niemeyer: yes, that was the case, fortunately spread -vv contains all the info about machine templates i need ;) [11:39] mborzecki: I find a bit surprising to be honest [11:39] mborzecki: I mean, anyway using that image is now broken [11:39] anyone [11:39] Looking at https://www.linode.com/distributions, the current one seems to be 2018.01.02 [11:40] niemeyer: switched to that version already [11:54] mvo, https://paste.ubuntu.com/26461903/ https://paste.ubuntu.com/26461941/ [11:54] mvo I see those errors on rpi2 and 3 when I refresh from stable to beta [11:56] cachio_: thanks, looking [11:58] cachio_: *hrm* smells like an issue with writable-path, let me dig [12:00] cachio_: out of curiosity, this did not happen on an x86 core device? [12:00] mvo, no [12:01] mvo, just on the pi [12:01] interessting [12:01] cachio_: and you said you refreshed from the previous stable, correct? a fresh image from stable and then refresh to beta? [12:02] mvo, I used the stable from http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ [12:02] mvo, the factory one [12:02] cachio_: thank you, I give it a go [12:05] 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] Chipaca: thanks and see you [12:08] mvo: still here for another little while though :-) [12:08] meeting is 13:30, google says 30 minutes of driving (but midday rush is a thing) [12:11] Issue snapcraft#1886 opened: Support for yarn --extra-args [12:21] 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] cachio_: can you ssh into the board and run "systemctl list-timers --all" and paste that please? [12:21] sure [12:21] PR snapd#4551 opened: interfaces: do not auto-connect manually disconnected interfaces [12:22] mvo, https://paste.ubuntu.com/26463820/ [12:25] * kalikiana going to go for an earlier lunch in a few [12:33] PR snapd#4552 opened: testutil: do not use echo for printing potentially conflicting arguments [12:33] cachio_: hm, how strange. in a meeting now, lets talk in a bit [12:36] mvo, np [12:40] PR snapd#4547 closed: snap: fix race in `snap run --strace` [12:47] 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] ikey: https://youtu.be/elmwnUOtxu8?t=76 [13:22] hah perfect [14:00] cachio_: what is the output of "systemctl status snapd.snap-repair.timer" on the pi2? [14:00] cachio_: (or pi3) [14:01] cachio_, do you have any gsettings branch I can look at? or can describe the test case you want to achieve? [14:01] https://paste.ubuntu.com/26464226/ [14:01] pstolowski, yes, on sec [14:02] pstolowski, https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings [14:02] there is a snap already uploded to the store [14:03] mvo, https://paste.ubuntu.com/26464226/ [14:10] cachio_, thanks, i'll have a lunch now and will take a look afterwards [14:10] * pstolowski lunch [14:13] pstolowski, sure, just ping me [14:18] cachio_: thanks, I'm on it [14:22] cachio_: I think I found the issue and pushed a fix to the core build, will be part of ~rc2 [14:22] PR core#79 opened: 26-fixup-core.chroot: fix snapd.snap-repair.timer enable symlink [14:23] mvo, great [14:23] mvo, which is the problem that you found? [14:24] cachio_: its a problem with the writable-path stuff: https://github.com/snapcore/core/pull/79/commits [14:24] PR core#79: 26-fixup-core.chroot: fix snapd.snap-repair.timer enable symlink [14:25] mvo, ohh, tx [15:19] kyrofa: Hey [15:20] 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] kalikiana, hahaha [15:26] Yeah we probably don't want that eh? [15:27] kalikiana, do you want to HO? [15:28] kyrofa: Yeah, we can have a quick chat now if you have time [15:30] kalikiana, I do [15:30] kyrofa: Shall we use the weekly? [15:30] weekly? [15:30] Yep [15:30] Oh wait, no [15:30] kalikiana, any chance you have skype? [15:30] I'm so stinking sick of chrome [15:30] kyrofa: I'm seeing a trend here :-D [15:30] Let's use that. Or talky [15:31] Is talky better? [15:31] I really don't care. Just something that doesn't require me to open chroem [15:31] kyrofa: Either one works for me [15:31] lol [15:31] Let's try talky. Hold on [15:38] cachio_, test-snapd-gsettings is the snap you meant? [15:38] yes [15:38] pstolowski, [15:41] cachio_, oh wow, that snap is huge [15:42] pstolowski, yes :s [15:46] cachio_, I see more plugs than just gsettings in its snap.yaml; is this intended to be used for many tests? [15:47] it is pluggin also desktop [15:47] pstolowski, it is because it needs to access to destop files [15:51] 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] Issue snapcraft#1887 opened: Update to ROS2 Ardent [15:52] I thought there was some seccomp/apparmor provision for this, but I can't find any documentation on it [15:55] bloodearnest, no, it's in the design phases as I understand it, jdstrand will know more/all [16:03] 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] kyrofa, hey, where can I lookup the definition of desktop-gtk3 part? I knew it but forgot.. [16:06] pstolowski, snapcraft define [16:06] pstolowski, or do you want to update it? [16:06] kyrofa, no, just check it out [16:06] Yeah, that should work [16:06] kyrofa, thanks! [16:09] 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] kyrofa: jdstrand: ok, thanks [16:10] fwiw, this make squid and postgres very difficult to run, as they both refuse to run as uid 0 [16:10] 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] bloodearnest: but we'll get to it [16:11] bloodearnest: I think someone posted in the forum what to do with postgresql [16:11] bloodearnest: there is also the snapcraft preload plugin which LD_PRELOADs to make them no-ops [16:12] but like you say, the correct thing is to have this support. we'll get there [16:13] pstolowski, ok, I'll try that [16:13] pstolowski, apart of that, any idea about hot make it work on linode? [16:13] it was failing trying to create many directories [16:13] but then can't access to the gsettings user keys [16:13] it is just reading the values that come inside the snap [16:13] but when I try to update and see the change, the values have not been changed [16:14] cachio_, and you depend on desktop-gtk3 path to have the entire environment and schemas set, correct? [16:14] 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] pstolowski, I got disconnected, sorry [16:14] pstolowski, yes [16:14] bloodearnest: someone specifically patched postgresql for the postgresql snap [16:14] I copied that from the gnome-calculator app [16:14] bloodearnest: so yes, you might have to patch. for now. but we'll get there [16:15] 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] cachio_, this is part of the desktop-launch script afaict [16:15] cachio_, look at the gsettings stuff there [16:15] cachio_, you can basically replicate it [16:16] pstolowski, ok, but the problem is that all the desktop part is not in the linode images [16:17] pstolowski, so, the mappings in this script don't work [16:17] cachio_, yeah but we don't need it afaict [16:18] pedronis: hi any suggestions on https://forum.snapcraft.io/t/seed-yaml-documentation/3050/4 maybe --classic snaps can't be seeded ? [16:18] blackboxsw, he is off, back next week [16:19] ahh excellent pstolowski thanks for the heads up [16:20] pstolowski, ok, I'll try to clean this but first I need to figure out how to fix the current issue [16:20] pstolowski, for example [16:20] 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] cachio_, and the test could use gsettings binary from the snap, no custom python to query gsettings data [16:22] cachio_, we should be able to test gsettings with just cli tools, no need for gtk and all the desktop stuff [16:22] pstolowski, ok, I'll try this [16:23] cachio_, i'm not sure about the dconf part of the interface, it has a dbus snippet [16:23] cachio_, there is a dconf binary that can also query settings. but i don't know if it touches dbus [16:24] pstolowski, no idea [16:24] so jdstrand to clarify, how am i going to move forward with the steam thing? [16:24] cachio_, if not, then we can use dbus-send cli or something else (not to pull python) [16:25] cuz that much i failed as yet to discern [16:25] but gathered "pending voodoo" being the trend [16:26] cachio_, well, just the bare python itself is not too bad, problems start when we pull too much stuff [16:27] pstolowski, yes, agree [16:27] pstolowski, I tried to simulate what the desktop team do but it is so complex for our tests [16:30] 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] 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] 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] 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] jdstrand, ok [16:37] i think ill have to pull my snaps out of the store [16:37] as i cant update them [16:38] ikey: ? why? [16:38] pstolowski, ok, I'll start researching on this [16:38] because to develop them any further i need working strict confinement, and they're bugged out in their current state [16:38] and nobody else will have the interface they need to run them properly [16:38] etc [16:38] ikey: you could set 'grade: devel' and not push them to stable [16:39] ive not pushed to stable [16:39] because of my permanent chicken / egg cycle with this snap :P [16:39] I don't know if that is helpful or not, but an option [16:41] basically because i cant update them i cant testify to their security status [16:41] and would be more comfortable with withdrawing them entirely [16:41] as it reflects poorly on solus [16:41] pstolowski, another question [16:42] pstolowski, https://paste.ubuntu.com/26465150/ [16:42] hidraw should be just for gadgets? [16:42] well, regardless, I'll be working on this to give you what you need [16:42] pstolowski, or it should be visible in any core? [16:43] pstolowski, based on that declaration [16:43] PR core#79 closed: 26-fixup-core.chroot: fix snapd.snap-repair.timer enable symlink [16:43] jdstrand, how would i go about unpublishing snaps..? [16:43] if such a concept exists [16:45] alternatively ill refresh the snaps without any of the new interfaces.. but ofc they remain broken [16:45] this is too much thinking for a friday -_- [16:45] ikey: I'm not sure tbh. perhaps roadmr or sergiusens can comment? [16:47] what would need to be done on your side out of interest? [16:47] re: enabling the globbing stuffs [16:48] 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] 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] 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] i mean like all revisions [16:53] ikey: oh like just removing them from existence entirely? I don't think that can be done :( sorry [16:53] ah ok [16:53] ikey: another way is to close all channels. snapcraft close stable [16:53] so ill need to push a gimped build then [16:53] roadmr, unfortunately i dont have a stable channel [16:53] same for beta, edge, candidate. [16:54] ikey: if the snap is on e.g. edge, you can close that too [16:54] ok ty [16:58] PR snapd#4553 opened: many: add io.snapcraft.Settings to `snap userd` [16:59] * kalikiana going to wrap up for the week shortly [17:04] eow, o/ [17:06] PR snapd#4554 opened: test build - ignore [17:08] ogra_, hey [17:08] could you please confirm if the hidraw interface is available on any core device [17:09] ogra_, this is the declaration https://paste.ubuntu.com/26465150/ [17:09] PR snapd#4553 closed: many: add io.snapcraft.Settings to `snap userd` [17:09] PR snapd#4554 closed: test build - ignore [17:10] cachio_: I get dinner now, but the failure in 4073 is strange still :/ [17:11] mvo, checking [17:12] PR snapd#4538 closed: interfaces/builtin: Add new steam-support interface [17:22] cachio_, nops, uhid is there but not hidraw [17:23] cachio_, so core does not have it declared atm [17:23] (the core snap that is) [17:26] ogra_, ok [17:26] ogra_, tx [17:26] s/declared/exposed/ [17:26] np [17:29] ogra_, not sure why not [17:29] ogra_, it should [17:29] ogra@localhost:~$ snap interfaces|grep hid [17:29] :uhid [17:29] well, thats what i get [17:30] (on all core devices running here) [17:30] This is looking smooth... https://travis-ci.org/snapcore/snapd/jobs/333816377 [17:50]