/srv/irclogs.ubuntu.com/2019/05/01/#snappy.txt

=== chihchun_afk is now known as chihchun
mupPR snapd#6731 closed: overlord: make the store context composably backed by separate backends for device asserts/info etc <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6731>06:09
=== BlueT_ is now known as BlueT
pedronisthere are also problems with the centos repos: https://api.travis-ci.org/v3/job/526762904/log.txt08:35
mupPR snapd#6807 opened: tests:  reduce snapcraft leftovers from PROJECT_PATH,  temp disable centos <Created by pedronis> <https://github.com/snapcore/snapd/pull/6807>08:47
pedronisChipaca: hi, could you look at ^08:51
Chipacayes08:54
ChipacaI should make a PR with just the cleanups from the invariant pr, until i can get the pr to pass fully08:56
Chipacapedronis_: why the convoluted logic of '! command -v snapcraft >/dev/null || snapcraft clean'?08:56
Chipacapedronis_: I suspect you didn't mean to write that :-| but if you did i'd like to understand why08:57
pedronisChipaca: #6803 looks reasonable, some lateral comments09:19
mupPR #6803: daemon, o/snapstate, store: support for installing from cohorts <Created by chipaca> <https://github.com/snapcore/snapd/pull/6803>09:19
Chipacawoo09:19
Chipacapedronis: thanks09:20
mupPR snapd#6807 closed: tests:  reduce snapcraft leftovers from PROJECT_PATH,  temp disable centos <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6807>10:05
pedronisChipaca: #6447 also needs/can be reviewed, a bit big10:20
mupPR #6447: polkit: cast pid to uint32 to keep polkit happy for now <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6447>10:20
Chipacathat's merged tho10:20
Chipaca#6747 ?10:21
mupPR #6747: many:  make access to the device model assertion etc contextual via a DeviceCtx hook/DeviceContext interface <Created by pedronis> <https://github.com/snapcore/snapd/pull/6747>10:21
pedronisyes, sorry10:21
Chipacapedronis: bit of a cow to review, but, done! and, nice. thank you.11:01
pedronisChipaca: thank you11:02
Chipacapedronis: none of those nits are worth another spread run on their own, fwiw11:02
Chipacaif you happen to do one, fine; otherwise i am content11:03
pedronisChipaca: let's see how it goes, anyway there's already an immediate follow up by mvo11:03
pedronisthat needs tweaks11:03
pedronisso it could go there11:03
pedronisChipaca: we should try to land #680611:04
mupPR #6806: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6806>11:04
Chipacai was wondering if that was the best approach11:05
Chipacaprobably fine for now tho11:05
Chipacabut i'd rather ship static binaries than the whole of libc11:06
Chipacajust for those two binaries i mean11:06
pedronisChipaca: I see, reasonable but is a larger change11:06
pedronisatm snapd snap was breaking hard a bunch of spread tests11:06
pedronismvo had to revert it in edge11:07
pedronisalso a bit weird why the tests were using the snapd from edge11:07
pedronisand not something built then11:07
mupPR snapd#6806 closed: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6806>11:11
pedronisChipaca: is your thinking to have again a single Install later taking a struct?11:15
Chipacapedronis: yes11:15
pedronisbut is a big refactor11:15
Chipacaexactly11:15
Chipacadidn't want to do it as part of cohort work11:15
Chipacabut it clearly needs to move to be that way11:15
pedronisChipaca: in that case either name is fine for the new helper11:15
pedroniss/helper/taskset producing function/11:15
Chipacain fact i'd expect InstallPath to also get absorbed into the new thing11:16
Chipacaat which point Try is probably on the chopping board too :-)11:16
Chipacawe'll see (installpath does a bunch of stuff that needs dissecting at this point)11:16
pedronisnot sure it will be worth trying to merge back Path or Try11:17
pedronisit might make things less readable actually11:17
pedronisChipaca: anyway I think it would be good to add some // TODO: merge back with Install taking a struct11:18
pedronisexplicitly though11:18
Chipacadidn't i?11:18
* Chipaca thought he had11:18
* Chipaca checks11:18
Chipaca/ TODO: refactor things so there's a single install that takes a struct, mayeb a bit more like doInstall but public-er.11:18
pedronisyou did11:18
pedronisbut maybe s/install/Install/ there11:18
pedronisactually s/install/Install again/11:19
pedronisI read that commented and thought it meant that but wasn't super clear11:19
Chipacaok11:19
pedroniss/commented/comment/11:19
Chipacapedronis: wrt leave-cohort, should I declare a special cohort that means 'leave' internally, or should i have a flag for it?11:20
Chipacaon the fence on that11:20
pedronisit will not be store in SnapState to be celar11:21
pedronisit will remove what is there11:21
pedroniss/celar/clear/ ...11:21
Chipacayes, it'd be in SnapSetup but not in SnapState11:21
Chipacain the client action structs, from there to snapInstruction, from there to SnapSetup11:22
pedronisChipaca: I fear on the API side a different flag seems better11:24
pedronisChipaca: unless we  go dinstihishgin  no cohort-key  vs cohort-key: null vs cohort-key: string11:25
pedronis(which is doable but a bit annoying in go911:25
Chipacaew11:25
Chipacaleave-cohort: true seems weird tho :-)11:26
pedroniscohort-key: "<leave>" is also weird11:26
Chipacayes, yes it is11:26
Chipacaerror: you can't leave a cohort, it's for life11:26
Chipaca\o/11:27
pedronisChipaca: 6747 is green, so I'm going to merge it, and take care of you remark at the start of tweaking the follow up11:27
pedronis*remarks11:28
Chipacapedronis: np11:28
Chipacapedronis: did you see what i meant about cohort-key + revision being ok in context?11:28
Chipacaas opposed to in action11:29
pedronisyes11:31
Chipacak11:31
mupPR snapd#6747 closed: many:  make access to the device model assertion etc contextual via a DeviceCtx hook/DeviceContext interface <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6747>11:32
Chipacagrmbl out-of-space errors12:16
* Chipaca lunch quick before standup12:32
pedronisChipaca: where, I thought I fixed some of those12:34
Chipacapedronis: in cross-compiling12:44
Chipacapedronis: merged master in case it was in that delta12:44
pedronisChipaca: I landed a fix for that, or so I hope12:44
pedronisthis morning12:44
mupPR snapd#6808 opened: overlord: pass a DeviceContext to the CheckSnap implementations <Created by pedronis> <https://github.com/snapcore/snapd/pull/6808>12:48
pedronisChipaca: ^  it's small, follow up  to previous and adding deviceCtx arg to checkSnap, otoh the test changes maybe are too noisy, don't know12:49
Chipacapedronis: looks like a lot of the 'noise' is to pass an argument that isn't used?12:50
pedronisChipaca: it will be used, but I can simply merge this in the next one12:51
Chipacaah because. got it.12:51
pedronisthat one will be big(tm) though12:51
pedronisif you prefer12:52
ChipacaCheckSnapCallback12:52
pedronisyes12:52
pedronisbut it would make mvo and my self harder12:52
Chipacanah it's fine12:52
Chipacaalso, TMI12:52
pedronisbecause we are both working in different areas at intersection of this12:52
pedronisoops12:52
pedronismissing a life there12:52
Chipaca:-)12:53
Chipaca+1, looks good12:53
pedronisChipaca: standup?13:01
Chipacayep13:02
pedronisChipaca: seems bundling the libc in snapd didn't quite work, we get segfaults now, fun13:21
Chipacapedronis: segfaults are libc's way of telling you it loves you13:21
Chipacaor was it that it hated you and wanted you dead13:22
Chipacaone of those13:22
tooijarIf I run `snapcraft init` in folder B, then `snapcraft` in folder A no longer looks at folder A/snap. It builds from folder B.  I was expecting the snapcraft command to look for `snap/` in the current directory.13:37
tooijarIs this expected?13:37
pedronisChipaca: I reverted snapd edge for now13:41
pedronisand pinged mvo13:41
Chipacatooijar: wat13:43
Chipacapedronis: ack13:43
Chipacatooijar: what does running 'snapcraft init' in folder B have to do with running 'snapcraft' in folder A?13:45
tooijarChipaca: That's what I'm wondering. When I run snapcraft in folder A, it builds from the snapcraft.yaml in folder B (!)13:54
Chipacatooijar: are these two projects using base: <something>, and are they called the same?13:56
tooijarChipaca they're both using base: core1813:58
brlintooijar: Are you running these commands in a snap build environment?  Snapcraft handles directories quite differently in a build environment13:59
tooijarTheir name fields are different.13:59
tooijarI'm running in Ubuntu 180413:59
tooijarMaybe cleanbuild will fix it?14:01
Chipacatooijar: could you pastebin the console output of running snapcraft in both directories?14:03
Chipacatooijar: it would be very interesting to get a way to reproduce this14:05
Chipacatooijar: if you are able to get those steps, file it in a bug please14:05
tooijarhttps://pastebin.com/LpMdFWsf14:08
tooijarThe output is identical in both directories. Problem is the ./snap/snapcraft.yaml in directory A is not 'my-snap-name'14:09
tooijarfixed with snapcraft clean && snapcraft build14:25
diddledantooijar: sounds like your "folder A" and "folder B" are named the same but in different locations?14:27
diddledanif so it is expected that you'll get into a confused mess because the VM name is set to the folder name14:28
tooijardiddledan: they're both different folders in my home directory14:30
tooijarOf course the snapcraft.yaml is in a directory named "snap" in both folders.  And they're both set to use base: core1814:31
Chipacatooijar: how do we reproduce the issue?14:33
Chipacai've run multiple snapcrafts simultaneously before now and things work fine, so i'm puzzled14:34
Chipacatooijar: is one a subdirectory of the other?14:34
tooijarChipaca: I've corrected it now with snapcraft clean14:34
tooijarno, they're both in ~14:34
tooijarSo ~/A and ~/B14:35
Chipacatooijar: did you copy one to the other?14:35
tooijarno14:35
tooijarI'll try to reproduce14:35
Chipacatooijar: ie did you 'snapcraft' and then copy the snap/ directory14:35
tooijarChipaca: no, but there are no hidden files in the snap folder. Why would copying break things?14:36
Chipacaah, that's right, the state is kept in the vm14:40
* Chipaca hates spread14:48
Chipacaonly worse thing than spread is everything else that tries to do the same thing it tries to do14:48
tooijarChipaca: Since running snapcraft clean I can't reproduce anymore.14:55
alan_gjdstrand, could you clarify your seccomp denial question here? https://github.com/snapcore/snapd/pull/6790#discussion_r279408775 (I just need it explained to an idiot).15:03
mupPR #6790: interfaces: add login-session-control interface <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/6790>15:03
jdstrandalan_g: yes, I plan to go through that again today15:04
mupPR snapcraft#2547 opened: [legacy] catkin spread test: allow python2 as well as python <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2547>15:04
alan_gjdstrand, thanks. I don't know if this should be related, but you were mentioned: https://forum.snapcraft.io/t/installing-a-desktop-file-in-usr-share-wayland-sessions/1117315:05
jdstrandthat's another on my todo for today15:08
alan_g\o/15:08
mupPR snapd#6699 closed: daemon: add RootOnly flag to commands <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6699>15:27
tooijarHow can I install a library into a prime/ directory for faster testing?  I don't want to add to stage-packages and re-run snapcraft over and over until the last unmet dependencies is added.15:34
brlinSimply copy them into it and run `snapcraft pack prime`15:40
kyrofatooijar, actually, modifying stage-packages and re-running is a good way to do it, but you may need to restructure your project ever so slightly. Does your snapcraft.yaml specify a `base`?15:43
tooijarkyrofa: yes, base is core1815:44
tooijarReason I don't want to re-run is ...it just takes a long time.15:44
kyrofatooijar, I assume you have a part that takes a while to build, and you're adding the stage-packages to that part? Modifying the list means it needs to rebuild, yada yada15:44
kyrofatooijar, correct so far?15:45
tooijarkyrofa: source-type is local so it's not building as in compiling / linking....but it does take a long time at "snapping test-snap". I'm not sure what it's doing that's taking so long.15:46
kyrofatooijar, that's creating the squashfs image out of the priming area. If you're creating a snap you'll always pay that cost regardless of how you choose to get the lib into the priming area15:48
tooijarkyrofa: yeah, 'snapcraft pack prime' doesn't speed things up much15:49
tooijarI guess I should find a better way of identifying all dependencies rather than just building / running and waiting to see what shared library error is thrown.15:50
kyrofatooijar, are you using multipass, then?15:53
tooijarkyrofa: Not specifically by choice, but yes, I believe snapcraft is using multipass on my Ubuntu1804 machine.15:54
kyrofatooijar, how are you accessing the prime directory?15:54
tooijarI had done `snapcraft try prime` and it put prime/ in my current directory15:55
tooijarThen I just cd'd into it15:55
kyrofaAh! I didn't realize sergiusens had implemented that yet, very nice15:55
kyrofatooijar, so then, here's what you need to do15:55
kyrofaStop messing about with the prime directory, and stop running `snapcraft` with no args. Basically, stop creating a snap15:56
kyrofaAlter the stage-packages as necessary, and run `snapcraft prime` only15:56
kyrofaThat will do everything EXCEPT create a snap15:56
kyrofaSince you have `snapcraft try` already, all you need to do at that point is try running the app again15:56
kyrofaThe libs will be in prime15:56
pedronisChipaca: we have never used the internal package mechanism right, how do you feel about it?16:03
tooijarkyrofa: that works, but because stage-packages has changed, it does a build, then stage, then prime when I run `snapcraft prime` so it's not much faster than just running snapcraft.  What I was hoping what that it could load the new libraries into the existing image, and be done. Without then having to build/stage/prime.16:12
tooijarI just want to do the equivalent of `sudo apt install missing-lib` in the already built prime folder16:14
tooijarMaybe I just need a better build machine.16:16
diddledandang, I missed the dockercon keynote16:21
* diddledan makes a note to watch that later16:21
brlintooijar: You can put the `stage-packages` entries under another fake part, in this case changing them won't clean the entire part's progress16:22
diddledanhmm, come on travis-ci!!16:23
* diddledan pokenprod mit deine pokiestick16:23
tooijarbrlin: that sounds promising, thanks.16:25
diddledanI'd recommend merging that fake part back into the part you're not wanting to rebuild once you have the right packages sorted so that it's obvious which part they really belong to :-)16:26
diddledanbut while you're working out what you need brlin 's idea is solid to prevent long waits16:27
tooijarok, thanks for the help folks.16:28
mupPR snapd#6808 closed: overlord: pass a DeviceContext to the checkSnap implementations <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6808>17:09
Chipacapedronis: I wish we had used internal17:14
Chipacapedronis: I'd like to transition to it yesterday17:14
Chipacapedronis: failing that, tomorrow is ok17:14
Chipacapedronis: further I think some things are internal-internal, but dunno if go supports that or even if it's a good idea17:15
pedronisChipaca: ok, I have I use in current refactoring, actually a slightly strange use but seems to work17:15
Chipacapedronis: e.g. some things in *util only meant to be used from overlord17:15
Chipacapedronis: >shocked pikachu<17:16
Chipacapedronis: if it's "use internal because it has a side effect that the compiler does things in reverse order so things no longer segfault" then i'm against it17:17
Chipacapedronis: :-)17:17
Chipacabut also ha-ha-but-seriously17:18
pedronisChipaca: no, is to have something that is exposed to tests via a *test package but otherwise not accesible except in its home package17:18
pedronisthe only other solution I could think of would need repeating the impl twice17:18
Chipacapedronis: what do we say to the god of repeating ourselves?17:20
* Chipaca came back from the gym more memetic than usual17:22
tooijarCan someone clarify why "allow-sandbox" is defaulted to "false"?  "The allow-sandbox attribute may be used to give the necessary access to use the browser’s sandbox functionality."17:26
tooijarGiven that the browser sandbox is a security measure, shouldn't it default to true?17:27
Chipacatooijar: AIUI, it's because it weakens the snap's security, in exchange for trusting the browser to enforce it17:32
Chipacatooijar: jdstrand might be able to explain more, but that's my understanding17:32
Chipacatooijar: also see https://forum.snapcraft.io/t/sandboxing-with-the-browser-support-interface/1984/217:33
Chipacadegville: jdstrand: what happened to the "Note:" in that ^ topic, that is no longer in https://docs.snapcraft.io/the-browser-support-interface/7775 ?17:34
tooijarChipaca: Thanks for the link....this explains it well enough to satisfy my curiosity: "Since the browser’s internal sandbox requires a lot of privileged security policy rules to work, use of --allow-sandbox=true is limited to trusted publishers"17:37
Chipacatooijar: in other words, it needs manual review17:37
tooijarChipaca: Would be good to have that same explanation on the main docs here https://docs.snapcraft.io/the-browser-support-interface/777517:38
Chipacatooijar: the funny thing is that that is a quote from the docs, hence my question to jdstrand & degville17:38
Chipacawe've lost something in a cleanup somewhere17:38
degville(looking)17:38
Chipacaas they stand the docs don't say that allow-sandbox:true is privileged17:39
Chipacaanyway, i need to go to the shops before they close17:39
Chipacattfn, ttyl17:39
degvilleChipaca:see you! I'll look into the docs.17:40
jdstrandChipaca: that note never made it to https://forum.snapcraft.io/t/the-browser-support-interface/7775. I'll let degville decide how to incorporate it17:44
jdstranddegville: if you do, feel free to drop the reference to oxide17:44
degvillejdstrand: thanks - not sure what happened, but I'll re-instate it now and drop the oxide reference.17:45
jdstrandtooijar: Chipaca is right. the snap sandbox and the browser sandbox have different ideas about things. outside of snapd, the browser is considered trusted and may even have a setuid binary to setup its sandbox, or use kernel features like user namespaces that are well mediated with current LSM, seccomp, etc yet17:47
jdstrandtooijar: within sanpd, allowing anyone to use that functionality without explicit permission means that snaps could abuse the system or break out of the sandbox17:48
jdstrandtooijar: so allow-sandbox: true is reserved for major browsers from established publishers17:48
kenvandinejdstrand: i got a USN email about the gtk-common-themes snap17:49
kenvandineRevision r1198 (all; channels: stable)17:49
kenvandine * libpng16-16: 3962-117:49
jdstrandtooijar: your typical electron app gets plenty of security from the snapd sandbox, for example17:49
kenvandinejdstrand: but that snap doesn't actually contain any libs17:49
jdstrandtooijar: so allow-sandbox: false is fine for all of them17:49
tooijarjdstrand: Thanks. That's even more helpful. Would be nice to have that level of explanation in https://docs.snapcraft.io/the-browser-support-interface/777517:49
jdstrandkenvandine: I'm guessing your manifest.yaml says something different17:49
* kenvandine looks17:50
jdstrandtooijar: that is what degville is looking at fixing17:50
tooijarjdstrand: My only concern is that chromium states that -no-sandbox is only for testing. That's from their point of view. Which is fine. But I wonder if they might one day decide that even for testing it shouldn't be used.17:50
tooijarAnd then disable that option altogether.17:51
jdstrandtooijar: sure. the chromium snap is allowed to use allow-sandbox: true17:51
kenvandinejdstrand: so that's the installed packages at build time right?17:51
jdstrandtooijar: so is brave17:51
jdstrandkenvandine: yes. ie, what is in stage-packages17:52
jdstrandkenvandine: you might 'organize' things away, but the tool doesn't know about all that17:52
kenvandinesure17:52
kenvandineok17:52
kenvandinefor gtk-common-themes i can ignore these then :)17:53
jdstrandkenvandine: you might spot check that someone didn't change the snapcraft.yaml, but sure, it is up to you to decide if you need to do anything17:53
kenvandinei did17:53
jdstrandthis is but one reason of many why we don't do a report card on snaps or publishers17:54
kenvandineand there are no libs at all in the installed snap17:54
kenvandinewhich i confirmed17:54
jdstrandkenvandine: yeah, I meant going forward if you get it, just double check someone didn't change it out from under your expectations17:54
kenvandinewill do17:54
mupPR snapcraft#2548 opened: integration tests: use correct series in get_package_version <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2548>18:03
jdstrandroadmr: hey, I don't recall if you responded to my request to pull r122618:04
roadmrjdstrand: oh! I didn't :( r1225 was deployed yesterday. I'll put r1226 in the usual queue18:04
mupPR snapd#6809 opened: snapcraft.yaml: fix links ld-linux-x86-64.so.2/ld64.so.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6809>18:05
jdstrandroadmr: thanks! :)18:06
Chipacajdstrand: that's the *second* time I get to quote you as '<jdstrand> Chipaca is right'18:06
Chipacanot that I'm keeping a tally or anything18:06
mupPR snapd#6801 closed: snapstate,devicestate: add snapstate.DeviceCtx to checkSnap* <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6801>18:06
jdstrandChipaca: \o/ :)18:14
jdstrandroadmr: actually, I'm going to have an r1227 for a new override in a moment18:14
roadmrjdstrand: oh! I haven't done r1226 because $reasons, so I might as well wait for that :)18:14
jdstrandroadmr: ok, can you pull r1228* ? (I forgot r1227 had a new override from yesterday)18:22
roadmrlol :)18:23
roadmrsure18:23
mupPR snapcraft#2549 opened: [legacy] integration tests: use correct series in get_package_version <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2549>18:27
jdstranddegville: curious, is the updating of https://docs.snapcraft.io/the-*-interface automatic from https://forum.snapcraft.io/t/the-*-interface? do you get a report and manually update?18:32
jdstranddegville: there is no problem. I see that my recentish changes to the personal-files docs in the forum are represented in docs.snapcraft.io so was just curious18:32
degvillejdstrand: it's automatically updated. The delay is usually less than 5 mins.18:33
jdstrandnice18:33
mupPR snapd#6810 opened: many:  do without device state/assertions accessors based on state only outside of devicestate/tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/6810>19:22
mupPR snapcraft#2548 closed: integration tests: use correct series in get_package_version <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2548>21:52
mupPR snapcraft#2549 closed: [legacy] integration tests: use correct series in get_package_version <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2549>21:58
mupPR snapd#6811 opened: tests: make create-user test support managed devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6811>23:56

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