=== chihchun_afk is now known as chihchun
zygaGood morning06:38
zygaLibc never ceases to surprise06:38
mborzeckizyga: hey06:38
mborzeckizyga: what happened?06:38
zygaI sent a small PR for a bug that was reported after recent TW update06:41
zygaapparently? libmount is libc now?06:42
zygawe end up linking to it06:42
mborzeckihm, why haven't i seen it on arch?06:45
zyganot sure06:47
zygaldd snap-confine06:47
mborzeckizyga: what's the version of glibc you have there?06:47
zygawhat do you see?06:47
zygaone sec06:47
mborzeckilib{mount,uuid,blkid} are not part of glibc package on arch06:48
zygaperhaps I'm wrong06:48
mborzeckii'm on 2.2806:48
zygaand this is via libudev?06:48
zygaI should read changelogs06:48
mborzeckizyga: nope, libudev seems to pull in libc only06:50
zygamagic :)06:50
zygachecking those changelogs06:50
mborzeckizyga: does ldd snap-confine show anything interesting?06:50
zygathat we really link to those guys06:51
zyganow how do I get changelogs on suse....06:52
mborzeckizyga: missing --as-needed?06:52
mborzeckirpm -q --changelog?06:52
zygait's odd that this broke after recent update06:53
zygathe -1 package was OK06:53
zygathen TW synced06:54
zygathen it was broken06:54
zygalinking didn't change06:54
mborzeckizyga: was that a new tw snapshot?06:56
mborzeckizyga: if you're using tumbleweed-cli you could switch to the previous one06:57
mborzeckizyga: heh there's even libpcre in the ldd output you posted :)06:57
zygabut that was not new06:58
* zyga wonders how to resolve bug like boo#1113188#c1 to a link06:58
zygasuse bugzilla?06:58
zygaunrelated but explains /run/run bug07:00
mborzeckizyga: found anything interesting?07:48
zygait's low priority, I think this is fine for now07:49
zygaI'm working on more mount bits07:49
zygaover weekend I experimented with transactional security setup07:49
zygait looks super promising07:49
zygabut to measure I would love to add some helper for checking how long stuff takes07:49
zyganeed to think about that07:49
zygahaving said that, I need to get more bits merged07:50
zygasuper simple review: https://github.com/snapcore/snapd/pull/615007:50
mvo6153 needs a second review (if somone has a bit of time)07:52
zygagood morning mvo :)07:53
mvoand good morning zyga - you looked at this already07:53
zygauh, I already did07:53
mvozyga: :)07:53
zygamvo: can you look at https://github.com/snapcore/snapd/pull/6150/files07:53
zygasamuele suggested a different option name07:53
zygaconsistency vs explicitness07:53
zygaeither  way I just want to merge it and move on, it's an internal option07:54
mvozyga: 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 much07:56
=== pstolowski|afk is now known as pstolowski
mborzeckimvo: pstolowski: morning guys08:13
mborzeckisamuele is at the sprint right?08:13
mvohey mborzecki and pstolowski !08:13
mvomborzecki: correct, he is at a sprint08:14
mborzeckimvo: does #6164 replace #6156?08:16
mvomborzecki: its build on top08:17
mvomborzecki: its just one more step to cleanup things08:17
mborzeckimvo: ok08:17
zygahey pawel08:20
mborzeckizyga: left some comments under 615008:23
mvosergiusens: 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/patches09:02
zygamborzecki, mvo: pushed better parsing09:04
mvozyga: to what PR?09:04
zygajdstrand_: hey, could you please have a look at tiny fix at https://github.com/snapcore/snapd/pull/616709:06
* zyga didn't have breakfast09:19
mvozyga: updated the review, please don't hate me :)09:22
mborzeckizyga: 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
mvomborzecki: what does it contain?09:58
mborzeckimvo: `fs.may_detach_mounts=1`, that's all09:58
mvomborzecki: 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 right09:59
mvomborzecki: if in doubt, data/ I think - with a comment in the file maybe?09:59
mborzeckimvo: no it's RHEL kernels specific09:59
Chipacamborzecki: also plz a comment line saying why it's needed09:59
mborzeckiChipaca: ack09:59
Chipacamborzecki: 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 stays10:00
mborzeckibtw. let me quickly spin rhel 8 beta to check if the option is still there, otherwise it'll fail miserably10:01
mvoChipaca: heh - and good morning!10:03
Chipacamvo: :-)10:03
mborzeckiand it's not htere10:05
zygamvo: looking10:06
zygamborzecki: in our sources IMO10:06
mborzeckizyga: right, but more like data/rhel/99-ugly-tweak.conf or packaging/fedora/99-ugly-tweak-conf?10:08
zygamborzecki: can we just have it unconditionally?10:08
zygaI mean, does it hurt?10:08
zygamvo: apt-hooks test times out10:09
zyga2018-11-19 09:51:32 Error executing google:ubuntu-18.04-64:tests/main/apt-hooks :10:09
zygalots of sleep 110:09
zygathen killed10:09
vidal72[m]arch uses Wl,--as-needed to minimize libs linking maybe suse does not10:13
mvomborzecki: 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
mborzeckimvo: i think i'm leaning towards replacing + with _ in he original name and leaving them unchanged otherwise10:18
mvomborzecki: sounds good, will update the PR10:19
vidal72[m]I just found that snaps are unusable when someone uses aa-notify :(10:39
mborzeckividal72[m]: isn't that an issue with audit[d] not being set up on the machine?10:40
mvovidal72[m]: do you get too many denials? or why unusalble?10:40
vidal72[m]yes, too many denials10:40
mborzeckividal72[m]: which snap is causing this?10:41
vidal72[m]I tested it with chromium but I think it's similar with all profiles10:42
vidal72[m]snap profiles would have to 'deny' everything not alowed10:43
vidal72[m]when I open files dialog I have denials for every dotfile10:43
zygamvo, 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
zygasimple and maintainlable, even if longer)10:46
zygaI would rather do the regular parser like in snap-confine, with tests, than a not-fully-baked one you both proposed10:46
zygamvo: please pick the direction, I will do as you wish10:46
zygamvo: I also said in the PR that with a fully baked parser we could share some code with snap-confine as well10:47
zygathough that is not a priority now10:48
mvozyga: I think as short as possible unless we need more, everything else feels like yagni. once we need more we can do a full solution10:48
mvozyga: in the "medium" one, what is too much? cut it down as much as needed and I think its fine10:48
zygait's almost the same length as what is in the PR now10:49
zygaand I'd argue that the longer code is easier to understand and extend10:49
mvozyga: is it? i counted ~40 lines vs 15 or so, did I misread?10:49
zygaboth are screen-size10:50
zyganot a saving10:50
zygacompared to the 3 lines that the initial version that was simplistic had10:50
mvozyga: 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 decides10:50
zygamvo: can we not do this10:51
zygathis will waste more time10:51
zygaI'll do as you suggested10:51
mvozyga: 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
mvozyga: i.e. just https://github.com/snapcore/snapd/pull/6150/commits/efef054dbe657b86e611405c36d593bec6f70c71#r23452231810:52
zygait was checking argc so not sure10:52
mvozyga: oh, sorry, let me look at the original again, iirc there was something that mborzecki  pointed out missing10:53
zygaI reverted10:56
mvozyga: 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
mvomborzecki, pstolowski if you have a moment a second review for 6153 would be nice10:58
zygathat's fine, I just want to land this and iterate10:58
mvozyga: yeah, I will approve, I don't feel super strong about this particular check10:58
zygaI 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 fail10:59
mvozyga: yes11:00
mvozyga: (I approved based on that it will fail with an incorrect option)11:01
zygaI think this capture the essence of the original review11:02
mvozyga: thank you!11:02
zygathank you both! :)11:02
mvozyga: yeah, totally fine11:02
pstolowskimvo: +1, one question there11:08
mvo6156 also needs a second review :)11:24
zygaah, interesting!11:24
zygamvo: nice idea with +11:25
zygasnap+ foo11:25
mvozyga: yeah, this way we keep being backward compatible11:26
zygaI didn't read the diff but we should note that + is a reserved character for this purpose next to snap validation functions11:27
zygain case we forget and decide to package g++ ;)11:27
mvozyga: good point11:29
zygaI think right now we only reserve what.11:29
zygadot, dash, underscore and plus?11:29
zyga. for snap.app.foo separation11:29
zygadash for ... not sure11:29
zygaunderscore for instances and udev11:29
zygaand plus for desktop and instances11:30
zygaI guess dash is not reserved11:30
* mvo nods11:36
mborzeckiopening centos spread in a bit11:48
mborzeckione 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 there11:49
ograppisati, 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
zygamborzecki: you mean wait -n, right?11:53
ograppisati, with core16 ... 4.4 kernel (1101 build)11:53
zygamborzecki: can we just wait on the PIDs?11:54
zyga mborzecki just: wait "$pid1"11:54
mborzeckiworth trying11:58
mborzeckii'll push self checks for rhel in a separate pr11:58
mborzeckior more like self check for kernel < 3.1811:58
ppisatiogra: uhm, where did you get the dtb?11:59
ppisatiogra: btw, i just got one12:00
zygatests are not happy today12:03
zygaapt-hooks are failing more than ususual12:04
zygaI'll finish one branch and look at why they fail12:04
mborzeckishellchecks failing on tests? https://paste.fedoraproject.org/paste/Fwd6Maa3xgGP9w3sAjZ79w/raw12:10
zyga\n strikes again12:12
zygamvo: ^12:13
mborzeckihm mup is silent again :)12:16
mborzeckimvo: are you looking into the shellcheck or should i open a quick pr?12:23
zygadarn, bad keypress12:27
mborzeckihttps://github.com/snapcore/snapd/pull/6169 - shellchecks12:27
zygasuspended vm12:27
ograppisati, 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
ograppisati, it seems to use bcm2710-rpi-3-b-plus.dtb12:30
ograhmm, though cpuinfo shows a BCM270912:41
zygamvo, mborzecki: I believe you reviewed the original https://github.com/snapcore/snapd/pull/6170/files12:51
=== cpaelzer__ is now known as cpaelzer
zygapushed a small test cleanup there as well12:59
zygamvo: I'll break for lunch now and then look at that apt-hooks test failure12:59
mborzeckioff to pick up the kids13:01
zygaoff for lunch13:04
jdstrand_zyga: hey, done13:14
zygaHey :-)13:15
zygaThank you13:16
mvozyga: ta13:22
mvomborzecki: I look for the shellcheck now13:23
mvomborzecki: aha, you did already, thank you13:24
=== jdstrand_ is now known as jdstrand
Son_Gokuzyga, did you make any progress on mkosi based base snap building?13:37
pedronismvo: 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 deep13:38
zygaSon_Goku: it's ready, I think the branch got merged upstream13:41
zygapedronis: it's done, we found a simpler solution that wasn't controversial13:41
zygaobviously apt hooks don't fail when I want them to13:41
pedroniszyga: ah, ok13:41
zygaI'll keep trying while working on more features13:42
zygapedronis: thank you, how is the sprint going?13:42
pedronisgood, mostly in the intro phase still13:42
Chipacapedronis: do you want to review the epochs followup pr?13:42
mvozyga: same for me :( I ran tests for apt hooks in qemu and its fine13:45
pedronisChipaca: ah, the follow up, is it up?13:45
pedronisnot stricly13:45
Chipacapedronis: writing its description right now13:45
zygamvo: yeah, I will look at changing the test to fail faster and have debugging in case it happens13:45
mvohey, 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/patches13:46
pedronisChipaca: shouldn't block on me, I can skim it tough, I suppose is relatively small13:46
mvozyga: I wonder if its related to a new apt13:46
pedroniszyga: mvo: I wrote somethin again about that command option btw13:46
zygamvo: new apt in bionic?13:46
zygapedronis: thank you, looking13:47
mvozyga: not really that new so probably not it13:47
mvopedronis: thank you13:47
Chipacapedronis: it's 6172 fwiw13:48
zygamvo: is there any command that would ensure that commands.db is fetched?13:49
zygaI don't see one in postDebug13:50
Chipacalinkedin says i've been at canonical for 10 years13:50
Chipacazyga: easy one is to start snapd13:50
zygamvo: would you feel OK if I add something like "snap debug ensure-commands-db" or similar?13:51
Chipacazyga: it's done every startup13:51
zygaChipaca: woot, congratulations! :)13:51
Chipacazyga: I'd be +1 to 'snap debug xyzzy' looking for snap-debug-xyzzy in PATH13:51
Chipacabut also this one should be simple13:52
zygaChipaca: mmmm that sounds fine but how does that help?13:52
Chipacait doesn't13:52
zygaI would just like to add a debug api handler for that name13:52
* Chipaca is being super "helpful"13:52
zygaah :-)13:52
* zyga hugs Chipaca 13:52
zygaI would like to add "snap tool snap-discard-ns"13:52
Chipacazyga: don't call it ensure-commands-db13:52
Chipacazyga: and don't call ensure from it13:53
Chipacazyga: call refreshCatalogs13:53
Chipacazyga: otherwise you get the timer check :-)13:53
zygaI'll do that13:53
Chipacazyga: and you could call it refresh-catalogs :-)13:54
zygayeah, sounds great13:54
pedronisChipaca: +1 but one question13:54
Chipacaanyway, i forgot to have lunch13:54
zygaChipaca: oh13:54
* Chipaca goes to heat up leftovers13:54
zyga6 minutes13:54
pedronisChipaca: which is not I think about code that was changed13:54
roadmrhey 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
roadmrmvo: do you know this by any chance? ^^14:12
roadmrWimpress: hi, are you a good person to poke on the forum re: transfers to snapcrafters?14:12
mvoroadmr: in a meeting right now. does the user have ssh keys attached to the account?14:12
roadmrmvo: probably not. I can wait until you're finished, no rush :)14:13
Wimpressroadmr: Probably. What do you need?14:13
mvoroadmr: 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
roadmrWimpress: 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 threads14:13
WimpressWhich Snaps out of interest?14:14
roadmrmvo: sure thing, let me know when done and we can see14:14
WimpressI've been OOTO14:14
roadmrWimpress: mr robOOTO? :P14:14
roadmrWimpress: qxmledit is one of them, I'll find the other one14:14
Wimpresspopey: Do you know anything about this?14:15
roadmrWimpress: ah, the other is none other than hello-snapcrafters :D14:16
roadmra @snapcrafters forum team would be nice (like @reviewers) but that might be spammy to you folks :/14:18
popeyNot a bad idea actually14:21
roadmrpopey: tangent, is ev on holiday or otherwise off this week?14:23
roadmroh! bummer for me, but good for him :)14:24
roadmrpopey: 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
popeysnap-advocacy@canonical.com :)14:25
roadmrfantastic \o/ (sorry, guess I should have known about that)14:26
mvoroadmr: 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
roadmrmvo: thanks for getting back to me! here's the bug as filed14:43
roadmrmvo: the basic problem is that he indeed has no SSH keys: https://launchpad.net/~grayslash14:44
roadmrmvo: 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
mvoroadmr: yeah, that sounds good14:45
mvoroadmr: console-conf sounds like a good choice for the bug14:45
* roadmr now tries to find the LP project for console-conf :D14:45
mvoroadmr: try subiquity14:46
roadmrthanks mvo, moved. I guess I could have done all this without troubling you :/ heh14:47
mvoroadmr: no worries14:48
Chipaca#1804006 is interesting14:48
zygahooks are still underused, thank you for finding that14:50
ijohnsondo y'all think that's a snapd bug or a snapcraft bug?14:50
zygait is a snapcraft bug14:53
zygasnapd doesn't have this bug14:53
zygasnapd needs to know about hooks to introduce plugs and slots to them14:54
zygaonce declared we properly attach all interfaces, as to apps14:54
zygaone could argue that the bug was to allow undeclared hooks14:54
zygathat feels IMO like the thing that caused the complexity to arise14:54
ijohnsonokay, so it sounds like by design the root level `plugs` in snap.yaml is not supposed to affect hooks?14:54
Chipacastokachu: 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 over14:54
zygaon snapcraft side the code to always declare hooks would be simple14:54
zygabut as the system stands today it's too late to do that14:55
zygaijohnson: that's incorrect14:55
zygaijohnson: top level plugs and slots affect declared hooks14:55
stokachuChipaca: what?14:55
zygabut if you don't declare a hook in snap.yaml then there's nothing magically guessing that14:55
zygawe *do* run discovered but undeclared hooks14:56
zygaand then they don't run with any interfaces14:56
Chipacastokachu: aren't you battlemidget on https://github.com/conjure-up/conjure-up/issues/154214:56
stokachuall day14:56
ijohnsonI see what you mean that makes sense14:56
zygaperhaps that is a snapd bug after all but it's complex to untangle now14:56
Chipacastokachu: so, yeah, that14:56
zygapstolowski: do you think we should discover hooks every time we load snap.yaml?14:56
Chipacastokachu: lookup api.snapcraft.io on [::1]:53: read udp [::1]:47619->[::1]:53: read: connection refused14:56
zygaso that we can properly add slots and plugs to hooks that are not declared14:56
Chipacastokachu: that's not a snap store issue14:57
* Chipaca goes for tea14:58
zygachai :)14:59
roadmrchaipaca? :)15:00
roadmrzyga: I'm curious about what the blob of molten plastic was in the end15:00
zygaroadmr: it didn't fail this time15:01
zygaroadmr: but I had it fail to print sometimes15:01
zygathe object would detach from the heatbed15:01
zygathe hot end would grab a hold of it by accident15:01
zygait would melt and "stick" to the extruder15:01
pstolowskizyga: don't we do already? see info.go - ReadInfoFromSnapFile -> addImplicitHooksFromContainer15:01
zygathe extruder kept oozing stuff15:01
roadmrsounds messy15:01
zygaroadmr: yes :-)15:02
stokachuChipaca: we good?15:02
zygapstolowski: https://bugs.launchpad.net/snapcraft/+bug/180400615:02
zygaChipaca: btw, we do add interfaces to hooks15:02
zygapstolowski: perhaps it's out of sync15:02
zygapstolowski: we load yaml, attach plugs and slots to hooks15:02
zygathen we notice more hooks on disk15:03
zygaand we don't do anything else to connect the dots15:03
Chipacastokachu: dunno. Bug's still closed at your end, but I don't know what the issue is about15:03
Chipacastokachu: just know it's not in the realm of things that we can help with15:03
* zyga needs to catch a bus now15:03
Chipacazyga: take the XL butterfly net15:04
stokachuChipaca: then nothing for you to continue to worry about then, we good15:04
Chipacastokachu: k15:04
mborzeckihttps://github.com/snapcore/snapd/pull/6173 - sanity checks for centos/rhel15:11
mvozyga: the apt-hook error is a 403 from the api15:17
pstolowskizyga: ah, i see now, i had to read a little bit of the backlog, and look into the code. indeed.15:22
pstolowskiseems to be the case15:22
=== on is now known as Guest70909
ppisatisergiusens: 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 FWIW15:54
roadmrppisati: if you're using snapcraft 3.0, use snapcraft build --destructive-mode16:05
ppisatiroadmr: it still tries to launch a VM16:08
roadmrppisati: sounds like a bug to me, as that's the description for --destructive-mode :(16:08
ograjust switch back to 2.0 ;)16:19
ppisatiroadmr: nm, i got it working16:19
ppisatiogra: too late :)16:19
ppisati*to work16:19
Chipaca's going on with the apt-hooks test?16:23
* zyga is stuck in traffic16:23
zygamvo: is that something we retry?16:23
Chipacaah, store 403ing16:23
zygamvo: is that something we retry?16:24
zygamvo: is that something we retry?16:25
Chipacazyga: 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
mvozyga: haha16:38
mvozyga: I don't know, I was looking and then got side-tracked16:39
mvoChipaca: I suspect its a demonstration of the issue (or a funny coincidence ;)16:39
Chipacamvo: yeah i was wonderingering16:39
mvozyga: in any case, we need to retry but if the store is really unhappy not much we can do :/16:40
mvoChipaca, 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
Chipacamvo: on it17:03
Chipacamvo: (half an hour ago)17:04
Chipacamvo: happy hockeying17:04
zygaback home17:08
zygamvo: ack17:08
zygaChipaca: re17:08
zygaChipaca: so what's the state of catalog refresh issue17:08
zygashould I finish the debug command? I guess it doesn't hurt to have17:08
Chipacazyga: sorry, what issue? i saw you talking about the debug command but not why you were looking into that17:10
zygaChipaca: yes, I'm writing a debug command17:10
zygaI'm asking if that helps in this particular issue or if you know more about the store 40317:10
Chipacazyga: the issue here is clear17:11
Chipacazyga: 'got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/names'17:11
roadmryes, totally the store's fault :( sorry :( I'm looking into it17:14
=== pstolowski is now known as pstolowski|afk
ahasenackis subiquity the ubuntu core installer as well?17:28
ahasenackjust checking if this is assigned to the right project: https://bugs.launchpad.net/subiquity/+bug/180387517:28
roadmrahasenack: 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 source17:31
ahasenackI only know subiquity as being the server installer, that's why I asked17:32
roadmrindeed, it also seemed odd to me17:33
roadmrahasenack: https://packages.ubuntu.com/bionic/console-conf17:33
mikedldChipaca: 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
zygamikedld: hey, snapd aims to coordinate application interdependencies, such as sharing files or sockets via /tmp18:29
zygamikedld: this is so that it can ensure that there is no hidden dependency between one snap and another18:29
ogramikedld, sadly what you want isnt there atm18:30
zygamikedld: if you tell us more about the kind of use case you are after we will be able to help you better18:30
zygamikedld: perhaps you just need an interface18:30
zygamikedld: perhaps this is not supported by design and we just need to be clear about that18:30
ograsnaps can write to their private /tmp, to the users ~/snap or to /var/snap/<snapname> ... none of these is easily shareable among multiple users18:31
ograzyga, an interfaces wouldnt help18:31
ograthe question was initially about sharig data among multiple users IIRC18:31
mikedldzyga: 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 /tmp18:32
ograwe'd need another dir like /home/snap/<snapname> where all users have access or some such18:32
zygamikedld: does /etc/machine-id help?18:33
zygayou can ask dbus about it18:33
ogrado we bind that into the core snap ?18:33
ogra(would he see the host one ?)18:33
mikedldon Linux (or even a specific flavor of it), maybe, but the code is cross-platform18:33
zygait is the host one18:33
ograah, cool18:34
* ogra only knows how it works on UC ... 18:34
zygamikedld: as things stand today /tmp is private for each snap application18:35
zygaso two users running one snap will see the same /tmp18:35
zygabut one user running two snaps will "see" separate empty /tmp's18:35
mikedldit'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 field18:38
zygamikedld: is it the case that multiple separate snaps need to interoperate?18:38
mikedldyes, 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 whatever18:39
zygaif you use a different path (not /tmp) and you use an interface this could be solved (we can implement the interface)18:40
mikedldif it will be the same path for all the users then this would be okay if it's not /tmp18:40
mikedldI'm even okay with being required to specify a filename mask if necessary18:41
mikedldso what do you need from me for this to gain traction?18:47
zygaChipaca: around>?19:02
zygaI'm super slow but does this look sensible?19:02
zygaChipaca: code in https://github.com/snapcore/snapd/pull/617419:05
mikedldzyga: I have no idea what's going on there but there's a typo in the new file on line 31 :)19:09
zygamikedld: oh, looking19:09
zygathanks, fixing :)19:10
mikedldit passes my review now, feel free to merge :-P19:13
mwhudsoni am confused by filesets/organize/stage :(21:12
zygamwhudson: not the only one21:23
zygabut I think degville is working on documenting those21:23

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