[00:13] jdstrand: A bit late, but just in case, are you around? [00:13] jdstrand: It's not urgent [00:30] 'libc6' is required inside the snap for this part to work properly. [00:30] this particular part ships a single text file [00:30] wat [00:32] oh it's emitted for all parts if is_host_compatible_with_base is not true [00:33] that's a bit broad :) [00:35] mwhudson: Yeah, and also the idea of installing packages on the local machine to build.. we had a call today, and have a session in the sprint next week to discuss the future of snapcraft [00:36] mwhudson: In this sense specifically.. we need significantly simpler and more consistent [00:36] mwhudson: There are some good ideas in place already, in terms of building from within a container or image with shared access to the data [00:36] mwhudson: We just need to be a bit more opinionated and have a single workflow that always works [00:37] niemeyer: my use case is a bit strange because i need to include libraries from bionic [00:37] (thanks systemd journal format non-stability) [00:37] but yes [00:38] mwhudson: That's not too strange.. part of the conversation is precisely making sure it works no matter what the target base is [00:38] mwhudson: IOW, decoupling local host from build env [00:39] i guess i really want to use a bionic base... [00:39] Right [00:39] We have one of those coming :) [00:39] core18 [00:40] niemeyer: due around 18.04.1 time or did i get that wrong? [00:40] "Files from the build host were migrated into the snap to satisfy dependencies that would otherwise not be met." [00:41] would looove to know which files had these dependencies [00:42] mwhudson: :) [00:42] mwhudson: Yeah [00:42] oh wow i have far too much in this snap :( === chihchun_afk is now known as chihchun [00:58] hi: i'm begginer with ubuntu core. Trying to add startup comand in rc.local but shell says "read only file syste". How can i solve this? [00:59] basically i want to automatically start a snap i built in startup [01:06] pablo_: wouldn't that be done by shipping a daemon normally? [01:07] nacc: eh, this is the first snap i build and the tutorials did not helped me too much (or i'm too dumb to understand them). How could i build a daeomn snap? [01:07] nacc: thanks a lot for the answer btw! :) [01:08] pablo_: https://docs.snapcraft.io/build-snaps/metadata [01:09] pablo_: i think that hooks into systemd [01:10] nacc: so i add daeomn: simple and should start at startup? [01:10] pablo_: i'm not sure, i've never done it, but that seems worth trying ;) [01:13] nacc: yes, i'm pakaging the snap right now. I'm worried cause my snap needs root privileges to change GPIO of my board. But if its hooks systemd it may work, doesn't it? [01:13] pablo_: you might need to enable an interface, and connect to it, i don't know [01:21] didn't start at reboot :( [01:25] PR snapd#4753 opened: tests: fix dependency for ubuntu artful [01:26] pablo_: are you able to start it manually? [01:27] IT workied!!! i rebooted again and worked [01:27] thanks a lot nacc! for answering my noob question [01:28] pablo_: not noob! it's a bit confusing [01:41] Good afternoon! I'm attempting to setup a snap package for Citra (3DS emulator) and was hoping I could work with someone with a bit more knowledge of how snap packages are developed? I'm really flying blind here... I've attempted to read the documentation on snapcraft.io but am still fumbling around quite a bit. [02:03] chris062689: yes, snapcraft doc is not useful for me either. I wrote a snap of a python script and to be honest, it was all try an error. [02:04] do you have a snapcrafst.yaml created so far? if you paste it in pastebin perhaps someone can help you [02:06] I'm slowly hacking away at it. I was just curious if I could partner with someone. If I'm still having trouble and at the end of my rope I'll paste it here :) [04:33] PR snapd#4754 opened: spread: start moving towards google backend [05:46] PR snapd#4754 closed: spread: start moving towards google backend [06:01] morning [06:51] good morning [06:51] -14C now [06:52] zyga: hey [06:52] -17 here [06:52] brrr :) [06:55] * zyga goes for breakfast [07:09] hey mvo [07:11] zyga: check the build error in this PR https://github.com/snapcore/snapd/pull/4751 maybe it's of interest to you [07:11] PR #4751: tests: add support for external backend executions on listing test [07:11] mvo: hey [07:11] checking [07:12] hmmmm [07:14] no such file or directory... [07:14] [Mon Feb 26 20:50:27 2018] audit: type=1400 audit(1519678227.940:302): apparmor="DENIED" operation="mount" info="Failed name lookup - deleted entry" error=-2 profile="/usr/lib/snapd/snap-confine//snap_update_ns" name="/etc/group" pid=13952 comm="3" flags="rw, bind" [07:14] deleted entry [07:14] so [07:15] something killed that file form under us [07:15] prepare/restore logic? [07:15] but that's supposed to be run before/after the test right? [07:17] yeah but we saw many times that there is something that definitely runs at the wrong time [07:18] I don't know really [07:18] what would delete /etc/group otherwise [07:18] and note, we normally handle missing things just fine [07:18] we stat and look [07:18] and if missing create [07:18] and only then we proceed to mount [07:19] so before we stated and mounted something removed that [07:21] mborzecki, zyga good morning! [07:21] o/ [07:27] zyga: can you take another look at #4695? (sorry to be nagging you :) [07:27] PR #4695: wrappers: generator for systemd OnCalendar schedules [07:27] yes, sorry for not sending feedback, I have it open all the time but I was checking if I understand the problem space and that took forever [07:45] sliff [08:08] morning! [08:11] hey pstolowski ! good morning [08:28] pstolowski: hey [08:44] PR snapd#4753 closed: tests: fix dependency for ubuntu artful [09:24] Bug #1752031 opened: core `service.ssh.disable` key not taken into account [09:31] on the subject of InstallDate, and using the timestamp from current vs the timestamp from MountDir [09:31] I seem to remember that we went with current because it was a better indicator of when the thing was last refreshed to whatever is current [09:31] however if not current, there'd be no install date -- meaning no refreshed in info [09:32] I _could_ fall back to mountdir timestamp if there is no current [09:32] how well would that work? [09:32] (i think it'd work fairly well, but i might be missing something) [09:32] my vote goes for simplicity [09:32] (i could make a table of scenarios, but then people won't look at it) [09:32] :-) [09:32] just show what we know, not what we can make up (sort of) [09:33] we know both these things, and both can be arguably called an install date, or a refreshed date [09:33] and both are simple :-) [09:33] my point is that I'd personally feel better if the information always came from one source [09:33] if we use just one, the current timestamp is the right thing, as it's wrong less often (and when it would be wrong it's zero, which isn't printed) [09:33] is this a temporary situation and over time we will always have the right data? [09:34] that is the hope yes [09:34] we'll be adding this to snapstate at some point [09:35] anyone know a snap that places a *.desktop file under $SNAP_USER_DATA/.config/autostart? [09:35] zyga: the plan (small p) is to have, in snapstate, something like {refreshed: , reverted: <...>, ...}, or maybe a short log [(refreshed, <>), (refreshed, <>), (reverted, <>), ...) [09:36] log would be nice [09:36] mborzecki: I don't expect there to be a lot, as it doesn't work [09:36] mborzecki nope [09:36] mborzecki: (there's a bug open for that) [09:36] maybe on the bug? [09:37] mborzecki: https://bugs.launchpad.net/snapd/+bug/1736926 [09:37] Bug #1736926: No way to autostart a snap of a desktop application [09:38] Chipaca: the log would be truncated ? or just one entry per type, even if its' a log? [09:38] pedronis: i'm making stuff up on the fly, but I imagine it'd be, say, 5 entries? [09:38] i mean, all we're seeing immediate use for is the latest entry [09:38] Chipaca: well, keeping installed forever seems useful [09:39] pedronis: as opposed to refreshed [09:39] yes [09:39] that's when you introduced the snap into the system [09:39] but reverted vs refreshed vs enabled/disabled are much the same imho [09:39] so, well, something for this space :-) [09:40] point is, yes zyga, temporary until we have proper data instead of inferences [09:40] Chipaca: yeah, i'm working on that atm [09:40] zyga: I think I understand the problem with that storeSuite.TestCheckAuthority test, otoh it's hard to reproduce the failure [09:40] mborzecki: popey might be the person to ask then [09:40] I can propose something untested [09:40] Chipaca: hah, good idea ;) [09:40] mborzecki: but, is all the above a good enough answer for why the timestamp of current instead of of mountdir, wrt #4735? [09:41] PR #4735: daemon, snap: fix InstallDate, make a method of *snap.Info [09:41] pedronis: not this week -- i want to wrap snapshots [09:41] pedronis: next week i hear we're going to be idle, so maybe then [09:41] Chipaca: ? [09:41] I can propose something untested [09:42] Chipaca: that was about my comment to zyga about flaky test [09:42] ah :-) ok [09:42] too many threads [09:42] Chipaca: I have a gazillion other things to do [09:43] pedronis is it a test failure or a deeper bug? [09:43] pedronis: i must admit i was a little surprised, but i thought you were itching for something simple to relax [09:43] zyga: it's a test failure [09:43] Chipaca: mountdir timestap if no current seems fine, but then if you disable/enable that would 'alter' the installed date? [09:43] zyga: it's purely an order of stuff/timing issue, is just hard to reproduce here [09:44] zyga: the fix is swapping two lines [09:44] well two statements [09:46] Chipaca: mborzecki hmm? [09:47] popey: do you know of a snap that tries to do autostart by dropping a desktop file under $SNAP_USER_DATA/.config/autostart? [09:47] mborzecki: yes, discord [09:48] popey: thanks :) [09:48] https://www.irccloud.com/pastebin/YcIz40Cr/ [09:51] I think it does that post first run, it ticks the box by default. [09:54] PR snapd#4755 opened: snap/squashfs: add BuildDate [09:57] PR snapd#4756 opened: asserts: fix flaky storeSuite.TestCheckAuthority [09:57] zyga: ^ [10:05] mborzecki have a look [10:05] pedronis looking [10:32] PR snapd#4756 closed: asserts: fix flaky storeSuite.TestCheckAuthority [10:50] PR # closed: snapd#3963, snapd#3998, snapd#4285, snapd#4349, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4486, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4545, snapd#4551, snapd#4562, snapd#4571, snapd#4578, snapd#4588, snapd#4597, snapd#4600, [10:50] snapd#4639, snapd#4672, snapd#4682, snapd#4695, snapd#4696, snapd#4700, snapd#4714, snapd#4720, snapd#4721, snapd#4723, snapd#4725, snapd#4735, snapd#4738, snapd#4739, snapd#4743, snapd#4745, snapd#4748, snapd#4750, snapd#4751, snapd#4752, snapd#4755 [10:50] ooooh, github is dead [10:50] oh, what's wrong mup? [10:51] PR # opened: snapd#3963, snapd#3998, snapd#4285, snapd#4349, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4486, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4545, snapd#4551, snapd#4562, snapd#4571, snapd#4578, snapd#4588, snapd#4597, snapd#4600, [10:51] snapd#4639, snapd#4672, snapd#4682, snapd#4695, snapd#4696, snapd#4700, snapd#4714, snapd#4720, snapd#4721, snapd#4723, snapd#4725, snapd#4735, snapd#4738, snapd#4739, snapd#4743, snapd#4745, snapd#4748, snapd#4750, snapd#4751, snapd#4752, snapd#4755 [10:54] https://github.com/snapcore/snapd/pull/4714 needs 2nd review [10:54] PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) [10:54] mvo this is from jamie for 2.32 [10:55] zyga: ok === ikey|zzz is now known as ikey [11:04] zyga: thanks for the review, i've pushed an update, once it's green i'll merge that pr [11:04] sorry for taking so long [11:05] mvo: do you remember why we made --no-wait hidden? [11:08] Chipaca: I think because initially it was meant for our tests [11:08] Chipaca: but I think if it is useful outside of that we should just unhide it [11:10] mvo: I'm +1 for unhiding it, but only because it messes up some help screens and seems unnecessary for it to be hidden [11:12] Chipaca: sounds good to me [11:14] Chipaca: it's mostly hidden also because we never had a discussion how to call it properly [11:14] as long as it was for us, that was not a problem [11:14] pedronis: in what sense? you mean --no-wait might be a bad name for the flag? [11:15] ah [11:15] yes, how to call the flag [11:15] ok, i'l raise it as part of this por [11:15] pr* [11:24] zyga: do we have a backwards containment checker? [11:24] mmmm, what? [11:24] what is backwards containment? [11:24] I know we have a [foo,bar] contains foo checker [11:24] aaah [11:25] do we have a foo in [foo,bar] [11:25] I think that's Contains [11:25] (same check, different error) [11:25] no, wait [11:25] I mean [11:25] we have is x in [x, y, z] checker [11:25] is that what you mean? [11:27] zyga: I think it's just that Contains is used for checking that a container you got from the test has an element you expect it to have, and not viceversa [11:29] what is vice versa here? that an element exists in a container? [11:29] I mean [11:30] the check is the same, the error may be different [11:30] like Contained or something? [11:30] zyga: I'd call it In, but yeah [11:30] let me get an example for you [11:31] jdstrand I have a prototype of per-snap update-ns profiles [11:31] it works, I need to adjust some tests [11:31] and think about edge cases [11:31] where it would break [11:31] currently the policy is the same as before though [11:32] but I expect that to come in with small patches to policy and interfaces/layouts after this one lands [11:32] actually seeing the error message from contains, i guess it makes no difference; the expectation that the thing in test is first and the test valyue second is probably just mine [11:32] the other checkers have an obtained/expected thing though [11:32] hello, I just tried to push a snap using --release beta but it's been saying "Processing..." for an hour now [11:32] Contains just has container/elem [11:36] Jasem[m]: I'm not sure at what point snapcraft says "Processing"; is your network or cpu/disk busy? [11:36] Jasem[m] (you can use dstat to check) [11:39] Jasem[m]: otherwise it's possible the store went away for a bit, in which case maybe ^C and try again? [11:39] but if it's working, maybe let it work [11:39] * Chipaca might not be a snapcraft nor a store person [11:40] * cachio afk [11:52] ctlr+c doesn't even stop it [11:52] need to kill [11:52] Jasem[m]: ctrl+\ ? [11:52] PR snapd#4695 closed: wrappers: generator for systemd OnCalendar schedules [11:54] Chipaca: running again, will see how it goes [11:55] Chipaca: ok now 'internal server error' .. try in few minutes the page returned. [11:56] that's not very good is it [11:56] Jasem[m]: in the 500 page you probably have (in the source) a OOPS id [11:56] Jasem[m]: could you look for that? [11:56] brb, cranking the heating up [11:56] hands're freezing [11:59] Chipaca what's the temperature? [11:59] (outside) [11:59] here it's gotten much warmer [11:59] -8 now [11:59] yeah you're sending it all this way [11:59] but nah, it's zero [12:00] PR snapcraft#1879 closed: extractors: replace desktop file ids with paths [12:00] just that the wind's up, and snow [12:00] going to hit -4 by sundown [12:00] oddly warm here [12:00] calm before the storm [12:01] I don't mind thinking about spring now [12:01] my uncle works on the tube, was expecting to be stuck somewhere today [12:01] like having +20 would be ... amazing [12:01] 3c here atm, "warm" lol [12:02] tonight is when the wind and snow is meant to be kicking off.. [12:02] still 11C more than here :) [12:02] ah yeah but we'll be down to -10C soon [12:02] I woke up and sent kids to school at -14 [12:02] and a foot of snow [12:02] oof [12:02] my daughter said she wants to see snow in Poland [12:02] (after living in Spain almost her entire life) [12:02] I told her "careful what you wish for" [12:03] well, she's getting the snow all right [12:03] "are you having fun yet?" [12:04] lol [12:07] speaking of which [12:07] my hands are freezing too [12:08] this new imac is not making any heat that my old AMD system used to do [12:08] how can I fix 12 failing tests when I cannot feel my fingers anymore :/ [12:11] PR snapd#4757 opened: cmd/snap: unhide --no-wait; make wait use go via waitMixin [12:11] niemeyer: how do you feel about --no-wait? :_) [12:11] * pstolowski lunch [12:11] * Chipaca straightens his nose ;-) [12:12] Chipaca: ok tried again and now it says that a file with the exact content already been uploading [12:12] it's kstars_2.9.3_amd64.snap [12:14] Jasem[m]: something's going on because now login.ubuntu.com is out [12:16] 9 errors left :-) [12:16] but all should be trivial two line changes [12:16] https://status.snapcraft.io shows stuff is "ok" [12:18] * Chipaca goes for lunch [12:21] ok I'm getting the same error of the file already being uploaded :( [12:25] PR snapd#4696 closed: wrappers: timer services [12:27] PR snapd#4758 opened: tests/main/snap-service-timer: spread test for timer services [12:33] * zyga food [12:44] PR snapd#4735 closed: daemon, snap: fix InstallDate, make a method of *snap.Info [12:50] Chipaca: The functionality seems nice, the argument name seems awkward [12:50] Chipaca: --no-wait=false :) [12:50] PR snapd#4759 opened: [RFC] snap application autostart support [12:50] Chipaca: --wait=no [12:50] niemeyer: i don't understand --no-wait=false [12:51] Exactly :) [12:51] i mean, what? [12:51] niemeyer: i mean, i don't understand what you mean [12:51] Chipaca: I mean pretty much what you mean too: negatives makes it a bit awkward, when it could be a straight positive [12:52] niemeyer: what'd be the positive? [12:52] Chipaca: 1/yes/true [12:53] niemeyer: that's the side of the thing I knew [12:54] Chipaca: Yeah, it's a bit of an early morning conversation I suppose.. :) [12:54] Chipaca: Let's chat in a few mins [12:54] niemeyer: and a good morning to you too sir :-D [12:54] Morning! [12:54] It'll be even better if I learn that the google backend is working smoothly [12:57] Looks fine! [12:57] mborzecki: This failure on master probably needs some attention: https://travis-ci.org/snapcore/snapd [12:58] mborzecki: Ah, it's not master.. [12:58] mborzecki: It's a PR for master.. confusing Travis [12:59] It's this: https://github.com/snapcore/snapd/pull/4758 [12:59] PR #4758: tests/main/snap-service-timer: spread test for timer services [13:04] jdstrand, ping [13:06] https://usercontent.irccloud-cdn.com/file/UhcAcUK4/gce.png [13:25] mvo: #4748 is for 2.31 (or is that 2.32), fwiw [13:25] PR #4748: store: don't ask for snap_yaml_raw except on the details endpoint [13:26] Chipaca: .32 - but yeah, I was almost looking at it [13:26] mvo: I'll milestone it [13:26] Chipaca: ta [13:26] mvo: there's one in the review queue milestoned for .31, should i change it to .32? [13:28] * ikey fixes yama in solus kernels [13:38] Chipaca: if we need it for .31 we should make sure it goes to both [13:38] Chipaca: does .31 already ask for snap_yaml_raw? [13:41] mvo: I don't know [13:41] pedronis might [13:45] * kalikiana lunch time [13:48] Chipaca: I think it came with the default-provider stuff [13:49] which is 2.32 afaik [13:54] PR snapcraft#1956 closed: snap: actually plug the completer in [13:55] Chipaca: yeah, that is my understanding, its the default-provider so 2.32, so lets retarget [13:56] mwhudson: hey, I just saw this 'thanks systemd journal format non-stability'. Not sure what your plan is, but I looked at this before and found that older journald's didn't work with newer journals *and* vice versa (I was using the python bindings). it was frustrating [13:57] mwhudson: fyi only [14:03] zyga: re per s-u-n profiles. cool :) seems fine to factor out now and tailor policy later [14:03] yep :) [14:05] niemeyer: hi! I'm here now if you still need me [14:05] ikey: hi! [14:05] jdstrand, howya [14:05] jdstrand, so just seen your forum reply sorry (transitioned to a craptop) [14:06] ikey: heh [14:06] ikey: I was going to ping you this week if didn't hear from you :) [14:06] so the original PR had some problems that we encountered, in that it somehow conflicted with core [14:07] ikey: right. we can work through all that [14:07] like on a fresh install with no snapd state no new snaps could be installed [14:07] in the mean time im enabling yama in the kernels per your advice [14:07] but yeah the actual how-the-interface-fits bit i think is the one i need most help with [14:08] and with devmode snaps changing soon i think now is certainly the time to do it [14:08] ikey: nice! I think you'll like that as a feature in general. do note, you'll likely need some docs stating how to disable it for your devs. in the beginning, Ubuntu carried a patch to strace and gdb iirc to let devs know (users never cared) [14:08] jdstrand: Thanks! Not quite sure what it was about, but I'll probably remember as I go through the notes again :) [14:08] yeah patching those seems sufficient [14:09] niemeyer: hehe, ok :) [14:11] building kernels on this laptop isn't the fastest thing in the world :( [14:12] ikey: ok, so I see you responded in the forum. I'll move it to the top of my list to go through the PR with a fine-toothed comb and we'll iterate get it into mergeable state. if the fresh install or other bugs remain and we can't solve them, we'll get help [14:12] cheers jdstrand - i think i just got the initial declaration part wrong [14:12] but the apparmor bits seem ok [14:12] cool [14:13] I just came online, but hopefully I can get to this today (famous last words, haven't seen inbox yet ;) [14:13] hah my inbox is closed today [14:13] too much to do [14:13] smart [14:13] :) [14:13] had to get the mesa 17.3.6 emergency update out as they'd broken igp [14:13] icky [14:13] mm [14:14] hopefully for an emergency update, all the depends didn't sping out [14:14] spin* [14:14] mvo: niemeyer: I noticed https://forum.snapcraft.io/t/the-content-interface/1074 doesn't mention default-provider [14:14] pedronis: What a great opportunity! ;) [14:14]