| === chihchun_afk is now known as chihchun | ||
| mborzecki | morning | 06:06 |
|---|---|---|
| zyga | Good morning | 06:38 |
| zyga | Libc never ceases to surprise | 06:38 |
| mborzecki | zyga: hey | 06:38 |
| mborzecki | zyga: what happened? | 06:38 |
| zyga | I sent a small PR for a bug that was reported after recent TW update | 06:41 |
| zyga | https://github.com/snapcore/snapd/pull/6167 | 06:41 |
| zyga | apparently? libmount is libc now? | 06:42 |
| zyga | we end up linking to it | 06:42 |
| mborzecki | hm, why haven't i seen it on arch? | 06:45 |
| zyga | not sure | 06:47 |
| zyga | ldd snap-confine | 06:47 |
| mborzecki | zyga: what's the version of glibc you have there? | 06:47 |
| zyga | what do you see? | 06:47 |
| zyga | one sec | 06:47 |
| mborzecki | lib{mount,uuid,blkid} are not part of glibc package on arch | 06:48 |
| zyga | 2.27-6.1 | 06:48 |
| zyga | perhaps I'm wrong | 06:48 |
| mborzecki | i'm on 2.28 | 06:48 |
| zyga | and this is via libudev? | 06:48 |
| zyga | I should read changelogs | 06:48 |
| mborzecki | zyga: nope, libudev seems to pull in libc only | 06:50 |
| zyga | magic :) | 06:50 |
| zyga | checking those changelogs | 06:50 |
| mborzecki | zyga: does ldd snap-confine show anything interesting? | 06:50 |
| zyga | https://www.irccloud.com/pastebin/dSCqaDe2/ | 06:51 |
| mborzecki | woo | 06:51 |
| zyga | that we really link to those guys | 06:51 |
| mborzecki | https://paste.fedoraproject.org/paste/a4oL699BiGrowxA0ATuRzA/raw | 06:51 |
| zyga | now how do I get changelogs on suse.... | 06:52 |
| mborzecki | zyga: missing --as-needed? | 06:52 |
| mborzecki | rpm -q --changelog? | 06:52 |
| zyga | it's odd that this broke after recent update | 06:53 |
| zyga | the -1 package was OK | 06:53 |
| zyga | then TW synced | 06:54 |
| zyga | then it was broken | 06:54 |
| zyga | linking didn't change | 06:54 |
| mborzecki | zyga: was that a new tw snapshot? | 06:56 |
| zyga | yes | 06:56 |
| mborzecki | zyga: if you're using tumbleweed-cli you could switch to the previous one | 06:57 |
| mborzecki | zyga: heh there's even libpcre in the ldd output you posted :) | 06:57 |
| zyga | yep | 06:58 |
| zyga | but that was not new | 06:58 |
| * zyga wonders how to resolve bug like boo#1113188#c1 to a link | 06:58 | |
| zyga | suse bugzilla? | 06:58 |
| zyga | https://bugzilla.opensuse.org/show_bug.cgi?id=1113188#c1 | 06:59 |
| zyga | unrelated but explains /run/run bug | 07:00 |
| mborzecki | zyga: found anything interesting? | 07:48 |
| zyga | nope | 07:48 |
| zyga | it's low priority, I think this is fine for now | 07:49 |
| zyga | I'm working on more mount bits | 07:49 |
| zyga | over weekend I experimented with transactional security setup | 07:49 |
| zyga | it looks super promising | 07:49 |
| zyga | but to measure I would love to add some helper for checking how long stuff takes | 07:49 |
| zyga | need to think about that | 07:49 |
| zyga | having said that, I need to get more bits merged | 07:50 |
| zyga | super simple review: https://github.com/snapcore/snapd/pull/6150 | 07:50 |
| mvo | 6153 needs a second review (if somone has a bit of time) | 07:52 |
| zyga | sure | 07:53 |
| zyga | good morning mvo :) | 07:53 |
| mvo | and good morning zyga - you looked at this already | 07:53 |
| zyga | uh, I already did | 07:53 |
| zyga | :D | 07:53 |
| mvo | zyga: :) | 07:53 |
| zyga | mvo: can you look at https://github.com/snapcore/snapd/pull/6150/files | 07:53 |
| zyga | samuele suggested a different option name | 07:53 |
| zyga | consistency vs explicitness | 07:53 |
| zyga | either way I just want to merge it and move on, it's an internal option | 07:54 |
| mvo | 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 | 07:56 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 08:10 |
| mborzecki | mvo: pstolowski: morning guys | 08:13 |
| mborzecki | samuele is at the sprint right? | 08:13 |
| mvo | hey mborzecki and pstolowski ! | 08:13 |
| mvo | mborzecki: correct, he is at a sprint | 08:14 |
| mborzecki | mvo: does #6164 replace #6156? | 08:16 |
| mvo | mborzecki: its build on top | 08:17 |
| mvo | mborzecki: its just one more step to cleanup things | 08:17 |
| mborzecki | mvo: ok | 08:17 |
| zyga | hey pawel | 08:20 |
| mborzecki | zyga: left some comments under 6150 | 08:23 |
| zyga | looking | 08:23 |
| mvo | 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:02 |
| zyga | mborzecki, mvo: pushed better parsing | 09:04 |
| mvo | zyga: to what PR? | 09:04 |
| zyga | https://github.com/snapcore/snapd/pull/6150 | 09:04 |
| zyga | jdstrand_: hey, could you please have a look at tiny fix at https://github.com/snapcore/snapd/pull/6167 | 09:06 |
| * zyga didn't have breakfast | 09:19 | |
| mvo | zyga: updated the review, please don't hate me :) | 09:22 |
| mborzecki | 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:57 |
| mvo | mborzecki: what does it contain? | 09:58 |
| mborzecki | mvo: `fs.may_detach_mounts=1`, that's all | 09:58 |
| mvo | 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 |
| mvo | mborzecki: if in doubt, data/ I think - with a comment in the file maybe? | 09:59 |
| mborzecki | mvo: no it's RHEL kernels specific | 09:59 |
| Chipaca | mborzecki: also plz a comment line saying why it's needed | 09:59 |
| mborzecki | Chipaca: ack | 09:59 |
| Chipaca | 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:00 |
| mborzecki | hahah | 10:01 |
| mborzecki | btw. let me quickly spin rhel 8 beta to check if the option is still there, otherwise it'll fail miserably | 10:01 |
| mvo | Chipaca: heh - and good morning! | 10:03 |
| Chipaca | mvo: :-) | 10:03 |
| mborzecki | and it's not htere | 10:05 |
| zyga | mvo: looking | 10:06 |
| zyga | mborzecki: in our sources IMO | 10:06 |
| mborzecki | zyga: right, but more like data/rhel/99-ugly-tweak.conf or packaging/fedora/99-ugly-tweak-conf? | 10:08 |
| zyga | mborzecki: can we just have it unconditionally? | 10:08 |
| zyga | I mean, does it hurt? | 10:08 |
| zyga | mvo: apt-hooks test times out | 10:09 |
| zyga | 2018-11-19 09:51:32 Error executing google:ubuntu-18.04-64:tests/main/apt-hooks : | 10:09 |
| zyga | lots of sleep 1 | 10:09 |
| zyga | then killed | 10:09 |
| vidal72[m] | arch uses Wl,--as-needed to minimize libs linking maybe suse does not | 10:13 |
| mvo | 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:14 |
| mborzecki | mvo: i think i'm leaning towards replacing + with _ in he original name and leaving them unchanged otherwise | 10:18 |
| mvo | mborzecki: sounds good, will update the PR | 10:19 |
| vidal72[m] | I just found that snaps are unusable when someone uses aa-notify :( | 10:39 |
| mborzecki | vidal72[m]: isn't that an issue with audit[d] not being set up on the machine? | 10:40 |
| mvo | vidal72[m]: do you get too many denials? or why unusalble? | 10:40 |
| vidal72[m] | yes, too many denials | 10:40 |
| mborzecki | vidal72[m]: which snap is causing this? | 10:41 |
| vidal72[m] | I tested it with chromium but I think it's similar with all profiles | 10:42 |
| vidal72[m] | snap profiles would have to 'deny' everything not alowed | 10:43 |
| vidal72[m] | when I open files dialog I have denials for every dotfile | 10:43 |
| zyga | 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 |
| zyga | simple and maintainlable, even if longer) | 10:46 |
| zyga | I would rather do the regular parser like in snap-confine, with tests, than a not-fully-baked one you both proposed | 10:46 |
| zyga | mvo: please pick the direction, I will do as you wish | 10:46 |
| zyga | mvo: I also said in the PR that with a fully baked parser we could share some code with snap-confine as well | 10:47 |
| zyga | though that is not a priority now | 10:48 |
| mvo | 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 |
| mvo | zyga: in the "medium" one, what is too much? cut it down as much as needed and I think its fine | 10:48 |
| zyga | it's almost the same length as what is in the PR now | 10:49 |
| zyga | and I'd argue that the longer code is easier to understand and extend | 10:49 |
| mvo | zyga: is it? i counted ~40 lines vs 15 or so, did I misread? | 10:49 |
| zyga | both are screen-size | 10:50 |
| zyga | not a saving | 10:50 |
| zyga | compared to the 3 lines that the initial version that was simplistic had | 10:50 |
| mvo | 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:50 |
| zyga | mvo: can we not do this | 10:51 |
| zyga | this will waste more time | 10:51 |
| zyga | I'll do as you suggested | 10:51 |
| mvo | 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:51 |
| mvo | zyga: i.e. just https://github.com/snapcore/snapd/pull/6150/commits/efef054dbe657b86e611405c36d593bec6f70c71#r234522318 | 10:52 |
| zyga | it was checking argc so not sure | 10:52 |
| zyga | https://github.com/snapcore/snapd/pull/6150/commits/efef054dbe657b86e611405c36d593bec6f70c71#diff-dd2649824008f9aa9cd0f650906c71bfR44 | 10:52 |
| mvo | zyga: oh, sorry, let me look at the original again, iirc there was something that mborzecki pointed out missing | 10:53 |
| zyga | I reverted | 10:56 |
| mvo | 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:57 |
| zyga | yeah | 10:58 |
| mvo | mborzecki, pstolowski if you have a moment a second review for 6153 would be nice | 10:58 |
| zyga | that's fine, I just want to land this and iterate | 10:58 |
| mvo | zyga: yeah, I will approve, I don't feel super strong about this particular check | 10:58 |
| pstolowski | looking | 10:58 |
| zyga | 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 | 10:59 |
| mvo | zyga: yes | 11:00 |
| mvo | zyga: (I approved based on that it will fail with an incorrect option) | 11:01 |
| zyga | pushed | 11:01 |
| zyga | https://github.com/snapcore/snapd/pull/6150/commits/cccc3543069dbd35fa75aa2632d99dddda15193b | 11:01 |
| zyga | I think this capture the essence of the original review | 11:02 |
| mvo | zyga: thank you! | 11:02 |
| zyga | thank you both! :) | 11:02 |
| mvo | zyga: yeah, totally fine | 11:02 |
| pstolowski | mvo: +1, one question there | 11:08 |
| mvo | 6156 also needs a second review :) | 11:24 |
| zyga | mmm | 11:24 |
| zyga | ah, interesting! | 11:24 |
| zyga | mvo: nice idea with + | 11:25 |
| zyga | snap+ foo | 11:25 |
| zyga | snap+foo_bar | 11:25 |
| mvo | zyga: yeah, this way we keep being backward compatible | 11:26 |
| zyga | indeed | 11:26 |
| zyga | 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 |
| zyga | in case we forget and decide to package g++ ;) | 11:27 |
| mvo | zyga: good point | 11:29 |
| zyga | I think right now we only reserve what. | 11:29 |
| zyga | dot, dash, underscore and plus? | 11:29 |
| zyga | . for snap.app.foo separation | 11:29 |
| zyga | dash for ... not sure | 11:29 |
| zyga | underscore for instances and udev | 11:29 |
| zyga | and plus for desktop and instances | 11:30 |
| zyga | I guess dash is not reserved | 11:30 |
| * mvo nods | 11:36 | |
| mborzecki | opening centos spread in a bit | 11:48 |
| mborzecki | 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:49 |
| zyga | mmm | 11:52 |
| ogra | 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:52 |
| zyga | mborzecki: you mean wait -n, right? | 11:53 |
| ogra | ppisati, with core16 ... 4.4 kernel (1101 build) | 11:53 |
| zyga | mborzecki: can we just wait on the PIDs? | 11:54 |
| zyga | mborzecki just: wait "$pid1" | 11:54 |
| mborzecki | worth trying | 11:58 |
| mborzecki | i'll push self checks for rhel in a separate pr | 11:58 |
| mborzecki | or more like self check for kernel < 3.18 | 11:58 |
| ppisati | ogra: uhm, where did you get the dtb? | 11:59 |
| ppisati | ogra: btw, i just got one | 12:00 |
| zyga | tests are not happy today | 12:03 |
| zyga | apt-hooks are failing more than ususual | 12:04 |
| zyga | I'll finish one branch and look at why they fail | 12:04 |
| mborzecki | shellchecks failing on tests? https://paste.fedoraproject.org/paste/Fwd6Maa3xgGP9w3sAjZ79w/raw | 12:10 |
| zyga | uh | 12:12 |
| zyga | \n strikes again | 12:12 |
| zyga | mvo: ^ | 12:13 |
| zyga | gpio | 12:13 |
| mborzecki | https://github.com/snapcore/snapd/pull/6168 | 12:16 |
| mborzecki | hm mup is silent again :) | 12:16 |
| mborzecki | mvo: are you looking into the shellcheck or should i open a quick pr? | 12:23 |
| zyga | darn, bad keypress | 12:27 |
| mborzecki | https://github.com/snapcore/snapd/pull/6169 - shellchecks | 12:27 |
| zyga | suspended vm | 12:27 |
| ogra | 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:28 |
| ogra | ppisati, it seems to use bcm2710-rpi-3-b-plus.dtb | 12:30 |
| ogra | hmm, though cpuinfo shows a BCM2709 | 12:41 |
| zyga | mvo, mborzecki: I believe you reviewed the original https://github.com/snapcore/snapd/pull/6170/files | 12:51 |
| zyga | s/facts/features/ | 12:52 |
| === cpaelzer__ is now known as cpaelzer | ||
| zyga | pushed a small test cleanup there as well | 12:59 |
| zyga | mvo: I'll break for lunch now and then look at that apt-hooks test failure | 12:59 |
| mborzecki | off to pick up the kids | 13:01 |
| zyga | off for lunch | 13:04 |
| jdstrand_ | zyga: hey, done | 13:14 |
| zyga | Hey :-) | 13:15 |
| zyga | Thank you | 13:16 |
| mvo | zyga: ta | 13:22 |
| mvo | mborzecki: I look for the shellcheck now | 13:23 |
| mvo | mborzecki: aha, you did already, thank you | 13:24 |
| === jdstrand_ is now known as jdstrand | ||
| Son_Goku | zyga, did you make any progress on mkosi based base snap building? | 13:37 |
| pedronis | 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:38 |
| zyga | Son_Goku: it's ready, I think the branch got merged upstream | 13:41 |
| zyga | pedronis: it's done, we found a simpler solution that wasn't controversial | 13:41 |
| zyga | obviously apt hooks don't fail when I want them to | 13:41 |
| pedronis | zyga: ah, ok | 13:41 |
| zyga | I'll keep trying while working on more features | 13:42 |
| zyga | pedronis: thank you, how is the sprint going? | 13:42 |
| pedronis | good, mostly in the intro phase still | 13:42 |
| Chipaca | pedronis: do you want to review the epochs followup pr? | 13:42 |
| mvo | zyga: same for me :( I ran tests for apt hooks in qemu and its fine | 13:45 |
| pedronis | Chipaca: ah, the follow up, is it up? | 13:45 |
| pedronis | not stricly | 13:45 |
| Chipaca | pedronis: writing its description right now | 13:45 |
| zyga | mvo: yeah, I will look at changing the test to fail faster and have debugging in case it happens | 13:45 |
| mvo | 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 |
| pedronis | Chipaca: shouldn't block on me, I can skim it tough, I suppose is relatively small | 13:46 |
| mvo | zyga: I wonder if its related to a new apt | 13:46 |
| pedronis | zyga: mvo: I wrote somethin again about that command option btw | 13:46 |
| zyga | mvo: new apt in bionic? | 13:46 |
| zyga | pedronis: thank you, looking | 13:47 |
| mvo | zyga: not really that new so probably not it | 13:47 |
| mvo | pedronis: thank you | 13:47 |
| Chipaca | pedronis: it's 6172 fwiw | 13:48 |
| zyga | mvo: is there any command that would ensure that commands.db is fetched? | 13:49 |
| zyga | I don't see one in postDebug | 13:50 |
| Chipaca | linkedin says i've been at canonical for 10 years | 13:50 |
| Chipaca | :-) | 13:50 |
| Chipaca | zyga: easy one is to start snapd | 13:50 |
| zyga | mvo: would you feel OK if I add something like "snap debug ensure-commands-db" or similar? | 13:51 |
| Chipaca | zyga: it's done every startup | 13:51 |
| zyga | Chipaca: woot, congratulations! :) | 13:51 |
| Chipaca | zyga: I'd be +1 to 'snap debug xyzzy' looking for snap-debug-xyzzy in PATH | 13:51 |
| Chipaca | but also this one should be simple | 13:52 |
| zyga | Chipaca: mmmm that sounds fine but how does that help? | 13:52 |
| Chipaca | it doesn't | 13:52 |
| Chipaca | :-) | 13:52 |
| zyga | I would just like to add a debug api handler for that name | 13:52 |
| * Chipaca is being super "helpful" | 13:52 | |
| zyga | ah :-) | 13:52 |
| * zyga hugs Chipaca | 13:52 | |
| Chipaca | but | 13:52 |
| zyga | I would like to add "snap tool snap-discard-ns" | 13:52 |
| Chipaca | zyga: don't call it ensure-commands-db | 13:52 |
| Chipaca | zyga: and don't call ensure from it | 13:53 |
| zyga | k | 13:53 |
| Chipaca | zyga: call refreshCatalogs | 13:53 |
| Chipaca | zyga: otherwise you get the timer check :-) | 13:53 |
| zyga | thanks! | 13:53 |
| zyga | I'll do that | 13:53 |
| Chipaca | zyga: and you could call it refresh-catalogs :-) | 13:54 |
| zyga | yeah, sounds great | 13:54 |
| pedronis | Chipaca: +1 but one question | 13:54 |
| Chipaca | anyway, i forgot to have lunch | 13:54 |
| zyga | Chipaca: oh | 13:54 |
| * Chipaca goes to heat up leftovers | 13:54 | |
| zyga | 6 minutes | 13:54 |
| pedronis | Chipaca: which is not I think about code that was changed | 13:54 |
| roadmr | 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 |
| roadmr | mvo: do you know this by any chance? ^^ | 14:12 |
| roadmr | Wimpress: hi, are you a good person to poke on the forum re: transfers to snapcrafters? | 14:12 |
| mvo | roadmr: in a meeting right now. does the user have ssh keys attached to the account? | 14:12 |
| roadmr | mvo: probably not. I can wait until you're finished, no rush :) | 14:13 |
| Wimpress | roadmr: Probably. What do you need? | 14:13 |
| mvo | 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 |
| roadmr | 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:13 |
| Wimpress | Which Snaps out of interest? | 14:14 |
| roadmr | mvo: sure thing, let me know when done and we can see | 14:14 |
| Wimpress | I've been OOTO | 14:14 |
| roadmr | Wimpress: mr robOOTO? :P | 14:14 |
| roadmr | Wimpress: qxmledit is one of them, I'll find the other one | 14:14 |
| Wimpress | popey: Do you know anything about this? | 14:15 |
| popey | hm? | 14:15 |
| roadmr | Wimpress: ah, the other is none other than hello-snapcrafters :D | 14:16 |
| roadmr | a @snapcrafters forum team would be nice (like @reviewers) but that might be spammy to you folks :/ | 14:18 |
| popey | Not a bad idea actually | 14:21 |
| roadmr | \o/ | 14:22 |
| roadmr | popey: tangent, is ev on holiday or otherwise off this week? | 14:23 |
| popey | Yes | 14:24 |
| roadmr | oh! bummer for me, but good for him :) | 14:24 |
| roadmr | 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 |
| popey | snap-advocacy@canonical.com :) | 14:25 |
| roadmr | fantastic \o/ (sorry, guess I should have known about that) | 14:26 |
| mvo | 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 |
| roadmr | mvo: thanks for getting back to me! here's the bug as filed | 14:43 |
| roadmr | https://bugs.launchpad.net/canonical-identity-provider/+bug/1803875 | 14:43 |
| roadmr | mvo: the basic problem is that he indeed has no SSH keys: https://launchpad.net/~grayslash | 14:44 |
| roadmr | 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 |
| mvo | roadmr: yeah, that sounds good | 14:45 |
| mvo | 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:45 | |
| mvo | roadmr: try subiquity | 14:46 |
| roadmr | yay! | 14:46 |
| roadmr | thanks mvo, moved. I guess I could have done all this without troubling you :/ heh | 14:47 |
| mvo | roadmr: no worries | 14:48 |
| Chipaca | #1804006 is interesting | 14:48 |
| zyga | hooks are still underused, thank you for finding that | 14:50 |
| ijohnson | do y'all think that's a snapd bug or a snapcraft bug? | 14:50 |
| zyga | it is a snapcraft bug | 14:53 |
| zyga | snapd doesn't have this bug | 14:53 |
| zyga | snapd needs to know about hooks to introduce plugs and slots to them | 14:54 |
| zyga | once declared we properly attach all interfaces, as to apps | 14:54 |
| zyga | one could argue that the bug was to allow undeclared hooks | 14:54 |
| zyga | that feels IMO like the thing that caused the complexity to arise | 14:54 |
| ijohnson | okay, so it sounds like by design the root level `plugs` in snap.yaml is not supposed to affect hooks? | 14:54 |
| Chipaca | 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 |
| zyga | on snapcraft side the code to always declare hooks would be simple | 14:54 |
| zyga | but as the system stands today it's too late to do that | 14:55 |
| zyga | ijohnson: that's incorrect | 14:55 |
| zyga | ijohnson: top level plugs and slots affect declared hooks | 14:55 |
| stokachu | Chipaca: what? | 14:55 |
| zyga | but if you don't declare a hook in snap.yaml then there's nothing magically guessing that | 14:55 |
| zyga | we *do* run discovered but undeclared hooks | 14:56 |
| zyga | and then they don't run with any interfaces | 14:56 |
| Chipaca | stokachu: aren't you battlemidget on https://github.com/conjure-up/conjure-up/issues/1542 | 14:56 |
| stokachu | all day | 14:56 |
| ijohnson | I see what you mean that makes sense | 14:56 |
| zyga | perhaps that is a snapd bug after all but it's complex to untangle now | 14:56 |
| Chipaca | stokachu: so, yeah, that | 14:56 |
| zyga | pstolowski: do you think we should discover hooks every time we load snap.yaml? | 14:56 |
| Chipaca | stokachu: lookup api.snapcraft.io on [::1]:53: read udp [::1]:47619->[::1]:53: read: connection refused | 14:56 |
| zyga | so that we can properly add slots and plugs to hooks that are not declared | 14:56 |
| Chipaca | stokachu: that's not a snap store issue | 14:57 |
| stokachu | yep | 14:57 |
| Chipaca | k | 14:57 |
| * Chipaca goes for tea | 14:58 | |
| roadmr | Teapaca? | 14:59 |
| zyga | chai :) | 14:59 |
| roadmr | chaipaca? :) | 15:00 |
| roadmr | zyga: I'm curious about what the blob of molten plastic was in the end | 15:00 |
| zyga | roadmr: it didn't fail this time | 15:01 |
| zyga | roadmr: but I had it fail to print sometimes | 15:01 |
| zyga | the object would detach from the heatbed | 15:01 |
| roadmr | ouch | 15:01 |
| zyga | the hot end would grab a hold of it by accident | 15:01 |
| zyga | it would melt and "stick" to the extruder | 15:01 |
| pstolowski | zyga: don't we do already? see info.go - ReadInfoFromSnapFile -> addImplicitHooksFromContainer | 15:01 |
| zyga | the extruder kept oozing stuff | 15:01 |
| roadmr | sounds messy | 15:01 |
| zyga | roadmr: yes :-) | 15:02 |
| stokachu | Chipaca: we good? | 15:02 |
| zyga | pstolowski: https://bugs.launchpad.net/snapcraft/+bug/1804006 | 15:02 |
| zyga | Chipaca: btw, we do add interfaces to hooks | 15:02 |
| zyga | pstolowski: perhaps it's out of sync | 15:02 |
| zyga | pstolowski: we load yaml, attach plugs and slots to hooks | 15:02 |
| zyga | then we notice more hooks on disk | 15:03 |
| zyga | and we don't do anything else to connect the dots | 15:03 |
| Chipaca | stokachu: dunno. Bug's still closed at your end, but I don't know what the issue is about | 15:03 |
| Chipaca | 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:03 | |
| Chipaca | zyga: take the XL butterfly net | 15:04 |
| stokachu | Chipaca: then nothing for you to continue to worry about then, we good | 15:04 |
| Chipaca | stokachu: k | 15:04 |
| mborzecki | https://github.com/snapcore/snapd/pull/6173 - sanity checks for centos/rhel | 15:11 |
| mvo | zyga: the apt-hook error is a 403 from the api | 15:17 |
| pstolowski | zyga: ah, i see now, i had to read a little bit of the backlog, and look into the code. indeed. | 15:22 |
| pstolowski | seems to be the case | 15:22 |
| === on is now known as Guest70909 | ||
| ppisati | 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 | 15:54 |
| roadmr | ppisati: if you're using snapcraft 3.0, use snapcraft build --destructive-mode | 16:05 |
| ppisati | roadmr: it still tries to launch a VM | 16:08 |
| roadmr | ppisati: sounds like a bug to me, as that's the description for --destructive-mode :( | 16:08 |
| ppisati | :( | 16:08 |
| ogra | just switch back to 2.0 ;) | 16:19 |
| ppisati | roadmr: nm, i got it working | 16:19 |
| ppisati | ogra: too late :) | 16:19 |
| ppisati | *to work | 16:19 |
| Chipaca | what | 16:22 |
| Chipaca | 's going on with the apt-hooks test? | 16:23 |
| * zyga is stuck in traffic | 16:23 | |
| zyga | mvo: is that something we retry? | 16:23 |
| Chipaca | ah, store 403ing | 16:23 |
| zyga | mvo: is that something we retry? | 16:24 |
| zyga | mvo: is that something we retry? | 16:25 |
| Chipaca | 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:29 |
| mvo | zyga: haha | 16:38 |
| mvo | zyga: I don't know, I was looking and then got side-tracked | 16:39 |
| mvo | Chipaca: I suspect its a demonstration of the issue (or a funny coincidence ;) | 16:39 |
| Chipaca | mvo: yeah i was wonderingering | 16:39 |
| mvo | zyga: in any case, we need to retry but if the store is really unhappy not much we can do :/ | 16:40 |
| mvo | 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:02 |
| Chipaca | mvo: on it | 17:03 |
| Chipaca | mvo: (half an hour ago) | 17:04 |
| Chipaca | mvo: happy hockeying | 17:04 |
| zyga | back home | 17:08 |
| zyga | mvo: ack | 17:08 |
| zyga | Chipaca: re | 17:08 |
| zyga | Chipaca: so what's the state of catalog refresh issue | 17:08 |
| zyga | should I finish the debug command? I guess it doesn't hurt to have | 17:08 |
| Chipaca | zyga: sorry, what issue? i saw you talking about the debug command but not why you were looking into that | 17:10 |
| zyga | Chipaca: yes, I'm writing a debug command | 17:10 |
| zyga | I'm asking if that helps in this particular issue or if you know more about the store 403 | 17:10 |
| Chipaca | zyga: the issue here is clear | 17:11 |
| Chipaca | zyga: 'got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/names' | 17:11 |
| zyga | aha | 17:12 |
| roadmr | yes, totally the store's fault :( sorry :( I'm looking into it | 17:14 |
| === pstolowski is now known as pstolowski|afk | ||
| ahasenack | is subiquity the ubuntu core installer as well? | 17:28 |
| ahasenack | just checking if this is assigned to the right project: https://bugs.launchpad.net/subiquity/+bug/1803875 | 17:28 |
| roadmr | ahasenack: I moved that there; I believe console-conf is what handles that part of the process and a package search pointed to subiquity as the source | 17:31 |
| ahasenack | ok | 17:32 |
| ahasenack | I only know subiquity as being the server installer, that's why I asked | 17:32 |
| roadmr | indeed, it also seemed odd to me | 17:33 |
| roadmr | ahasenack: https://packages.ubuntu.com/bionic/console-conf | 17:33 |
| mikedld | Chipaca: got you message here https://forum.snapcraft.io/t/sharing-files-via-tmp/1613/23 but would still like to know of any (acceptable given my description there) alternatives... | 18:28 |
| zyga | mikedld: hey, snapd aims to coordinate application interdependencies, such as sharing files or sockets via /tmp | 18:29 |
| zyga | mikedld: this is so that it can ensure that there is no hidden dependency between one snap and another | 18:29 |
| ogra | mikedld, sadly what you want isnt there atm | 18:30 |
| zyga | mikedld: if you tell us more about the kind of use case you are after we will be able to help you better | 18:30 |
| zyga | mikedld: perhaps you just need an interface | 18:30 |
| zyga | mikedld: perhaps this is not supported by design and we just need to be clear about that | 18:30 |
| ogra | snaps can write to their private /tmp, to the users ~/snap or to /var/snap/<snapname> ... none of these is easily shareable among multiple users | 18:31 |
| ogra | zyga, an interfaces wouldnt help | 18:31 |
| ogra | *interface | 18:31 |
| ogra | the question was initially about sharig data among multiple users IIRC | 18:31 |
| ogra | *sharing | 18:32 |
| mikedld | zyga: well, what I want is to be able to tell, in two different programs (and thus two different processes) whether they are running on the same machine. given that one program connects to the other via TCP socket, what I'm doing now is passing some ID via the socket and then checking whether the same ID exists in the form of a file in /tmp | 18:32 |
| ogra | we'd need another dir like /home/snap/<snapname> where all users have access or some such | 18:32 |
| zyga | mikedld: does /etc/machine-id help? | 18:33 |
| zyga | you can ask dbus about it | 18:33 |
| ogra | do we bind that into the core snap ? | 18:33 |
| zyga | https://www.freedesktop.org/software/systemd/man/machine-id.html | 18:33 |
| ogra | (would he see the host one ?) | 18:33 |
| mikedld | on Linux (or even a specific flavor of it), maybe, but the code is cross-platform | 18:33 |
| zyga | it is the host one | 18:33 |
| ogra | ah, cool | 18:34 |
| * ogra only knows how it works on UC ... | 18:34 | |
| zyga | https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-peer | 18:34 |
| zyga | mikedld: as things stand today /tmp is private for each snap application | 18:35 |
| zyga | so two users running one snap will see the same /tmp | 18:35 |
| zyga | but one user running two snaps will "see" separate empty /tmp's | 18:35 |
| mikedld | it's not highly critical but being unable to tell if they're on the same machine will affect UX in that the program will e.g. not display a button to show file selection dialog next to (or instead of) the path input field | 18:38 |
| zyga | mikedld: is it the case that multiple separate snaps need to interoperate? | 18:38 |
| mikedld | yes, putting everything into a single snap is not a good option. and as I mentioned, one of two programs may not even be snapped if one builds it from source or whatever | 18:39 |
| zyga | if you use a different path (not /tmp) and you use an interface this could be solved (we can implement the interface) | 18:40 |
| mikedld | if it will be the same path for all the users then this would be okay if it's not /tmp | 18:40 |
| zyga | yep | 18:41 |
| mikedld | I'm even okay with being required to specify a filename mask if necessary | 18:41 |
| mikedld | so what do you need from me for this to gain traction? | 18:47 |
| zyga | Chipaca: around>? | 19:02 |
| zyga | https://www.irccloud.com/pastebin/uOgifp6z/ | 19:02 |
| zyga | I'm super slow but does this look sensible? | 19:02 |
| zyga | Chipaca: code in https://github.com/snapcore/snapd/pull/6174 | 19:05 |
| mikedld | zyga: I have no idea what's going on there but there's a typo in the new file on line 31 :) | 19:09 |
| zyga | mikedld: oh, looking | 19:09 |
| zyga | thanks, fixing :) | 19:10 |
| mikedld | it passes my review now, feel free to merge :-P | 19:13 |
| mwhudson | i am confused by filesets/organize/stage :( | 21:12 |
| zyga | mwhudson: not the only one | 21:23 |
| zyga | but I think degville is working on documenting those | 21:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!