/srv/irclogs.ubuntu.com/2018/07/31/#snappy.txt

=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
mborzeckimorning05:10
mborzeckihmm arch's kernel package changed their LOCALVERSIONing scheme and our checks are failing06:14
=== chihchun_afk is now known as chihchun
CyberManifestare there any plans to port snapd (snap support) to macOS ?06:33
mborzeckiCyberManifest: 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 internals06:38
mborzeckiCyberManifest: however we have plans to port the utilities for building snaps to windows and macos and this work should commence sooonish, next month most probably06:38
mborzeckimvo: hi, i've opened #5581 to fix the current problems on arch06:38
CyberManifestmborzecki: couldn't https://mesonbuild.com be used to contain the linux portions i.e. sandbox the environment?06:39
CyberManifestmborzecki: building doesn't help me run snap apps on macOS06:39
mborzeckiCyberManifest: 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 on06:43
CyberManifestso snap can't run on non systemd systems that use sysV init?06:44
mborzeckiCyberManifest: 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 this06:44
CyberManifestmborzecki: and could homebrew not be used to port it?06:45
mborzeckiCyberManifest: afaik homeberew i just for building, you'd still need to provide the functional counterparts of the intefaces we use at the system level06:46
mborzeckiCyberManifest: but as i said, i'm not a mac user and have limited experience with osx06:47
CyberManifestmborzecki: it's for distribution as well; it's mostly described as a package manager06:48
mvomborzecki: 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
mborzeckimvo: yes, #5581 addresses that06:53
mvomborzecki: cool06:53
mborzeckii should porbably label it as simple ;)06:54
mborzeckimvo: https://github.com/snapcore/snapd/pull/558106:54
mvomborzecki: curious, why do we check the kernel version on arch?06:54
mborzeckimvo: 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:55
mvomborzecki: aha, ok. makes sense, thank you06:56
mborzeckimvo: apt-hooks tests is still a bit flaky07:07
mvomborzecki: yeah, I noticed yesterday I'm a bit puzzled about the why, the debug output shows the commands.db is populated :/07:07
mborzeckimvo: yup, but iirc you've added a wait loop in the test right?07:08
mvomborzecki: yes07:08
mborzeckiah right, but the file is there07:08
mborzeckihm07:08
mborzeckimvo: maybe we could dump the db in the test debug section?07:09
mborzeckior it's stale from one of the previous tests07:09
mvomborzecki: dump|grep is a good idea07:09
mborzeckimvo: snap debug commands would be useful07:15
mborzeckimvo: strings /var/cache/snapd/commands.db is a bit hard to read07:16
mvomborzecki: yeah, I think we need a debug dump command or similar07:17
mborzeckimvo: hm i think i can make it work with strings & some sed magic07:26
mborzeckimvo: super low tech https://paste.fedoraproject.org/paste/KeXaitkPbRn59wnVakr5ng/raw07:28
CyberManifestmborzecki: systemd is covered by http://mesonbuild.com/Users.html don't know the rest though.07:28
mvomborzecki: heh, nice! I think thats good enough for now07:40
mborzeckimvo: https://github.com/snapcore/snapd/pull/558207:55
mvomborzecki: nice! and magic :)07:58
=== chihchun is now known as chihchun_afk
mborzeckimvo: left a comment in https://github.com/snapcore/snapd/pull/555708:10
mborzeckimvo: otherwise it's looking good08:11
mborzeckibrb, need to do a quick run by the bike shop to get a new tube08:19
mborzeckire09:04
Chipacamvo: mborzecki's commands.db pr died with an error you might know about or be interested in09:04
Chipaca- 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
Chipacain google:ubuntu-core-18-64:tests/main/install-remove-multi09:05
mborzeckidamn09:06
Chipacamborzecki: i've got the logs, if you want to just restart your run09:12
mborzeckibtw. i don't recall the mount thing failing on ubuntu09:22
mborzeckiit was always fedora & arch09:22
mvoChipaca: hrm, hrm, the protocol error again?09:23
Chipacamvo: http://r.chipaca.com/log.txt09:24
Chipacamvo: I don't see protocol error in there, but i don't recall the exact error message it would throw09:25
Chipacamvo: changing subjects, 16.04 having 2.34.2 and stable being 2.33 is weird :-)09:26
mvoChipaca: no kidding09:32
mvoChipaca: but yeah, will be fixed soon :)09:32
mvoChipaca: the one and only time that the deb is ahead because we had issues on core devices with the refresh (pi2)09:32
mvoChipaca: we will release 2.34.3 on Monday09:32
Chipacamvo: I'm mostly surprised the sru got there that fast09:33
mvoChipaca: yeah, we did all we could this time to get it ready in time for 18.04.109:35
mvoChipaca: and all is fine on "normal" devices09:35
Chipacamvo: to be fair I only noticed because my /usr/bin/snap was broken (because I broke it) so it was suddenly crashing09:35
=== chihchun_afk is now known as chihchun
mvoChipaca: 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
Chipacamvo: ah09:41
mvoChipaca: so yeah, this is the error we are hunting since some time09:41
mvoChipaca: maybe a systemd bug but so far elusive09:41
abeatomvo, 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 PR09:47
Chipacaabeato: not related09:47
Chipacaabeato: also, often but not all the time. Sorry... we're looking into it09:48
abeatonw, good to know09:48
Chipacaabeato: i'll punch 'retry' for you09:48
abeatoChipaca, thanks09:48
Chipacaabeato: actually, if it's happening often for that pr, could you merge master?09:50
Chipacaabeato: mborzecki added some debug to that test09:50
abeatoChipaca, I rebased like one hour ago, so mborzecki could take a look at the log09:50
Chipacaabeato: the debug pr landed seconds ago09:51
abeatook09:51
Chipacaabeato: (i merged it between punching restart, and asking you to merge master)09:51
abeatoChipaca, I've rebased my branc now09:52
Chipacak09:52
Chipacanow of course it'll just work :-p09:52
abeatoI would prefer that :p09:53
mvo<mvo> Chipaca: 5583 is a bit of an rfc, let me know about any obvious holes in the approach10:13
mvo<mvo> mborzecki: ^- you are welcome as well of course10:13
mvogot disconnected, not sure I the above made it to the channel10:13
Chipacamvo: it hadn't10:20
Chipacamvo: thanks10:20
mvoChipaca: 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
Chipacamvo: a'yup10:54
=== chihchun is now known as chihchun_afk
* mvo hugs Chipaca 10:54
mborzeckianyone feeling like looking at some c code? https://github.com/snapcore/snapd/pull/558410:58
mborzeckisecond review for the timers fix? https://github.com/snapcore/snapd/pull/557311:02
mvomborzecki: careful, when I review C code I usually get grumpy ;)11:04
mborzeckimvo: heh, i get so when writing c code11:04
mborzeckimvo: 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 all11:06
mvomborzecki: how do you mean? you mean in an ideal world it would not start at all?11:07
mborzeckimvo: 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 on11:07
mborzeckimvo: at least that's the line of thinking i'd have should i be running a dense vm/container environment11:08
mvomborzecki: 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 can11:08
mborzeckimvo: 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 ugly11:10
mvomborzecki: I had a PR once that tried to do it all with systemd conditionals but I can't find it right now11:12
mvoanyway, lunch first11:13
mborzeckimvo: enjoy11:13
mvomborzecki: thank you! and thanks for the review(s)11:14
Chipacamvo: mborzecki: what we _could_ do is have snapd touch files that we can then use from conditionals11:15
mborzeckiChipaca: then gate on ConditionPathExists or like?11:16
Chipacamborzecki: say we touch /var/lib/snapd/up-to-date once everything is fine11:17
Chipacamborzecki: and we remove that file if it's more than N days old11:17
Chipacamborzecki: the problem is the catalog will be stale unless we have a way of triggering snapd to run periodically11:18
mborzeckiChipaca: hm we have timers now :)11:19
Chipacamborzecki: in systemd we've had timers for yonks11:19
Chipacathere even was a snapd.timer11:19
Chipacaor was it snapd-service.timer11:19
Chipacasomething like that11:19
mborzeckirepair?11:19
Chipacamborzecki: repair only runs in core11:20
Chipacain any case, we'll see11:24
Chipacamaybe if the problem is VMs and clouds we add the dumb conditionals just to there11:24
mborzeckimeanwhile, i've added a temporary label for parallel installs PRs11:28
jdstrandmvo: would you mind taking a look at https://github.com/snapcore/snapd/pull/557912:38
jdstrandmvo: hi btw :)12:40
mvojdstrand: in a meeting right now, will do so soon12:41
mvojdstrand: and *thnk you*12:41
Chipacamborzecki: https://api.travis-ci.org/v3/job/410245666/log.txt12:57
mborzeckijdstrand: hi, i've requested your review on some of my prs, they should appear in your dashboard12:57
mborzeckishellchecks part 5 https://github.com/snapcore/snapd/pull/5585 - 'the song of quoting and escaping'13:15
jdstrandmborzecki: ack13:35
mvojdstrand: now I'm back, looking at your PR now13:44
mvojdstrand: thanks for the PR - I look forward killing ptrace trace :)13:52
jdstrandmvo: yes, me too :)13:53
mvomborzecki: I cherry picked the arch fix for 2.34 - thanks for this one13:54
mborzeckimvo: thanks for picking it up for 2.34!13:54
threshI wonder why I no longer have a _NET_WM_ICON xprop on a snapped firefox13:55
thresh=/ snap refresh to a previous revision and back to stable fixed it13:57
* Chipaca takes a break14:23
mvomborzecki: 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:52
mborzeckimvo: sure, thanks for the review and the diff14:53
mvomborzecki: 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 fine14:54
mvomborzecki: this was just my take on this14:54
kyrofacachio, 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
mborzeckimvo: yeah, the indent thing i did not notice even, showed fine in git diff & emacs14:54
cachiokyrofa, right14:55
kyrofaThat was phrased badly. I mean when running the real deal, the system is generated for us, right?14:55
mvomborzecki: iirc we use indent (or was it clang-format?) on the code14:55
cachiokyrofa, yes14:55
cachiokyrofa, you generate it when you run it locally14:55
mborzeckimvo: right, afaik it didn't cover snap-update-ns, probably need to run it manually14:55
mvomborzecki: aha, I think you are right. slightly sad14:56
kyrofacachio, 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 missing14:56
mvomborzecki: I just ran indent and the diff was huge so probably best to fix maually and call it a day ;)14:56
mborzeckimvo: heh, run it now and it basically redid the whole file :(14:57
mvomborzecki: yep14:57
cachiokyrofa, because then we use the system in the tests14:57
kyrofaAh, the SPREAD_SYSTEM var or whatever?14:57
cachioif the system name is ubuntu-14 we do something14:57
cachioif the system is arch-linux we do something different14:57
cachioif it is ubuntu-18 the same14:58
kyrofaThat 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 this14:58
cachiokyrofa, also we filter tests by systems14:58
cachioin a task you can define which system you want to run and which to skip14:59
cachiokyrofa, something like https://github.com/snapcore/snapd/blob/master/tests/main/ubuntu-core-create-user/task.yaml#L215:00
cachiothis test will be just executed on ubuntu-core-1615:01
mborzeckimvo: looks like the whole bootstrap.c is using space indentation15:01
kyrofacachio, ah, right, I do that too in retrospect15:02
Chipacamvo: mborzecki: I _think_ https://github.com/snapcore/snapd/pull/5586 should fix the apt-hooks test breakage15:08
mborzeckimvo: my guess about not using islower() and friends is that s-c code is almost the same, same function names, code copied and so on15:15
mborzeckimvo: probably makes it easier to keep the code in sync15:15
mvomborzecki: *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:30
mvoChipaca: oh, nice. looking at your fix15:31
mvomborzecki: 5586 is probably an easy win, if you have a moment for this one15:35
cachiomborzecki, I already pushed the PR to setup the storage at system level15:43
cachiowe will need to wait few weeks for it15:44
mvojdstrand: do you think you could review 5340 ? it got a +1 from zyga already but not from you yet15:53
mborzeckicachio: thank you15:53
jdstrandmvo: it is on my list, yes15:54
mvojdstrand: thank you, I was asked about the status I will relay that then15:55
mborzeckiChipaca: left some comments in 5586, count that as +1 if i'm pushing too much :)15:59
Chipacamborzecki: as i answered there: i can't create a boltdb from a file16:01
Chipacaso, no16:01
Chipacaunless we want to actualy fork it16:01
Chipaca(which AIUI we don't)16:01
mborzeckiChipaca: very well then16:02
Chipacamborzecki: 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.WriteTo16:03
Chipacawhich seems like a lot of copying around16:03
mborzeckimeh16:03
Chipacasoz16:03
Chipacabrb, compiz hates me16:59
om26er(sorry if this is coming as a repeat message, freenode had an issue and I believe my message were no going through)17:21
om26erHow can we create an Ubuntu Core image for the RPi with one additional snap installed.17:21
om26erogra: ^17:21
om26erin this case, we are using RPi3 and want our privately built snap preinstalled on it.17:22
ograby creating a model assertion that has "required-snaps:" populated17:22
ograah, if you dont want to cycle it through the store (or cant) use the --extra-snaps option to ubuntu-image17:22
om26erwe'll probably publish the snap to the store as well, so need to play with mode assertion probably.17:23
Chipacaabeato: 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:03
Chipacaabeato: if there is, comment in the PR (you can use the 'blocked' label also)20:05
Chipacaabeato: otherwise i'll merge it in the mron20:05
Chipacamorn20:05
Chipacag'night20:05
=== hurricanehrndz is now known as HurricaneHrndz_
=== HurricaneHrndz_ is now known as hurricanehrndz
FreeBDSMhow to cut some files from a .snap?22:36
FreeBDSMcan a snap be mounted as an rw mount?22:44
mcphailFreeBDSM: 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
FreeBDSMwhy does a firefox snap include usr/share with lots of non-related stuff, like pkgconfig, bash-completion, avahi, alsa, X11, themes, upstart etc?23:12
FreeBDSMactually, nevermind, fat package is a fat package, I just need it to work23:13

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!