=== chihchun_afk is now known as chihchun [06:06] morning [06:38] Good morning [06:38] Libc never ceases to surprise [06:38] zyga: hey [06:38] zyga: what happened? [06:41] I sent a small PR for a bug that was reported after recent TW update [06:41] https://github.com/snapcore/snapd/pull/6167 [06:42] apparently? libmount is libc now? [06:42] we end up linking to it [06:45] hm, why haven't i seen it on arch? [06:47] not sure [06:47] ldd snap-confine [06:47] zyga: what's the version of glibc you have there? [06:47] what do you see? [06:47] one sec [06:48] lib{mount,uuid,blkid} are not part of glibc package on arch [06:48] 2.27-6.1 [06:48] perhaps I'm wrong [06:48] i'm on 2.28 [06:48] and this is via libudev? [06:48] I should read changelogs [06:50] zyga: nope, libudev seems to pull in libc only [06:50] magic :) [06:50] checking those changelogs [06:50] zyga: does ldd snap-confine show anything interesting? [06:51] https://www.irccloud.com/pastebin/dSCqaDe2/ [06:51] woo [06:51] that we really link to those guys [06:51] https://paste.fedoraproject.org/paste/a4oL699BiGrowxA0ATuRzA/raw [06:52] now how do I get changelogs on suse.... [06:52] zyga: missing --as-needed? [06:52] rpm -q --changelog? [06:53] it's odd that this broke after recent update [06:53] the -1 package was OK [06:54] then TW synced [06:54] then it was broken [06:54] linking didn't change [06:56] zyga: was that a new tw snapshot? [06:56] yes [06:57] zyga: if you're using tumbleweed-cli you could switch to the previous one [06:57] zyga: heh there's even libpcre in the ldd output you posted :) [06:58] yep [06:58] but that was not new [06:58] * zyga wonders how to resolve bug like boo#1113188#c1 to a link [06:58] suse bugzilla? [06:59] https://bugzilla.opensuse.org/show_bug.cgi?id=1113188#c1 [07:00] unrelated but explains /run/run bug [07:48] zyga: found anything interesting? [07:48] nope [07:49] it's low priority, I think this is fine for now [07:49] I'm working on more mount bits [07:49] over weekend I experimented with transactional security setup [07:49] it looks super promising [07:49] but to measure I would love to add some helper for checking how long stuff takes [07:49] need to think about that [07:50] having said that, I need to get more bits merged [07:50] super simple review: https://github.com/snapcore/snapd/pull/6150 [07:52] 6153 needs a second review (if somone has a bit of time) [07:53] sure [07:53] good morning mvo :) [07:53] and good morning zyga - you looked at this already [07:53] uh, I already did [07:53] :D [07:53] zyga: :) [07:53] mvo: can you look at https://github.com/snapcore/snapd/pull/6150/files [07:53] samuele suggested a different option name [07:53] consistency vs explicitness [07:54] either way I just want to merge it and move on, it's an internal option [07:56] zyga: no opinion on the option, if it grows what it means your approach is better, if not samuele is cleaner. given that its internal I don't worry much === pstolowski|afk is now known as pstolowski [08:10] morning [08:13] mvo: pstolowski: morning guys [08:13] samuele is at the sprint right? [08:13] hey mborzecki and pstolowski ! [08:14] mborzecki: correct, he is at a sprint [08:16] mvo: does #6164 replace #6156? [08:17] mborzecki: its build on top [08:17] mborzecki: its just one more step to cleanup things [08:17] mvo: ok [08:20] hey pawel [08:23] zyga: left some comments under 6150 [08:23] looking [09:02] sergiusens: hey, can you give me a hint about how I can resolve "Failed to pull source: unable to determine source type of './snap/patches'." ? I see this in https://github.com/snapcore/core/pull/99 and when I try to put my patches under snap/patches [09:04] mborzecki, mvo: pushed better parsing [09:04] zyga: to what PR? [09:04] https://github.com/snapcore/snapd/pull/6150 [09:06] jdstrand_: hey, could you please have a look at tiny fix at https://github.com/snapcore/snapd/pull/6167 [09:19] * zyga didn't have breakfast [09:22] zyga: updated the review, please don't hate me :) [09:57] zyga: mvo: need advice, for rhel/centos we'll need to drop a file to /etc/sysctl.d, do you think it should live in our sources somewhere under data/ or rather under packaging/fedora/ ? [09:58] mborzecki: what does it contain? [09:58] mvo: `fs.may_detach_mounts=1`, that's all [09:59] mborzecki: do you think that is something we will reuse at some point? if so data/ sounds right if exclusive to RHEL I think the packaging is right [09:59] mborzecki: if in doubt, data/ I think - with a comment in the file maybe? [09:59] mvo: no it's RHEL kernels specific [09:59] mborzecki: also plz a comment line saying why it's needed [09:59] Chipaca: ack [10:00] mborzecki: a couple of years from now you'll be director of our globular nano-satellites division and nobody'll remember why rhel 9 carries the file, but _you_ put it there so it stays [10:01] hahah [10:01] btw. let me quickly spin rhel 8 beta to check if the option is still there, otherwise it'll fail miserably [10:03] Chipaca: heh - and good morning! [10:03] mvo: :-) [10:05] and it's not htere [10:06] mvo: looking [10:06] mborzecki: in our sources IMO [10:08] zyga: right, but more like data/rhel/99-ugly-tweak.conf or packaging/fedora/99-ugly-tweak-conf? [10:08] mborzecki: can we just have it unconditionally? [10:08] I mean, does it hurt? [10:09] mvo: apt-hooks test times out [10:09] 2018-11-19 09:51:32 Error executing google:ubuntu-18.04-64:tests/main/apt-hooks : [10:09] lots of sleep 1 [10:09] then killed [10:13] arch uses Wl,--as-needed to minimize libs linking maybe suse does not [10:14] mborzecki: thanks for your review for 6164 - the xdg-mime comment makes sense, what is your suggestion? leave the name as is? just filter out some chars? or always sort the globs? [10:18] mvo: i think i'm leaning towards replacing + with _ in he original name and leaving them unchanged otherwise [10:19] mborzecki: sounds good, will update the PR [10:39] I just found that snaps are unusable when someone uses aa-notify :( [10:40] vidal72[m]: isn't that an issue with audit[d] not being set up on the machine? [10:40] vidal72[m]: do you get too many denials? or why unusalble? [10:40] yes, too many denials [10:41] vidal72[m]: which snap is causing this? [10:42] I tested it with chromium but I think it's similar with all profiles [10:43] snap profiles would have to 'deny' everything not alowed [10:43] when I open files dialog I have denials for every dotfile [10:46] mvo, mborzecki: about the parser, I was thinking how this should be and the initial short version while not perfect was short and worked, the longer version is handling various cases and also works, the medium-length proposals are ... okay, I guess but they handle less standard syntax and are not super short either. I would rather do one of the extremes (short and simple but not super smart OR one that's reasonably correct, [10:46] simple and maintainlable, even if longer) [10:46] I would rather do the regular parser like in snap-confine, with tests, than a not-fully-baked one you both proposed [10:46] mvo: please pick the direction, I will do as you wish [10:47] mvo: I also said in the PR that with a fully baked parser we could share some code with snap-confine as well [10:48] though that is not a priority now [10:48] zyga: I think as short as possible unless we need more, everything else feels like yagni. once we need more we can do a full solution [10:48] zyga: in the "medium" one, what is too much? cut it down as much as needed and I think its fine [10:49] it's almost the same length as what is in the PR now [10:49] and I'd argue that the longer code is easier to understand and extend [10:49] zyga: is it? i counted ~40 lines vs 15 or so, did I misread? [10:50] both are screen-size [10:50] not a saving [10:50] compared to the 3 lines that the initial version that was simplistic had [10:50] zyga: just subscribe samuele and let him decide, I think we just have different opinions on what is easier to read. I will respect whatever he decides [10:51] mvo: can we not do this [10:51] this will waste more time [10:51] I'll do as you suggested [10:51] zyga: right, I think the simplistic one is fine I would just add an extra check that not too many args are passed, iirc that was what was missing, no? [10:52] zyga: i.e. just https://github.com/snapcore/snapd/pull/6150/commits/efef054dbe657b86e611405c36d593bec6f70c71#r234522318 [10:52] it was checking argc so not sure [10:52] https://github.com/snapcore/snapd/pull/6150/commits/efef054dbe657b86e611405c36d593bec6f70c71#diff-dd2649824008f9aa9cd0f650906c71bfR44 [10:53] zyga: oh, sorry, let me look at the original again, iirc there was something that mborzecki pointed out missing [10:56] I reverted [10:57] zyga: thanks, I prefer this over the other one for sure. if you don't want to add the check for invalid options that fine, it will still fail if snap-discard-ns --invalid-option snapName is used so no harm here (plus its internal) [10:58] yeah [10:58] mborzecki, pstolowski if you have a moment a second review for 6153 would be nice [10:58] that's fine, I just want to land this and iterate [10:58] zyga: yeah, I will approve, I don't feel super strong about this particular check [10:58] looking [10:59] I can add a check but not sure if it changes the flow now, if we pass two args and argv[1] is not --from-snap-confine it will just treat is as a snap name and fail [11:00] zyga: yes [11:01] zyga: (I approved based on that it will fail with an incorrect option) [11:01] pushed [11:01] https://github.com/snapcore/snapd/pull/6150/commits/cccc3543069dbd35fa75aa2632d99dddda15193b [11:02] I think this capture the essence of the original review [11:02] zyga: thank you! [11:02] thank you both! :) [11:02] zyga: yeah, totally fine [11:08] mvo: +1, one question there [11:24] 6156 also needs a second review :) [11:24] mmm [11:24] ah, interesting! [11:25] mvo: nice idea with + [11:25] snap+ foo [11:25] snap+foo_bar [11:26] zyga: yeah, this way we keep being backward compatible [11:26] indeed [11:27] I didn't read the diff but we should note that + is a reserved character for this purpose next to snap validation functions [11:27] in case we forget and decide to package g++ ;) [11:29] zyga: good point [11:29] I think right now we only reserve what. [11:29] dot, dash, underscore and plus? [11:29] . for snap.app.foo separation [11:29] dash for ... not sure [11:29] underscore for instances and udev [11:30] and plus for desktop and instances [11:30] I guess dash is not reserved [11:36] * mvo nods [11:48] opening centos spread in a bit [11:49] one last thing to figure out, bash 4.2.46 doesn't have 'watch -n' so cgroup-freezer test fails, need to find a workaround as it'd be nice to have this test running there [11:52] mmm [11:52] ppisati, i have one of the new pi3 A+ here ... had to update the firmware and u-boot in the gadget to make it work ... it works fine, BUT ... enabling the kms dtb overlay gets me a black screen (zero output) and an OOPS in dmesg ... https://paste.ubuntu.com/p/6R9zrtBkN2/ [11:53] mborzecki: you mean wait -n, right? [11:53] ppisati, with core16 ... 4.4 kernel (1101 build) [11:54] mborzecki: can we just wait on the PIDs? [11:54] mborzecki just: wait "$pid1" [11:58] worth trying [11:58] i'll push self checks for rhel in a separate pr [11:58] or more like self check for kernel < 3.18 [11:59] ogra: uhm, where did you get the dtb? [12:00] ogra: btw, i just got one [12:03] tests are not happy today [12:04] apt-hooks are failing more than ususual [12:04] I'll finish one branch and look at why they fail [12:10] shellchecks failing on tests? https://paste.fedoraproject.org/paste/Fwd6Maa3xgGP9w3sAjZ79w/raw [12:12] uh [12:12] \n strikes again [12:13] mvo: ^ [12:13] gpio [12:16] https://github.com/snapcore/snapd/pull/6168 [12:16] hm mup is silent again :) [12:23] mvo: are you looking into the shellcheck or should i open a quick pr? [12:27] darn, bad keypress [12:27] https://github.com/snapcore/snapd/pull/6169 - shellchecks [12:27] suspended vm [12:28] ppisati, from the gadget as usual ... the same Sd boots just fine on a normal b+ (which should theoretically be identical ... though obviously it isnt) [12:30] ppisati, it seems to use bcm2710-rpi-3-b-plus.dtb [12:41] hmm, though cpuinfo shows a BCM2709 [12:51] mvo, mborzecki: I believe you reviewed the original https://github.com/snapcore/snapd/pull/6170/files [12:52] s/facts/features/ === cpaelzer__ is now known as cpaelzer [12:59] pushed a small test cleanup there as well [12:59] mvo: I'll break for lunch now and then look at that apt-hooks test failure [13:01] off to pick up the kids [13:04] off for lunch [13:14] zyga: hey, done [13:15] Hey :-) [13:16] Thank you [13:22] zyga: ta [13:23] mborzecki: I look for the shellcheck now [13:24] mborzecki: aha, you did already, thank you === jdstrand_ is now known as jdstrand [13:37] zyga, did you make any progress on mkosi based base snap building? [13:38] mvo: zyga: hi, in the lunch break here, I saw you were discussing whether I have opinions on something, please do mark PRs either as review requests for me, or ping me from them if needed, I'll try to do a quick PR pass each day at some point if it doesn't get too deep [13:41] Son_Goku: it's ready, I think the branch got merged upstream [13:41] pedronis: it's done, we found a simpler solution that wasn't controversial [13:41] obviously apt hooks don't fail when I want them to [13:41] zyga: ah, ok [13:42] I'll keep trying while working on more features [13:42] pedronis: thank you, how is the sprint going? [13:42] good, mostly in the intro phase still [13:42] pedronis: do you want to review the epochs followup pr? [13:45] zyga: same for me :( I ran tests for apt hooks in qemu and its fine [13:45] Chipaca: ah, the follow up, is it up? [13:45] not stricly [13:45] pedronis: writing its description right now [13:45] mvo: yeah, I will look at changing the test to fail faster and have debugging in case it happens [13:46] hey, can anyone give me a hint about how I can resolve "Failed to pull source: unable to determine source type of './snap/patches'." ? I see this in https://github.com/snapcore/core/pull/99 and when I try to put my patches under snap/patches [13:46] Chipaca: shouldn't block on me, I can skim it tough, I suppose is relatively small [13:46] zyga: I wonder if its related to a new apt [13:46] zyga: mvo: I wrote somethin again about that command option btw [13:46] mvo: new apt in bionic? [13:47] pedronis: thank you, looking [13:47] zyga: not really that new so probably not it [13:47] pedronis: thank you [13:48] pedronis: it's 6172 fwiw [13:49] mvo: is there any command that would ensure that commands.db is fetched? [13:50] I don't see one in postDebug [13:50] linkedin says i've been at canonical for 10 years [13:50] :-) [13:50] zyga: easy one is to start snapd [13:51] mvo: would you feel OK if I add something like "snap debug ensure-commands-db" or similar? [13:51] zyga: it's done every startup [13:51] Chipaca: woot, congratulations! :) [13:51] zyga: I'd be +1 to 'snap debug xyzzy' looking for snap-debug-xyzzy in PATH [13:52] but also this one should be simple [13:52] Chipaca: mmmm that sounds fine but how does that help? [13:52] it doesn't [13:52] :-) [13:52] I would just like to add a debug api handler for that name [13:52] * Chipaca is being super "helpful" [13:52] ah :-) [13:52] * zyga hugs Chipaca [13:52] but [13:52] I would like to add "snap tool snap-discard-ns" [13:52] zyga: don't call it ensure-commands-db [13:53] zyga: and don't call ensure from it [13:53] k [13:53] zyga: call refreshCatalogs [13:53] zyga: otherwise you get the timer check :-) [13:53] thanks! [13:53] I'll do that [13:54] zyga: and you could call it refresh-catalogs :-) [13:54] yeah, sounds great [13:54] Chipaca: +1 but one question [13:54] anyway, i forgot to have lunch [13:54] Chipaca: oh [13:54] * Chipaca goes to heat up leftovers [13:54] 6 minutes [13:54] Chipaca: which is not I think about code that was changed [14:12] hey folks! Where do ubuntu-core bugs go? something like failure to create user on device: "error: while creating user: cannot create user for "E-MAIL-ADDRESS": no ssh keys found" ? [14:12] mvo: do you know this by any chance? ^^ [14:12] Wimpress: hi, are you a good person to poke on the forum re: transfers to snapcrafters? [14:12] roadmr: in a meeting right now. does the user have ssh keys attached to the account? [14:13] mvo: probably not. I can wait until you're finished, no rush :) [14:13] roadmr: Probably. What do you need? [14:13] roadmr: yeah, happy to talk more then, but in general we need some keys or adding the login is not helpful (no way to login for this user) [14:13] Wimpress: two snap transfers *to* snapcrafters, just need ack from the team and I can process them. If you're OK with it, I'll poke you in the relevant threads [14:14] Which Snaps out of interest? [14:14] mvo: sure thing, let me know when done and we can see [14:14] I've been OOTO [14:14] Wimpress: mr robOOTO? :P [14:14] Wimpress: qxmledit is one of them, I'll find the other one [14:15] popey: Do you know anything about this? [14:15] hm? [14:16] Wimpress: ah, the other is none other than hello-snapcrafters :D [14:18] a @snapcrafters forum team would be nice (like @reviewers) but that might be spammy to you folks :/ [14:21] Not a bad idea actually [14:22] \o/ [14:23] popey: tangent, is ev on holiday or otherwise off this week? [14:24] Yes [14:24] oh! bummer for me, but good for him :) [14:25] popey: we had a question about a small refinement for the snap name registration form, we were hoping to get advocacy team feedback. Who else might help us with this? [14:25] snap-advocacy@canonical.com :) [14:26] fantastic \o/ (sorry, guess I should have known about that) [14:43] roadmr: I'm back now - so this error - can you or someone from the store check if the user has ssh keys on the account? or is the actual issue that the error message is too cryptic? [14:43] mvo: thanks for getting back to me! here's the bug as filed [14:43] https://bugs.launchpad.net/canonical-identity-provider/+bug/1803875 [14:44] mvo: the basic problem is that he indeed has no SSH keys: https://launchpad.net/~grayslash [14:45] mvo: it's definitely not a canonical-identity-provider bug, I need to move it to the appropriate project but not sure which one that would be. Maybe console-conf, which should tell users to create their account and add SSH keys before trying to register the account on the device? [14:45] roadmr: yeah, that sounds good [14:45] roadmr: console-conf sounds like a good choice for the bug [14:45] * roadmr now tries to find the LP project for console-conf :D [14:46] roadmr: try subiquity [14:46] yay! [14:47] thanks mvo, moved. I guess I could have done all this without troubling you :/ heh [14:48] roadmr: no worries [14:48] #1804006 is interesting [14:50] hooks are still underused, thank you for finding that [14:50] do y'all think that's a snapd bug or a snapcraft bug? [14:53] it is a snapcraft bug [14:53] snapd doesn't have this bug [14:54] snapd needs to know about hooks to introduce plugs and slots to them [14:54] once declared we properly attach all interfaces, as to apps [14:54] one could argue that the bug was to allow undeclared hooks [14:54] that feels IMO like the thing that caused the complexity to arise [14:54] okay, so it sounds like by design the root level `plugs` in snap.yaml is not supposed to affect hooks? [14:54] stokachu: hey. If snapd can't connect to localhost port 53, that's *probably* not a "snap store issue" you should dismiss a user's bug over [14:54] on snapcraft side the code to always declare hooks would be simple [14:55] but as the system stands today it's too late to do that [14:55] ijohnson: that's incorrect [14:55] ijohnson: top level plugs and slots affect declared hooks [14:55] Chipaca: what? [14:55] but if you don't declare a hook in snap.yaml then there's nothing magically guessing that [14:56] we *do* run discovered but undeclared hooks [14:56] and then they don't run with any interfaces [14:56] stokachu: aren't you battlemidget on https://github.com/conjure-up/conjure-up/issues/1542 [14:56] all day [14:56] I see what you mean that makes sense [14:56] perhaps that is a snapd bug after all but it's complex to untangle now [14:56] stokachu: so, yeah, that [14:56] pstolowski: do you think we should discover hooks every time we load snap.yaml? [14:56] stokachu: lookup api.snapcraft.io on [::1]:53: read udp [::1]:47619->[::1]:53: read: connection refused [14:56] so that we can properly add slots and plugs to hooks that are not declared [14:57] stokachu: that's not a snap store issue [14:57] yep [14:57] k [14:58] * Chipaca goes for tea [14:59] Teapaca? [14:59] chai :) [15:00] chaipaca? :) [15:00] zyga: I'm curious about what the blob of molten plastic was in the end [15:01] roadmr: it didn't fail this time [15:01] roadmr: but I had it fail to print sometimes [15:01] the object would detach from the heatbed [15:01] ouch [15:01] the hot end would grab a hold of it by accident [15:01] it would melt and "stick" to the extruder [15:01] zyga: don't we do already? see info.go - ReadInfoFromSnapFile -> addImplicitHooksFromContainer [15:01] the extruder kept oozing stuff [15:01] sounds messy [15:02] roadmr: yes :-) [15:02] Chipaca: we good? [15:02] pstolowski: https://bugs.launchpad.net/snapcraft/+bug/1804006 [15:02] Chipaca: btw, we do add interfaces to hooks [15:02] pstolowski: perhaps it's out of sync [15:02] pstolowski: we load yaml, attach plugs and slots to hooks [15:03] then we notice more hooks on disk [15:03] and we don't do anything else to connect the dots [15:03] stokachu: dunno. Bug's still closed at your end, but I don't know what the issue is about [15:03] stokachu: just know it's not in the realm of things that we can help with [15:03] * zyga needs to catch a bus now [15:04] zyga: take the XL butterfly net [15:04] Chipaca: then nothing for you to continue to worry about then, we good [15:04] stokachu: k [15:11] https://github.com/snapcore/snapd/pull/6173 - sanity checks for centos/rhel [15:17] zyga: the apt-hook error is a 403 from the api [15:22] zyga: ah, i see now, i had to read a little bit of the backlog, and look into the code. indeed. [15:22] seems to be the case === on is now known as Guest70909 [15:54] sergiusens: is there a way to avoid building in a VM? e.g. --no-multipass or something? i'm already running my snapcraft tests inside a vm FWIW [16:05] ppisati: if you're using snapcraft 3.0, use snapcraft build --destructive-mode [16:08] roadmr: it still tries to launch a VM [16:08] ppisati: sounds like a bug to me, as that's the description for --destructive-mode :( [16:08] :( [16:19] just switch back to 2.0 ;) [16:19] roadmr: nm, i got it working [16:19] ogra: too late :) [16:19] *to work [16:22] what [16:23] 's going on with the apt-hooks test? [16:23] * zyga is stuck in traffic [16:23] mvo: is that something we retry? [16:23] ah, store 403ing [16:24] mvo: is that something we retry? [16:25] mvo: is that something we retry? [16:29] zyga: did you purposely send that three times, or is your client not only breaking tcp by doing out of order but also by repeating messages? [16:38] zyga: haha [16:39] zyga: I don't know, I was looking and then got side-tracked [16:39] Chipaca: I suspect its a demonstration of the issue (or a funny coincidence ;) [16:39] mvo: yeah i was wonderingering [16:40] zyga: in any case, we need to retry but if the store is really unhappy not much we can do :/ [17:02] Chipaca, zyga probably worthwhile to ping the store about the catalog update 403 (just in case). I will be off now for a bit to play hockey though :) [17:03] mvo: on it [17:04] mvo: (half an hour ago) [17:04] mvo: happy hockeying [17:08] back home [17:08] mvo: ack [17:08] Chipaca: re [17:08]