[06:03] morning [06:15] zyga: hey - I just saw that you were debugging a dbus apparmor query bug [06:15] zyga: did you get to the bottom of it? [06:16] (I see the dc25979eb commit) [06:21] Bug #1743504 opened: Ubuntu 16.04 snapd service not working [07:41] PR snapd#4489 opened: vendor: remove x/sys/unix to fix builds on arm64 and powerpc [07:53] mvo: morning [07:56] good morning [07:57] I'll get some coffee and will be back shortly :) [07:57] zyga: hey [07:58] have you guys seen this? https://forum.snapcraft.io/t/ubuntu-16-04-snapd-fail-to-start/3529 [07:58] mborzecki: looking [07:58] hey mborzecki ! good morning [07:58] and good morning zyga [07:59] looks like #include maybe (vs include) [07:59] but not sure [07:59] mvo: hey! [07:59] -> coffee [08:01] zyga: apparmor thing? [08:02] yes, we delt with this in the past, that's the only thing that I can recall having an '#' issue [08:02] but [08:02] this is not a guarantee this is it [08:02] that error is talking about the '#' being a problem [08:03] the issue you were thinking of was a missing '#' [08:03] indeed [08:03] hey jdstrand :) [08:03] hey [08:03] I'm not used to you being in the same timezone [08:03] how was day one? :) [08:03] but regardless, snapd was not affected by the '#' or lack of '#', it was the apparmor python tools. I think this is unrelated to all that [08:04] day one went fine [08:04] ah, indeed, I think you are right [08:04] zyga, mborzecki doing a "grep -r" for the error message in vendor/ and /usr/share/go-1.8/src indicates its a json decode error, so probably corrupted state.json [08:04] mborzecki: (as you already guessed :) [08:04] no time to do any engineering really. lots of meetings, lots of interrupts when I thought I had time to do something [08:04] typical sprint :) [08:06] zyga: ftr, I have a slew of PRs scheduled for review. just need time to focus on them. they will be at the top of my list next week if I can't get to them this week (and I don't expect I can) [08:06] mvo: makes me wonder, unless hand edited, how would # end up in state.json? [08:06] jdstrand: ack [08:07] mborzecki: yeah, a good question, we would need the state.json to inspect, might be a bit flip, once you have enough users this will happen (we saw that with e.g. the dpkg/apt database frequently). or a corrupted hdd like zyga had earlier. hard to say (or of course our fault somewhere in our state saving code) [08:08] it's not part of the pacakge right? so there's no chance of state.json getting updated as part of package upgrade? [08:09] jdstrand: how's the weather like? [08:09] zyga: beautiful [08:09] mborzecki: or if you remember my crazy hdd yesterday, may be the xml profile in place of json :) [08:09] mborzecki: on my disk the dpkg database contains random files [08:09] zyga: sounds like a fun day :) [08:09] zyga: yeah, that's possible too :/ [08:12] sliff [08:12] good morning! [08:12] * kalikiana feeling a bit under the weather this not so good morning :-( [08:12] mborzecki: correct [08:12] kalikiana: ouch [08:13] hey pstolowski [08:13] kalikiana, sad to hear that.. take it easy and get well! [08:19] mwhudson: snapd in debian is updating now [08:19] zyga, mborzecki, pstolowski quick question - what feels more natural to you: `snap run --strace-opts="-tt" hello` or `snap run --strace="-tt" hello` ? [08:20] mvo: the latter [08:20] mvo, the latter [08:20] (the former could also be written as `snap run --strace --strace-opts="-tt" ` [08:20] ok - cool, I look at it [08:20] thanks for your feedback [08:20] great, thanks for asking :) [08:21] snapd is now at 2.30-4 in sid :) [08:21] mwhudson: thank you for pushing that! [08:21] mvo: yup, the latter [08:21] mborzecki: ta! [08:22] mvo: btw. it'd also be a nice feature to be able to disable filtering out of pre snap-exec starce output [08:23] mvo: does the method to run strace scale to things like gdb? [08:23] PR snapcraft#1869 closed: cli: exported login should only be readable by owner [08:23] mborzecki: interessting idea [08:23] mvo: though gdb is also more complex because od symbols [08:23] and valgrind? ;) [08:23] hmm [08:24] I need to reboot my laptop [08:24] zyga: for gdb one would have to automatically set a breakpoint at "execve("the-snap-app")" and then run it [08:24] it goes crazy after suspend and all the textures blink [08:24] just kidding, valgrind is tricky for many reasons I suppose.. just gdb would be cool [08:24] brb [08:29] PR snapd#4490 opened: tests/main/snap-service-after-before: add test for after/before service ordering [08:30] hmmm [08:30] I think I need to power it off [08:30] it's still wonky [08:30] and wifi is wonky too [08:30] the year of linux desktop :P [08:33] * zyga looks for debian topics on the forum [08:37] PR snapd#4491 opened: snap: allow options for --strace, e.g. `snap run --strace="-tt"` [08:38] kalikiana: hey, iirc you had some suggestion for `snap refresh --amend`, a better term. now is a good time to add them to 4356 as samuele also expressed that its not super clear to him [08:40] mvo: I didn't like amed too [08:40] mvo: I proposed one alternative on the forum but I forgot what it was [08:43] mvo: I could think: --reestablish otherwise I thing we need more than one word with store in it somehow [08:43] *I think [08:44] pedronis: I like --reestablish - feel free to add to the PR. I'm addressing your comments now fwiw [08:45] mvo: and we have other plans for "replace" [08:45] that might happen or not, but I don't think we want to use that [08:46] pedronis, mvo: I commented on the PR https://github.com/snapcore/snapd/pull/4356#discussion_r160633033 [08:46] PR #4356: many: add new `snap refresh --amend ` command [08:49] * kalikiana getting more tea, with an extra slice of lemon [08:51] mvo: put a rambling there about this [08:51] ta [08:59] snapd 2.30 on debian sid works well, spotify, gimp and brave tested [09:00] yay [09:00] mvo: will the strace PR will work with classic snaps too? [09:02] mborzecki: classic snaps don't need anything for strace [09:02] though it'd be nice if they also worked with the same U [09:02] \UI [09:03] what i meant if you do `snap run --starce ` will it work too? [09:03] right [09:03] I don't know :) [09:04] mborzecki, zyga: do we run snap-confine on classic snaps at all? iirc we do and if so strace should work [09:09] zyga: np, does it work? :) [09:10] mwhudson: yes [09:10] oh good [09:10] mwhudson: with apparmor enabled [09:11] so good work :-) [09:11] mvo: tried `snap run --strace` with a classic snap just now, works fine :) [09:11] i should send some of the changes your way [09:11] mborzecki: \o/ [09:11] the "arch all only builds fail" thing would happen with ubuntu packaging too i'm fairly sure [09:12] mvo: https://paste.ubuntu.com/26396653/ the default value for --strace in --help is a bit confusing, i think you need to add `default-mask:""` or something similar [09:19] mborzecki: aha, good point. quirks with the go-flags [09:19] mborzecki: thanks, let me fix this [09:21] mborzecki: there is a failure in 4490 on 14.04 that looks vaguely ral [09:21] real === __chip__ is now known as Chipaca [09:25] good morning peeps [09:25] Chipaca: hey, good morning! [09:25] just popping in to let you know (because I completely forgot yesterday) [09:26] mvo: thanks, looks like the formatting changed between systemd versions :/ [09:26] that i've got two long parent meetings at the school today, so i've taken half a day off [09:26] Chipaca: morning [09:26] mborzecki: :( [09:26] hey there john! [09:26] so, hello and goodbye :-) [09:26] mborzecki: oh, "fun" [09:26] Chipaca: sure - when you have a moment 4489 is an easy win [09:26] how can projects do that :/ [09:26] or someone else :) [09:26] mvo: ack [09:27] mvo: reach me on telegram if you need me though [09:27] zyga: systemctl --porcelain :) [09:28] mvo: did you see http://travis.debian.net/ ? :) [09:29] would be cool to have instructions like that for snapcraft [09:30] zyga: might cool [09:31] mborzecki: you mentioned you would be interested in havng "snap run --strace" not hide anything (so include the snap-confine traces). do you think a environment options is appropriate? or an extra option to `snap run --strace-it-all` or something? [09:33] mvo: enabling it via environment sounds good to me, SNAP_STRACE_EARLY=1 or something similar [09:37] zyga: what's the motivation for wanting to update snapd in stretch? [09:38] the version released with stretch re-execs i think... [09:38] mwhudson: yes, thought I don't know if that enables all the features [09:38] mwhudson: it would be a nice thing to update it [09:38] mwhudson: flapak gets the updates, for example [09:38] oh ok [09:43] zyga: looks like the newest flatpak is only in backports? [09:43] which would be an easier thing to do i guess [09:45] mwhudson: yes, that's a good thing IMO [09:49] PR snapd#4492 opened: spread: try to enable Fedora once again [09:54] mvo: can you please try to review https://github.com/snapcore/snapd/pull/4471 today? [09:54] PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS [10:07] * zyga cannot stop laughing [10:07] https://twitter.com/Lilobase/status/952504781515509761 [10:09] PR snapd#4489 closed: vendor: remove x/sys/unix to fix builds on arm64 and powerpc [10:11] PR snapd#4482 closed: cmd/libsnap-confine-private: add debug build of libsnap-confine-private.a, link it into snap-confine-debug [10:11] mborzecki: 4483 has feedback - seems super close to handling [10:11] zyga: sure, going over the open PRs now [10:12] mvo: thanks for the reviews [10:12] thank you! :) [10:16] mborzecki: the failure in bboozzoo/snap-mgmt-extend-tests is very strange, could you please merge master and see if it persists? does not make much sense to me (spread failure in go unit tests on 14.04) [10:19] mvo: i'll be pushing more commits in a while and i'll merge master as well [10:20] mborzecki: ta [10:33] mvo: i'll have to open a follow-up pr anyway, for now i only merged master and pushed to #4480 [10:33] PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services [11:02] mvo: so far we implemented Type=notify for snapd but no the watchdog stuff, right? [11:20] fedora currently fails with: 'No package golang(github.com/Thomasdezeeuw/ini) available.', any ideas? [11:23] that's a new dependency [11:23] we need to package it apparently [11:27] * kalikiana taking a break, not feeling awesome at all [11:27] Bumping into some problems with using iptables on ubuntu core. I have been trying to put in some dnat rules and they have not be working at all. Tcpdump is showing the packets going to the host machine. Any thoughts? [11:28] Alexander_: hmm, are the right modules loaded? [11:28] from a quick survey, github.com/go-ini/ini seems to be avialble in fedora/ubuntu/debian [11:29] and this one too github.com/vaughan0/go-ini [11:30] zyga: I do not know, I have just been call iptables from command line in normal userspace and the "classic" space. How could I find out? [11:30] Alexander_: lsmod may tell you that [11:31] mborzecki: maybe it's just a missing dep then, low hanging fruit to add [11:31] zyga: you mean replace github.com/Thomasdezeeuw/ini with one of the 2 i listed above? [11:32] mborzecki: ah [11:32] sorry I misread [11:32] I think go-ini is the one that pedronis was unhappy about [11:33] but if that's not the case and we could use that then yes, that's a quick win [11:36] $ lsmod | grep ip [11:36] gives me [11:36] iptable_filter ip_tables ip6table_filter ip6_tables x_tables [11:37] I assume ip_tables is the support for iptables? [11:38] zyga: mborzecki: mvo proposed to use our old goconfigparser, that should have been packaged already too [11:39] pedronis: is it in the tree now? [11:39] mborzecki: no, it's on github though [11:40] probably best to wait for mvo to decide what to do [11:40] ok [11:44] hmm [11:44] I'm learning more aboud dbus the hard wy [11:44] way* [11:45] pedronis, zyga either way is fine with me, if we decide on the old parser I'm happy to look into the porting [11:45] mvo: I think I would prefer the old parser over go-ini [11:46] pedronis: works for me, I will look into the porting (unless you want to do it) [11:46] dbus is the debil [11:46] ikey: debil? [11:46] devil. [11:46] ah :D [11:46] in polish debil has another meaning and I was now wondering if that's an english word as well [11:46] ah ok [11:46] waterboy reference :P [11:47] https://translate.google.com/#pl/en/debil ;-) [11:47] hah nice [11:47] that works too [11:49] pedronis: heh, fun! goconfigparser is even part of the vendoring still as we use it in one of our tests [11:50] mvo: yes, I see [11:52] pedronis: fwiw, I addressed the points in 4356 [11:55] don't remember the details of fedora policy on go packages, but if it's under vendor then there musn't there be a real package with that dep too? [11:56] mborzecki: it depends on where it is, it needs to be marked as an embedded package, in some places it's embedded (centos) and in some places it's not (fedora) [11:56] mborzecki: that's what I remember, I'm sure Pharaoh_Atem can correct me if I'm wrong [12:04] zyga: i think https://github.com/snapcore/snapd/blob/master/dirs/dirs.go#L234 is causing https://bugs.launchpad.net/snappy/+bug/1743301 korora is derived from fedora and apaprently it's picking the wrong libexedir [12:04] Bug #1743301: cannot install apps using snap on Korora [12:04] pedronis: I pushed a PR and have lunch now. wonder if I should add more unit tests for the error cases? or do you think its sufficient? [12:04] PR snapd#4493 opened: image: port ini handling to goconfigparser [12:05] zyga: we should do release.DistroLike() probably [12:05] zyga: do you know what os-relase looks like on rhel and cetos? [12:08] mvo: I think the error handling is easy enough to follow [12:08] mvo: pushed couple of comments [12:08] mborzecki: looking [12:08] mborzecki: yep [12:09] mborzecki: sure [12:09] mborzecki: one sec... [12:09] https://github.com/zyga/os-release-zoo/blob/master/redhat/rhel7.txt [12:09] https://github.com/zyga/os-release-zoo/blob/master/centos/centos-7.txt [12:09] :-) [12:09] enjoy! and add anything you find missing please [12:09] zyga: hah, thanks [12:09] * zyga still fights dbus [12:10] zyga: url open thing? [12:11] mborzecki: hmm? [12:11] mborzecki: ah, yes [12:11] but in reality dbus bug [12:11] interesting, does it warrant a blog post? :) [12:11] mborzecki: ha, I can write about that though it's pretty obscure and I haven't fixed it yet [12:13] * pstolowski lunch [12:18] hey there neal! [12:27] zyga: https://github.com/zyga/os-release-zoo/pull/26 [12:27] PR zyga/os-release-zoo#26: korora: add Korora 26 [12:28] merged [12:28] thank you [12:29] man [12:29] building dbus sucks, it's hediously complex [12:29] I ended up rebuilding the package [12:30] I have no idea how things get configured apart from 'by magic' there [12:52] PR snapd#4494 opened: dirs: check if distro 'is like' fedora when picking path to libexecdir [12:58] * Chipaca is back but really exhausted from the meetings [13:01] joining [13:01] Speaking of which, I won't join you today [13:04] niemeyer: thanks for the heads up! [13:07] ogra ping [13:07] ondra, yo [13:20] PR snapd#4307 closed: tests: fix "job canceled" issue and improve cleanup for snaps [13:27] pstolowski: sudo snap debug get-base-declaration [13:27] zyga, thanks! [13:29] * Chipaca hugs niemeyer === Joneleth1 is now known as JonelethIrenicus [13:31] pstolowski: do you have a pointer to a place where we iterate of attrs (not constraints) [13:31] pedronis, 1 sec [13:32] what do I have multiple snappy cores? [13:33] JonelethIrenicus: pardon? [13:34] if I open up something like firelight I see mutliple snappy core "disks" [13:35] old versions [13:35] /snap/core/3604 [13:35] /snap/core/3748 [13:35] etc.. [13:36] for rollback [13:36] PR snapcraft#1873 opened: elf: cleaner patchelf experience [13:36] JonelethIrenicus: those are multiple revisions of one snap [13:36] JonelethIrenicus: snapd maintains up to three revisions per snap [13:36] JonelethIrenicus: they get recycled automatically [13:36] on classic you always need to have two ... on ubuntu-core you need three (two for rollback, one for factory reset) [13:37] i see [13:37] (i think snapd doesnt make any difference between core and classic on that level currently, so you will end up with three on classic too ... ) [13:39] pedronis: I updated the ini pr and addressed your feedback (thanks again for this) [13:40] JonelethIrenicus: you can remove them if you need to via "snap remove --revision= " [13:40] Chipaca: good tip thanks [13:40] JonelethIrenicus: if you try to remove the current one it'll tell you to behave :-) [13:41] haha well that is never going to happen [13:41] mvo: looks good, you miss a bundled(...) in one of those packaging lines though [13:42] pedronis: uh, thanks. silly copy/paste [13:42] pedronis, hmm I think I was wrong and confused the loop over constraints with looping over attributes [13:43] does snapcraft need to know about after/before properties in apps now that the systemd after/before ordering is merged? [13:44] pstolowski: I suppose better this way, but that's what I wondered, because I don't remember code like that (but it was a long time ago) [13:46] pedronis, yes, that solves half of the problems [13:46] lunch is soon, let's do one more test [13:49] mborzecki: one question about 4494> did you check that rhel and centos have a DISTRO_LIKE=fedora ? i.e. that we won't regress on those? [13:49] PR snapd#4494 closed: dirs: check if distro 'is like' fedora when picking path to libexecdir [13:50] mvo: i checked in zyga's os-release-zoo https://github.com/zyga/os-release-zoo/blob/master/redhat/rhel7.txt https://github.com/zyga/os-release-zoo/blob/master/centos/centos-7.txt [13:50] mborzecki: neat, thanks [13:50] mborzecki: that project takes patches (e.g. korororora?) [13:51] sounds kiwi'sh [13:53] my dad skills have spilled into the forum! first time i've used "you (plural)" like that that i know of :-D [13:53] anyhoo, work calls [13:54] since korora is basically fedora, I wonder if Son_Goku could cherry-pick the patch when updating the package to 2.30 [13:54] mborzecki: which patch do I need to cherry pick? [13:54] Son_Goku: https://github.com/snapcore/snapd/pull/4494 [13:54] PR #4494: dirs: check if distro 'is like' fedora when picking path to libexecdir [13:54] mvo: I thought I had gotten all of these things when I attempted to fix this for Korora last time? [13:55] I swear I did... [13:56] oh, geez [13:56] there was another check for libexecdir [13:56] Son_Goku: :/ well, I guess we now have them all! [13:56] are we really sure this time? [13:56] now even I'm not sure... [13:57] mborzecki: but yeah, I'll be cherry-picking this [13:58] Son_Goku: great, thanks [13:58] mvo, could you just make sure the PR is cherry picked into the 2.30 branch? [13:58] it makes it easier for me to keep track of these things [13:59] Son_Goku: sure [14:01] Son_Goku: its in release/2.30 now [14:01] thanks [14:01] I'm going to be preparing the backport later today [14:01] err, upgrade [14:05] mvo: since you're cherry picking to 2.30, can you also pick https://github.com/snapcore/snapd/pull/4432 ? Son_Goku left a note there, but I don't see it in release/2.30 [14:05] PR #4432: cmd/snap, tests/main/classic-confinement: fix snap-exec path when running under classic confinement [14:05] mborzecki: sure, looking [14:06] mborzecki: done [14:06] mvo: thanks [14:06] mvo: I just want to avoid being forced to have my own source maint tree [14:07] because in my opinion, such things are counterproductive with ensuring fixes are upstream [14:07] (it's one of the reasons I dislike the Debian/Ubuntu model of packaging with gbp trees) [14:08] today, there's exactly ONE downstream patch that's not upstream [14:08] Son_Goku: +1 [14:08] Son_Goku: ping me anytime if you need something cherry-picked [14:08] cool, thanks [14:08] zyga: 4483 needs a second review, iirc you looked at this before so should be trivial [14:09] God knows, I could actually do my own source trees for packaging, but I hate that stuff [14:09] it's far too easy to get lazy and complacent [14:09] Son_Goku: plus the collaborating with upstream is usually very healthy [14:09] yeah [14:10] (and great for upstream because they understand the needs of the packages better etc etc) [14:10] I think what really burned me was my experience with Debian as an upstream software developer [14:10] one of my software packages was effectively forked and they never bothered to talk to me [14:10] meanwhile I was listed as a contact point in the copyright, so I got weird questions from people using the Debian version [14:11] Son_Goku: uh, that sucks - may I ask what the package name was? [14:11] lugaru / openlugaru [14:11] they'd also converted the source tree from Mercurial (as it was at the time) to Git [14:11] which meant it was painful to figure out where they actually were [14:12] Son_Goku: uh, I see, that sounds painful [14:12] needless to say, it annoyed me [14:12] Son_Goku: *nod* [14:13] when development of lugaru restarted, I switched to Git (as everyone else wanted it), and did significant work [14:13] Son_Goku: I hope it got better over time [14:13] unfortunately, their little weird tree meant that they spent a year arguing about how to refork the source tree into Alioth for packaging [14:14] Debian was *the last* distribution to get the new Lugaru, and they missed the first release [14:14] I wish it wasn't common practice to fork source trees for packaging in Debian, because it seems to lead to people cheaply patching things without talking to upstream [14:15] the upstream project (that is me and a couple of others) requested that they didn't fork the tree again, and we were told to butt out :( [14:16] it's not like I don't understand how to handle the upstream/downstream relationship [14:16] but that was cold :/ [14:16] Son_Goku: :( [14:16] Son_Goku: sorry to hear this bad experience [14:16]