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

mborzeckimorning04:58
zygagood  morning mborzecki05:48
mborzeckizyga: hey05:48
zygamborzecki: trying the new atom feature05:51
mborzeckizyga: what is it?05:51
zygahttps://blog.atom.io/2019/05/12/atom-1-37.html05:52
zygait's pretty neat :)05:53
mborzeckizyga: interesting05:54
zygamborzecki: updated https://github.com/snapcore/snapd/pull/6856/files06:11
mupPR #6856: cmd/snap-update-ns: add tests for executeMountProfileUpdate <Created by zyga> <https://github.com/snapcore/snapd/pull/6856>06:11
zygaspecifically this part https://github.com/snapcore/snapd/pull/6856/files#diff-6e1312a8e6236111d0199b57d496b986R8706:11
mborzeckizyga: do we have any helpers in the code to find a mount point given a device/source name?06:21
mborzeckioh, well, i'll use LoadMountInfo() then06:22
mborzeckioff to drop some papers at my accountant's06:53
=== pstolowski|afk is now known as pstolowski
pstolowskimornings07:01
pstolowskizyga: hey, you there?07:07
mborzeckire07:48
pstolowskimborzecki: hey, 6868 can land08:03
mborzeckipstolowski: hey08:03
mborzeckipstolowski: Chipaca: thanks for the reviews08:03
mupPR snapd#6868 closed: systemd: workaround systemctl show quirks on older systemd versions <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6868>08:04
mborzecki#6860 has some new selinux denials, need to look at those08:04
mupPR #6860: tests: running tests on fedora 30 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6860>08:04
mborzeckiChipaca: morning, thanks for the reviews!08:28
Chipacamborzecki: niets te danken, or something08:29
mborzeckiChipaca: nice :) still remembering some dutch?08:30
Chipacamborzecki: i think 'niets te danken' and 'natuurlijk' are the only bits i remember at this point08:31
Chipacamborzecki: dunno if you saw but i tagged #6868 for 2.3908:40
mupPR #6868: systemd: workaround systemctl show quirks on older systemd versions <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6868>08:40
Chipacabecause it seems to me to be the right combination of safe and important08:41
mborzeckiChipaca: great, thanks08:41
mborzeckiwe'll be doing .1 anyway to include zyga's fixes08:41
Chipacayep08:41
zygahey hey08:54
zygamy fixes are almost ready, just need to add an instance test08:54
zygaI was trying to get to it between sessions08:54
Chipacazyga: is that going to be in a separate pr?08:56
* mborzecki feels sorry for whoever will review the raw image writer bits 09:07
Chipacamborzecki: could you wrap up your review of #6721 at some point?09:15
mupPR #6721: tests: new profiler snap used to track cpu and memory for snapd and snap commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6721>09:15
mborzeckiChipaca: sure09:15
mborzeckiChipaca: all that was missing was +1 :)09:16
Chipacamborzecki: :)09:16
Chipacai'm using my gh.go thing to find low-hanging fruit09:16
mborzeckii've restarted travis jobs, last it built was 13 days ago09:17
Chipacamight need a re-merge, we'll see09:18
Chipacaanyway cazzo has a few housekeeping things to do with his PRs09:18
Chipacacmatsuoka: you around?09:24
cmatsuokaChipaca: hello09:24
Chipacacmatsuoka: hiya! good morning09:24
cmatsuokagood morning!09:25
Chipacacmatsuoka: the "RootOnly" flag is now merged, and I don't know what to do with #6679: if that work continues, is it going to start there, or are you going to do it again from scratch?09:25
mupPR #6679: many: implement user removal <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/6679>09:25
Chipacacmatsuoka: IOW should I close the PR :)09:25
ChipacaRootOnly was only one of the parts of the puzzle that needed solving first09:26
Chipacathe other was about classic09:26
cmatsuokaChipaca: I think it will be cleaner to restart from scratch, we can just drop the old PR09:26
Chipacacmatsuoka: ok. I'll close it, unless you want to do so09:27
cmatsuokaclose it, please09:27
cmatsuokaoh, the link is right here, I can close it as well09:29
* cmatsuoka still sleepy, jet lag09:29
mupPR snapd#6679 closed: many: implement user removal <Created by cmatsuoka> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6679>09:30
Chipacamborzecki: in #6680, when you say 'root only', do you mean _actual_ root only, or is logged-in ok also?09:31
mupPR #6680: [RFC] daemon: expose pprof endpoints <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6680>09:31
mborzeckiChipaca: hm it's trace & profiling, not sure if anthing sensitive is accessible through the api, it's probably just stacktraces & addresses09:33
mborzeckimaybe addresses are sensitive ?09:33
mborzeckiChipaca: limiting access to uid 0 probably the safest approach09:34
Chipacamborzecki: ok, i included how to do that in my review09:34
Chipaca('s trivial)09:34
mborzeckiChipaca: see that now, thanks09:34
Chipacacmatsuoka: I'll be working on the next bit of user thing refactoring, namely making the user thing not be there on classic by default09:35
Chipacacmatsuoka: after that you should be able to work on the removal without issue09:35
mupPR snapcraft#2564 opened: remote_build: handle git push in detached head state <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2564>09:43
mborzeckigoing back home09:51
zygaChipaca: that bug? no, all one PR10:00
zygaChipaca: all the propagation fixes are in one PR (still pending because conference)10:00
Chipacazyga: not related to #6866 then?10:01
mupPR #6866: cmd/snap-update-ns: allow changing mount propagation <Created by zyga> <https://github.com/snapcore/snapd/pull/6866>10:01
popey_when is 2.39 out?10:01
mupPR snapd#6869 opened: daemon: only allow `users`/`create-users` when not on classic* <Created by chipaca> <https://github.com/snapcore/snapd/pull/6869>10:32
Chipacahmm, that PR looks a little daunting10:32
Chipacapopey_: cachio was coordinating with mvo and store people, dunno how that went10:33
Chipacapopey_: "asap"10:33
popey_ok10:33
mborzeckire10:34
zigfordAnyone familiar with the recent change where snap-seccomp now requires a buildid? Version bumping my Gentoo snapd package and hung up on this.10:34
Chipacazigford: yes10:38
Chipacazigford: we landed a fix for that in master 15 days ago though10:38
Chipacazigford: not sure what you're building10:38
Chipacain particular: #678210:38
mupPR #6782: osutil: use go build-id when no gnu build-id is available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6782>10:38
zigfordDid that make it into 2.39?10:39
* Chipaca asks git10:40
Chipacazigford: no10:40
Chipacaat least, git says no10:41
zigfordokay, no worries. I'll see if I can just patch in that commit10:41
Chipacak10:41
Chipacazigford: I'll flag mvo to see if we add it to 2.39.110:41
zigfordConfirmed by looking in the release .tar.gz that it is not in 2.3910:43
zigfordI don't know what it takes to use gnu buildid's which is probably why it is not working without that commit on my Gentoo ebuild.10:44
Chipacazigford: I think it's because we got rid of CGO dependencies that would previously allow gnu buildid to be involved10:45
mborzeckihm that PR should not be required for snap-seccomp10:49
mborzeckizigford: does your snap-seccomp have no buildid?10:49
zigfordcorrect. The output when running snap-seccomp: error: cannot get build-id of snap-seccomp: executable does not contain a build ID10:50
zigfordI mean snap-seccomp version-info10:50
zigfordIt could be the way I'm compiling it too. I'm a bit of a n00b when it comes to golang10:50
mborzeckizigford: can you run `file <path-to-snap-seccomp>` ?10:53
zigfordCertainly appears to have a buildid according to file: snap-seccomp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, Go BuildID=a8kMN841Luo-M1zG6V_w/k1vJUu3M_98NWHHNQyDR/4QcWrWhdOMwMS78nFYhQ/pb96YzBzA9BKT4Mc4AMS, stripped10:53
mborzeckiinteresting, that's only the buildid added by go toolchain10:55
mborzeckizigford: when you build the package, can you add -x -v to go build and upload the output somewhere10:57
mupPR snapd#6870 opened: cmd/snap, api, snapstate: implement "snap remove --purge" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6870>10:57
zigfordhttp://zigford.org/build.log11:01
zigfordmight have to search, as that log builds all the bits11:02
mborzeckizigford: thanks, so it's using gcc to drive the linking, but somehoow there's no GNU buildid added11:06
mborzeckizigford: can you try this `echo 'int main() { return 0; }' | gcc -xc  - && file ./a.out` ?11:07
zigford./a.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped11:08
mborzeckizigford: right, but it adds gnu buildid automatically on my system11:09
zigfordCould BuildID's be a compile time option of GCC, ie, On Gentoo, GCC is compiled by my system, and the feature to create buildid's might be disabled11:09
mborzeckizigford: maybe some defaults are different, i doubt it would be disabled11:10
mborzeckizigford: can you try this: `echo 'int main() { return 0; }' | gcc -xc -Wl,--build-id=sha1 - && file ./a.out` ?11:10
zigford./a.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=9fe501acda2e1d8562da2548c42b9361344804f5, not stripped11:11
mborzeckizigford: just for the record, what's the version of binutils and gcc?11:12
zigfordgcc = 8.3.0, binutils = 2.31.111:13
thomascmHey everyone, is there a way to know if a bug if good for newcomers?11:15
mborzeckizigford: can you check if there's --enable-linker-build-id in gcc -v output?11:15
=== ricab is now known as ricab|bbl
zigfordalas, it is not11:17
mborzeckizigford: right, so the PR that Chipaca linked makes snapd side of things support both GNU build id and Go build id (in case the first one is missing), but that won't be available in 2.39 until 39.1 (?)11:19
mborzeckizigford: meanwhile, maybe there's a use flag to enable build-id by default? this is enabled in configure of gcc11:20
zigfordYeah, I quickly checked that, but I think I might be able to find another ebuild package the enables it and just plagerize their work :)11:21
zigfordSo, there does not appear to be a use flag for GCC to enable it by default11:21
Chipacathomascm: what do you mean?11:21
zigfordMany thanks for your assistence in tracking down the issue, mborzecki11:22
mborzeckizigford: np, perhaps you could tweak CC/CFLAGS/LDFLAGS to add -Wl,--build-id=sha111:23
thomascmchipaca: well there many bugs in launchpad, and I am not sure where to start, this is the first opensource project that I contribute to...usually someone is assigning me issues :P11:24
zigfordGreat idea. I'll post back here if I get it working11:24
Chipacathomascm: I don't think we've been good at tracking "bitesize" bugs11:27
Chipacawe tried to start doing that but it didn't get momentum11:27
Chipacathomascm: are you wanting to contribute to snapd, or to snapcraft?11:27
Chipacapstolowski: what's the "dangerous" thing in the purge pr?11:36
* Chipaca hugs pstolowski 11:43
Chipacapstolowski: 's good, just one mistake i think11:43
pstolowskiChipaca: thanks for catching!11:43
thomascmChipaca: snapd11:43
Chipacathomascm: what do you know? what can you do?11:44
pstolowskiChipaca: hmm. i think i will simply pass bool there in the client (+options which will still be expected to be nil as before). don't see any nice way to check if anything-but-purge was passed11:54
thomascmchipaca: sorry getting ready to leave for work. I can program in python, php, javascript, and new to golang ... I can handle most task, it just I don't have a lot of time, a few hours a week, so I rather start with smaller issues11:55
mupPR snapcraft#2565 opened: requirements: update to requests-toolbelt 0.8.0 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2565>11:58
cachiomborzecki, hey12:11
cachiomborzecki, there is a problem on fedora 3012:12
zigfordmborzecki: fixed by adding a parm to go like so: go install --ldflags '-extldflags "-Wl,--build-id=sha1"'12:12
cachioI run the suite in a vm and after some tests it is out of space on disk12:12
cachiomborzecki, it is weird because du -h says we use 4.5 of 9 GB12:13
cachiomborzecki, I created a debug machine if you want to take  a look12:13
mborzeckizigford: yup, that should work too12:13
cachioI am debugging this as well12:13
mborzeckicachio: can you point me to the log?12:14
cachiomborzecki, https://paste.ubuntu.com/p/ckqhnFxvFC/12:17
cachiomborzecki, this is one from my machine12:17
dot-tobiasjdstrand / diddledan: Ping re: /dev/shm if you have the time 😊  → https://forum.snapcraft.io/t/proposal-add-dev-shm-namespace-to-all-snaps-by-default/5416/5?u=tobias12:21
diddledandot-tobias: have you tried the `browser-support` interface for the dev/shm access?12:24
dot-tobiasdiddledan: Not yet, since I thought using this interfaces prevents publishing on the store without exceptions12:25
diddledanyou'll need to get approval for automatic connection of the interface if you need it12:25
diddledanyou can request the store admins to verify and approve/deny the automatic connection by posting in the store-requests category on the forum12:26
ijohnsondot-tobias: fwiw the snap you mention in your forum post seems like a browser so it doesn't seem unreasonable to provide browser-support to that snap12:30
mupPR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>12:32
mupPR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>12:32
mupPR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>12:33
mupPR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>12:33
dot-tobias ijohnson: Yep, its a browser 😊12:33
dot-tobiasdiddledan: Ok, will try out locally with browser-support instead of preload + desktop launch first. I'm including this snap in a gadget and ran into issues with auto-installing chromium-mir-kiosk with browser-support interface before, but maybe that's resolved12:34
ijohnsonyeah so requesting browser-support should be fine12:35
ijohnsonsince you're using a kiosk, you may have your snap flagged since it would be a daemon and also use browser-support, which is not automatically allowed but that should be approved eventually12:35
dot-tobiasdiddledan / ijohnson: Just tested if browser-support resolves the shared memory error, but does not seem like it: Still getting “Failed to create shared memory file /WK2SharedMemory.3964029874: Permission denied” with browser-support interface connected for my snap.12:37
ijohnsondot-tobias: what is the apparmor denial for your snap when you try this?12:38
dot-tobiasijohnson: For whatever reason there's no syslog on my Core test machine … Core 18 on PC gadget+kernel12:39
ijohnsoncan you get logs from `journalctl -e --no-pager | grep apparmor | grep DENIED12:40
dot-tobiasijohnson: Yup: May 15 12:36:24 localhost kernel: audit: type=1400 audit(1557923784.977:691): apparmor="DENIED" operation="mknod" profile="snap.wpe-webkit-mir-kiosk.browser" name="/dev/shm/WK2SharedMemory.1479971001" pid=29142 comm="cog" requested_mask="c" denied_mask="c" fsuid=0 ouid=012:41
ijohnsondot-tobias: hmm that should be allowed: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/browser_support.go#L22812:42
ijohnsonI assume your snap is a daemon because it's a kiosk, but just to clarify the wpe-webkit-mir-kiosk.browser app is a deamon right/12:43
ijohnson?12:43
dot-tobiasijohnson: Correct12:43
diddledanthat's with sandbox12:43
diddledanyou either need to specify the sandbox on the interface or disable the webkit sandbox12:43
ijohnsonahh yes listen to diddledan12:43
* ijohnson will be back in a bit12:44
dot-tobiasdiddledan: I'm testing locally with allow-sandbox: true and running into a very stupid problem … how do I specify a list of plugs for an app where one is not a simple list entry but a dict (i.e. browser-support: \n allow-sandbox: true)12:57
diddledanspecifying interface options is a separate block to the `plugs` on an app:12:58
=== ricab|bbl is now known as ricab
diddledanhttps://www.irccloud.com/pastebin/LFF8yqR4/12:59
Chipacacachio: standup?13:01
diddledanChipaca: sit down!13:01
Chipacadiddledan: dance!13:01
cachioChipaca, OMW13:02
diddledanboogy!13:02
Chipacacachio: k13:02
diddledan/o/13:02
diddledan\o\13:02
diddledan\o/13:02
diddledan/o\13:02
* Chipaca assigns bugs to diddledan 13:02
diddledanoh damn13:02
dot-tobiasdiddledan: Thanks, works – the /dev/shm error is gone, but for whatever reason WPE can't find libraries that are definitely in the snap (and work fine when using snapcraft-preload + desktop-launch). Need to investigate this more .13:07
zygare13:09
* dot-tobias waves at zyga13:11
Chipacacachio: there should be a few lines wrt that cycle, listing all the things in the cycle13:15
Chipacacachio: can you pastebin the whole thing?13:15
Chipacasystemd will be always killing one of the units in the cycle to break it, but it picks one at random13:15
cachioChipaca, https://paste.ubuntu.com/p/8p3xhCRZTH/13:16
cachioChipaca, random :s13:16
cachiothat explains why it is happening randomly13:16
Chipacacachio: so it's one of those four things13:18
Chipacathree, really, because one is a target13:18
Chipacaand two of them are google13:18
Chipacaso i guess it's just the one :-)13:18
cachiohehehe13:18
Chipacasuspect you need to talk with the cloud-init devs13:18
Chipacacachio: this is only on fedora?13:18
cachioChipaca, it is only on fedora 3013:19
Chipacamaybe they have a "different" version of something13:19
Chipacacachio: can you compare the unit files for those four things in fedora 30 vs 29, say?13:19
cachioChipaca, yes13:19
Chipacacachio: digo 30 vs 29 so they might be closer than 30 vs 19.0413:19
cachioI'll check that13:19
cachiook}13:20
Chipacacachio: OTOH if you're seeing bug reports with this issue for ubuntus, maybe it's known and fixed in cloud-init and just needs updating on fedora13:20
cachioChipaca, the issues reported are with the same error message but different root cause13:22
Chipacacachio: aw13:22
cachiosystemctl cat cloud-init13:22
cachioChipaca, I'll review the open issues first and compare configuration with f29 and u19.0413:24
cachioto see I can find the diff13:24
Chipacak13:24
Chipacapstolowski: OTOH wrt checking whether only Purge is set, go can compare "flat" structs directly, so just checking whether the struct was equal to the empty one or the empty one with just purge set would work13:42
Chipaca(and client.SnapOptions is "flat" in this sense)13:43
pstolowskihmm indeed13:44
pstolowskiChipaca: nah, doesn't work because of Users []string13:52
Chipacao dang13:52
Chipacawell13:53
Chipacayou could embed the bools and compare that13:53
Chipacabut it gets silly13:53
Chipacaevery other option is not allowed in multi13:53
Chipacaso just, go with that13:53
Chipacawe'll add support for multi sometime, and it'll be fine13:53
Chipacabut there's not a lot of demand so ¯\_(ツ)_/¯13:53
pstolowskiok13:54
Chipacapstolowski: maybe remove it from multiActionData also :)13:57
pstolowskioh yes!13:58
pstolowskity13:59
mupPR snapd#6871 opened: gadget: raw/bare strcuture writer and updater <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6871>14:27
mborzeckionly excuse i have is that tests make up ~70% of the whole thing14:29
Chipacacachio: note #6618 is >this< close to a second +1, there's a suggestion from mvo that's hard to ignore14:38
mupPR #6618: tests: validates snapd from ppa <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>14:38
cachioChipaca, yes, I'll update that PR today14:40
cachiothanks for the heads up14:41
Chipacacachio: ping me when you do (and it's green) so we can land that14:41
cachioChipaca, sure14:41
* cachio lunch14:42
Chipacaondra: ping14:51
ondraChipaca hey14:58
ondraChipaca what's up?14:58
Chipacaondra: hey15:01
Chipacaondra: looking at your PRs15:01
Chipacaondra: in particular #669115:01
mupPR #6691: boot: move ExtractKernelAssets <Created by kubiko> <https://github.com/snapcore/snapd/pull/6691>15:01
Chipacaondra: it looks abandoned15:02
ondraChipaca no, I just need update test based on mvo's comment15:02
ondraChipaca just did not find time yet :(15:02
Chipacaondra: ah, ok, so i'll review it then15:02
ondraChipaca actually review avahi one pls15:03
ondraChipaca https://github.com/snapcore/snapd/pull/632515:03
mupPR #6325: Allowing avahi-observer/control slots from app snap also on classic <Created by kubiko> <https://github.com/snapcore/snapd/pull/6325>15:03
Chipacaondra: it's got a needs-changes from jdstrand and conflicts15:03
ondraChipaca yeah I did those15:04
Chipacaondra: that means "stay away" in reviewese15:04
ondraChipaca but it based on those changes it was bigger change, so it'd be good to have extra pair of eyes on it15:04
ondraChipaca lol15:04
Chipacaondra: i tried to look at your lk pr, and that looks interesting but it includs 6691 and is rather big to review in a single go15:05
Chipacaondra: what's the status of #6327?15:05
mupPR #6327: Allowing sockets under /run/user/0/$SNAP_NAME <Created by kubiko> <https://github.com/snapcore/snapd/pull/6327>15:06
ondraChipaca also more looking for time to rewrite it based on jdstrand comments, but that's last one on my priority list now15:09
Chipacaondra: if it's a rewrite, would it be ok to close it? or is it not a rewrite in that sense15:09
ondraChipaca not in that sense, still same idea, just a bit more clever implementation15:10
Chipacaah well15:10
* Chipaca goes on down the list15:10
Chipacazyga: for per-user mounts is there something reviewable?15:24
Chipacamborzecki: what should we do with #6708 ?15:33
mupPR #6708: packaging/ubuntu: enable PIE hardening flags <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>15:33
Chipaca#6734 could use a second review15:40
mupPR #6734: advise-snap: add --dump-db which dumps the command database <Created by shawnl> <https://github.com/snapcore/snapd/pull/6734>15:40
zygaChipaca: I’m sorry for responding late18:04
zygaNot yet18:04
zygaNeed to sit down tonight18:04
Chipacazyga: no worries, asking only because i was going down the list18:30

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