=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:10] morning [06:14] hmm arch's kernel package changed their LOCALVERSIONing scheme and our checks are failing === chihchun_afk is now known as chihchun [06:33] are there any plans to port snapd (snap support) to macOS ? [06:38] CyberManifest: snapd is closely tied with linux atm as such i'm not aware of any plans to support other platforms, feel free to experiment though and ping us if you'd like to know more about the internals [06:38] CyberManifest: however we have plans to port the utilities for building snaps to windows and macos and this work should commence sooonish, next month most probably [06:38] mvo: hi, i've opened #5581 to fix the current problems on arch [06:39] mborzecki: couldn't https://mesonbuild.com be used to contain the linux portions i.e. sandbox the environment? [06:39] mborzecki: building doesn't help me run snap apps on macOS [06:43] CyberManifest: meson is a build system, so it could replace the autotools magic we currently use to build one of the elements, the rest of the code is in Go but makes use of systemd, udev, makes certain assumptions about system components and paths and so on [06:44] so snap can't run on non systemd systems that use sysV init? [06:44] CyberManifest: we make use of some kernel interfaces like mount namespace, seccomp, i'm not familiar with macos and don't know if there are similar intefaces on macos, though it'd be exciting if anyone wanted to explore this [06:45] mborzecki: and could homebrew not be used to port it? [06:46] CyberManifest: afaik homeberew i just for building, you'd still need to provide the functional counterparts of the intefaces we use at the system level [06:47] CyberManifest: but as i said, i'm not a mac user and have limited experience with osx [06:48] mborzecki: it's for distribution as well; it's mostly described as a package manager [06:53] mborzecki: good morning! master is failing right now on arch with an "running unexpected kernel version 4.17.11-arch1 error. is that a known issue? [06:53] mvo: yes, #5581 addresses that [06:53] mborzecki: cool [06:54] i should porbably label it as simple ;) [06:54] mvo: https://github.com/snapcore/snapd/pull/5581 [06:54] mborzecki: curious, why do we check the kernel version on arch? [06:55] mvo: because there's just one kernel version installed at a time, we do an upgrade before the tests, reboot, and just to be extra sure verify that we're running the right kernel (iirc there were some issues at the early beginnign of arch integration with that too) [06:56] mborzecki: aha, ok. makes sense, thank you [07:07] mvo: apt-hooks tests is still a bit flaky [07:07] mborzecki: yeah, I noticed yesterday I'm a bit puzzled about the why, the debug output shows the commands.db is populated :/ [07:08] mvo: yup, but iirc you've added a wait loop in the test right? [07:08] mborzecki: yes [07:08] ah right, but the file is there [07:08] hm [07:09] mvo: maybe we could dump the db in the test debug section? [07:09] or it's stale from one of the previous tests [07:09] mborzecki: dump|grep is a good idea [07:15] mvo: snap debug commands would be useful [07:16] mvo: strings /var/cache/snapd/commands.db is a bit hard to read [07:17] mborzecki: yeah, I think we need a debug dump command or similar [07:26] mvo: hm i think i can make it work with strings & some sed magic [07:28] mvo: super low tech https://paste.fedoraproject.org/paste/KeXaitkPbRn59wnVakr5ng/raw [07:28] mborzecki: systemd is covered by http://mesonbuild.com/Users.html don't know the rest though. [07:40] mborzecki: heh, nice! I think thats good enough for now [07:55] mvo: https://github.com/snapcore/snapd/pull/5582 [07:58] mborzecki: nice! and magic :) === chihchun is now known as chihchun_afk [08:10] mvo: left a comment in https://github.com/snapcore/snapd/pull/5557 [08:11] mvo: otherwise it's looking good [08:19] brb, need to do a quick run by the bike shop to get a new tube [09:04] re [09:04] mvo: mborzecki's commands.db pr died with an error you might know about or be interested in [09:05] - Mount snap "test-snapd-control-consumer" (2) ([start snap-test\x2dsnapd\x2dcontrol\x2dconsumer-2.mount] failed with exit status 1: Job for snap-test\x2dsnapd\x2dcontrol\x2dconsumer-2.mount failed. [09:05] in google:ubuntu-core-18-64:tests/main/install-remove-multi [09:06] damn [09:12] mborzecki: i've got the logs, if you want to just restart your run [09:22] btw. i don't recall the mount thing failing on ubuntu [09:22] it was always fedora & arch [09:23] Chipaca: hrm, hrm, the protocol error again? [09:24] mvo: http://r.chipaca.com/log.txt [09:25] mvo: I don't see protocol error in there, but i don't recall the exact error message it would throw [09:26] mvo: changing subjects, 16.04 having 2.34.2 and stable being 2.33 is weird :-) [09:32] Chipaca: no kidding [09:32] Chipaca: but yeah, will be fixed soon :) [09:32] Chipaca: the one and only time that the deb is ahead because we had issues on core devices with the refresh (pi2) [09:32] Chipaca: we will release 2.34.3 on Monday [09:33] mvo: I'm mostly surprised the sru got there that fast [09:35] Chipaca: yeah, we did all we could this time to get it ready in time for 18.04.1 [09:35] Chipaca: and all is fine on "normal" devices [09:35] mvo: to be fair I only noticed because my /usr/bin/snap was broken (because I broke it) so it was suddenly crashing === chihchun_afk is now known as chihchun [09:41] Chipaca: Jul 31 08:09:10 jul310756-078436 snapd[6023]: Jul 31 08:09:09 jul310756-078436 systemd[1]: snap-test\x2dsnapd\x2dcontrol\x2dconsumer-2.mount: Failed with result 'protocol'. [09:41] mvo: ah [09:41] Chipaca: so yeah, this is the error we are hunting since some time [09:41] Chipaca: maybe a systemd bug but so far elusive [09:47] mvo, hey, tests/main/apt-hooks is failing for https://github.com/snapcore/snapd/pull/5572 all the time, is that expected? it does not seem to be related to the PR [09:47] abeato: not related [09:48] abeato: also, often but not all the time. Sorry... we're looking into it [09:48] nw, good to know [09:48] abeato: i'll punch 'retry' for you [09:48] Chipaca, thanks [09:50] abeato: actually, if it's happening often for that pr, could you merge master? [09:50] abeato: mborzecki added some debug to that test [09:50] Chipaca, I rebased like one hour ago, so mborzecki could take a look at the log [09:51] abeato: the debug pr landed seconds ago [09:51] ok [09:51] abeato: (i merged it between punching restart, and asking you to merge master) [09:52] Chipaca, I've rebased my branc now [09:52] k [09:52] now of course it'll just work :-p [09:53] I would prefer that :p [10:13] Chipaca: 5583 is a bit of an rfc, let me know about any obvious holes in the approach [10:13] mborzecki: ^- you are welcome as well of course [10:13] got disconnected, not sure I the above made it to the channel [10:20] mvo: it hadn't [10:20] mvo: thanks [10:54] Chipaca: thanks for the review! at least no obvious holes in the approach that is good. I'm sure this will have some more iterations once gustavo and samuele get a chnace to look at it :) [10:54] mvo: a'yup === chihchun is now known as chihchun_afk [10:54] * mvo hugs Chipaca [10:58] anyone feeling like looking at some c code? https://github.com/snapcore/snapd/pull/5584 [11:02] second review for the timers fix? https://github.com/snapcore/snapd/pull/5573 [11:04] mborzecki: careful, when I review C code I usually get grumpy ;) [11:04] mvo: heh, i get so when writing c code [11:06] mvo: i'm thinking about that socket activation code, i'm afraid that the idea behind it may be that snapd must not be started at all [11:07] mborzecki: how do you mean? you mean in an ideal world it would not start at all? [11:07] mvo: meaning, it probably goes down to the fact that once started there will be pages allocated on the host anyway, even if you stop it later the ripple effect is on [11:08] mvo: at least that's the line of thinking i'd have should i be running a dense vm/container environment [11:08] mborzecki: I don't disagree! however this was discussed a good while ago (not starting at all) and there was pushback from Gustavo for various reasons. so for now the consensus was to start and stop if we can [11:10] mvo: well, i agree that you have proposed is a saner solution :P i recall the hack we had before 2.3x release and that was ugly [11:12] mborzecki: I had a PR once that tried to do it all with systemd conditionals but I can't find it right now [11:13] anyway, lunch first [11:13] mvo: enjoy [11:14] mborzecki: thank you! and thanks for the review(s) [11:15] mvo: mborzecki: what we _could_ do is have snapd touch files that we can then use from conditionals [11:16] Chipaca: then gate on ConditionPathExists or like? [11:17] mborzecki: say we touch /var/lib/snapd/up-to-date once everything is fine [11:17] mborzecki: and we remove that file if it's more than N days old [11:18] mborzecki: the problem is the catalog will be stale unless we have a way of triggering snapd to run periodically [11:19] Chipaca: hm we have timers now :) [11:19] mborzecki: in systemd we've had timers for yonks [11:19] there even was a snapd.timer [11:19] or was it snapd-service.timer [11:19] something like that [11:19] repair? [11:20] mborzecki: repair only runs in core [11:24] in any case, we'll see [11:24] maybe if the problem is VMs and clouds we add the dumb conditionals just to there [11:28] meanwhile, i've added a temporary label for parallel installs PRs [12:38] mvo: would you mind taking a look at https://github.com/snapcore/snapd/pull/5579 [12:40] mvo: hi btw :) [12:41] jdstrand: in a meeting right now, will do so soon [12:41] jdstrand: and *thnk you* [12:57] mborzecki: https://api.travis-ci.org/v3/job/410245666/log.txt [12:57] jdstrand: hi, i've requested your review on some of my prs, they should appear in your dashboard [13:15] shellchecks part 5 https://github.com/snapcore/snapd/pull/5585 - 'the song of quoting and escaping' [13:35] mborzecki: ack [13:44] jdstrand: now I'm back, looking at your PR now [13:52] jdstrand: thanks for the PR - I look forward killing ptrace trace :) [13:53] mvo: yes, me too :) [13:54] mborzecki: I cherry picked the arch fix for 2.34 - thanks for this one [13:54] mvo: thanks for picking it up for 2.34! [13:55] I wonder why I no longer have a _NET_WM_ICON xprop on a snapped firefox [13:57] =/ snap refresh to a previous revision and back to stable fixed it [14:23] * Chipaca takes a break [14:52] mborzecki: I added some comments to your C code PR - just like I said, I got a bit grumpy, sorry for this. hope its still useful. [14:53] mvo: sure, thanks for the review and the diff [14:54] mborzecki: I should add, your stuff is fine (the indent is a bit off though) and I think the extra tests would be nice. but the other bits are fine [14:54] mborzecki: this was just my take on this [14:54] cachio, picking up where we left off yesterday (autopkgtests), I know I need to generate the system locally, but not when actually running in autopkgtests, right? [14:54] mvo: yeah, the indent thing i did not notice even, showed fine in git diff & emacs [14:55] kyrofa, right [14:55] That was phrased badly. I mean when running the real deal, the system is generated for us, right? [14:55] mborzecki: iirc we use indent (or was it clang-format?) on the code [14:55] kyrofa, yes [14:55] kyrofa, you generate it when you run it locally [14:55] mvo: right, afaik it didn't cover snap-update-ns, probably need to run it manually [14:56] mborzecki: aha, I think you are right. slightly sad [14:56] cachio, can you explain why, since all the systems do the same thing, we have so many of them? Why not just call it "my-autopkgtest-system" and use it for everything? I feel like there's something I'm missing [14:56] mborzecki: I just ran indent and the diff was huge so probably best to fix maually and call it a day ;) [14:57] mvo: heh, run it now and it basically redid the whole file :( [14:57] mborzecki: yep [14:57] kyrofa, because then we use the system in the tests [14:57] Ah, the SPREAD_SYSTEM var or whatever? [14:57] if the system name is ubuntu-14 we do something [14:57] if the system is arch-linux we do something different [14:58] if it is ubuntu-18 the same [14:58] That was the only situation I could think of, sounds like we're on the same page. Perfect, thanks cachio, I'm going to proceed to, uh, borrow, all of this [14:58] kyrofa, also we filter tests by systems [14:59] in a task you can define which system you want to run and which to skip [15:00] kyrofa, something like https://github.com/snapcore/snapd/blob/master/tests/main/ubuntu-core-create-user/task.yaml#L2 [15:01] this test will be just executed on ubuntu-core-16 [15:01] mvo: looks like the whole bootstrap.c is using space indentation [15:02] cachio, ah, right, I do that too in retrospect [15:08] mvo: mborzecki: I _think_ https://github.com/snapcore/snapd/pull/5586 should fix the apt-hooks test breakage [15:15] mvo: my guess about not using islower() and friends is that s-c code is almost the same, same function names, code copied and so on [15:15] mvo: probably makes it easier to keep the code in sync [15:30] mborzecki: *shrug* no strong opinion but generally I'm not a fan of cargo culting. but then I usually avoid the C review to avoid getting grumpy :) [15:31] Chipaca: oh, nice. looking at your fix [15:35] mborzecki: 5586 is probably an easy win, if you have a moment for this one [15:43] mborzecki, I already pushed the PR to setup the storage at system level [15:44] we will need to wait few weeks for it [15:53] jdstrand: do you think you could review 5340 ? it got a +1 from zyga already but not from you yet [15:53] cachio: thank you [15:54] mvo: it is on my list, yes [15:55] jdstrand: thank you, I was asked about the status I will relay that then [15:59] Chipaca: left some comments in 5586, count that as +1 if i'm pushing too much :) [16:01] mborzecki: as i answered there: i can't create a boltdb from a file [16:01] so, no [16:01] unless we want to actualy fork it [16:01] (which AIUI we don't) [16:02] Chipaca: very well then [16:03] mborzecki: i looked into passing in a file (or a writecloser, or even just a writer), but the only thing that i could do is create the db and then use tx.WriteTo [16:03] which seems like a lot of copying around [16:03] meh [16:03] soz [16:59] brb, compiz hates me [17:21] (sorry if this is coming as a repeat message, freenode had an issue and I believe my message were no going through) [17:21] How can we create an Ubuntu Core image for the RPi with one additional snap installed. [17:21] ogra: ^ [17:22] in this case, we are using RPi3 and want our privately built snap preinstalled on it. [17:22] by creating a model assertion that has "required-snaps:" populated [17:22] ah, if you dont want to cycle it through the store (or cant) use the --extra-snaps option to ubuntu-image [17:23] we'll probably publish the snap to the store as well, so need to play with mode assertion probably. [20:03] abeato: I merged master, with fixes for apt-hooks concurrency from #5586, into #5572 and it's now green. Any reason not to merge it? [20:05] abeato: if there is, comment in the PR (you can use the 'blocked' label also) [20:05] abeato: otherwise i'll merge it in the mron [20:05] morn [20:05] g'night === hurricanehrndz is now known as HurricaneHrndz_ === HurricaneHrndz_ is now known as hurricanehrndz [22:36] how to cut some files from a .snap? [22:44] can a snap be mounted as an rw mount? [23:12] FreeBDSM: as far as I know, a snap is just a squashfs file. I think you can unsquash it, adjust it then mount the unsquashed snap with "snap try" [23:12] why does a firefox snap include usr/share with lots of non-related stuff, like pkgconfig, bash-completion, avahi, alsa, X11, themes, upstart etc? [23:13] actually, nevermind, fat package is a fat package, I just need it to work