| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#1295 opened: Record build packages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1295> | 06:34 |
|---|---|---|
| zyga | good morning | 06:57 |
| * zyga has reproduced the issue affecting debian | 06:57 | |
| zyga | locally | 06:57 |
| zyga | (finally) | 06:57 |
| zyga | morphis: thanks for your help, I'll either contribute a debian-creation script to autopkgtest or vendorize it to build spread images in my repository | 06:58 |
| morphis | zyga: np, which issue did you reproduce exactly? | 06:58 |
| morphis | the hanging configure hook? | 06:58 |
| zyga | morphis: yes | 07:01 |
| zyga | morphis: essentially I only got the image created late last night and I left it at the spread -debug prompt | 07:01 |
| morphis | zyga: that one happens on a regular debian installation with snapd installed from the archive | 07:01 |
| zyga | yes, I'm replying on the forum | 07:01 |
| morphis | zyga: this really much looks like we miss something in 2.24 which was fixed in 2.23.6 | 07:02 |
| zyga | morphis: hmm | 07:06 |
| morphis | zyga: interesting, however we broke distros like debian with this which would validate a hotfix for 2.24 and again proves that we always have to release snapd and a core snap in sync | 07:06 |
| zyga | morphis: wait | 07:07 |
| zyga | morphis: I'm 100% sure mvo merged all of 2.23.x into 2.24 | 07:07 |
| zyga | morphis: what this 2.24 sems to be lacking is a timeout on the hook | 07:07 |
| zyga | morphis: or a way to let it fail | 07:07 |
| zyga | morphis: this VM is up for 10 hours now | 07:07 |
| morphis | and the hook is still running? | 07:08 |
| zyga | morphis: and the hook is up for 10 yours still | 07:08 |
| zyga | morphis: yep | 07:08 |
| zyga | morphis: let's check the 2.24 tree to be sure we're not missing anything | 07:08 |
| morphis | ok | 07:09 |
| zyga | spineau: good morning :) | 07:09 |
| zyga | morphis: I found one small bug btw | 07:10 |
| spineau | zyga: morning zyga | 07:10 |
| zyga | in spread setup | 07:11 |
| zyga | morphis: PR coming up in a sec, just describing it | 07:12 |
| zyga | morphis: https://github.com/snapcore/snapd/pull/3264 | 07:15 |
| mup | PR snapd#3264: tests: remove quoting from [[ ]] when globs <Created by zyga> <https://github.com/snapcore/snapd/pull/3264> | 07:15 |
| zyga | morphis: and https://github.com/snapcore/snapd/pull/3265 | 07:15 |
| mup | PR snapd#3265: spread: add spread target qemu:debian-9-64 <Created by zyga> <https://github.com/snapcore/snapd/pull/3265> | 07:15 |
| zyga | morphis: now to investigate 2.24 | 07:15 |
| mup | PR snapd#3264 opened: tests: remove quoting from [[ ]] when globs <Created by zyga> <https://github.com/snapcore/snapd/pull/3264> | 07:15 |
| mup | PR snapd#3265 opened: spread: add spread target qemu:debian-9-64 <Created by zyga> <https://github.com/snapcore/snapd/pull/3265> | 07:15 |
| zyga | morphis: signed off is a personal preference, I just think it is important as a declaration of intent, there is no formal requirement to use it | 07:29 |
| morphis | zyga: yeah it is, but what are you signing off? | 07:30 |
| morphis | for the kernel its clear but for other projects its not unless explicitly stated somewhere | 07:31 |
| zyga | morphis: oh, right, I do use the same semantics | 07:31 |
| zyga | morphis: I think there is no other well-known semantics for that line | 07:31 |
| morphis | it normally refers to https://developercertificate.org/ | 07:31 |
| zyga | yep, (though I think I read that elsewhere, I wasn't aware of this domain before) | 07:32 |
| morphis | zyga: I think the linux foundation has its own copy of this | 07:34 |
| morphis | just wasn't sure what this means in the context of snapd as we have the CLA too | 07:34 |
| zyga | morphis: I think it formally does nothing but I really wish we had it over the CLA :) | 07:35 |
| zyga | morphis: so 2.24 should have a timeout | 07:35 |
| zyga | morphis: so checking WTF | 07:35 |
| morphis | zyga: however, should we go in the meantime with https://github.com/snapcore/snapd/pull/3259 to get all other PRs unblocked? | 07:39 |
| mup | PR snapd#3259: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259> | 07:39 |
| zyga | morphis: yes | 07:39 |
| zyga | I'll merge it now | 07:40 |
| morphis | ok | 07:40 |
| morphis | thanks | 07:40 |
| mup | PR snapd#3259 closed: tests/upgrade: force install core snap from beta for debian <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3259> | 07:40 |
| zyga | ok, let's merge master into some PRs and get some breakfast :) | 07:41 |
| morphis | :-) | 07:41 |
| zyga | ok, done | 07:47 |
| zyga | morphis: thank you, sorry for taking so long to merge this :) | 07:47 |
| zyga | morphis: I'll open a new thread to investigate the hook timeout issue | 07:47 |
| morphis | zyga: why not reusing the one we already have? | 07:47 |
| zyga | https://forum.snapcraft.io/t/hook-timeout-mechanism-not-working-in-2-24/464 | 07:49 |
| zyga | morphis: separate topic | 07:49 |
| zyga | morphis: I linked them though | 07:49 |
| zyga | hmmm | 07:54 |
| zyga | so I removed overlord/hookstate/Context.timeout (field in the struct) and no test captured that, looking deeper | 07:54 |
| zyga | ok, breaking this to really eat something... | 07:57 |
| dragly | Sorry for the basic question, but I am a bit confused after the folder structure changed: | 08:23 |
| dragly | If I have "snapcraft.yaml" in a folder named "snap", should "setup/gui/app.desktop" be inside "snap" as well? | 08:23 |
| dragly | I moved most files into the "snap" folder after snapcraft told me "plugins" should reside there. | 08:24 |
| mwhudson | hi so https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1657254 | 08:33 |
| mup | Bug #1657254: console-conf - unable to connect over proxy <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1657254> | 08:33 |
| mwhudson | so the ui side is pretty easy | 08:33 |
| mwhudson | but once the user has provided a proxy, the thing to do is stick it in /etc/environment and systemctl restart snapd? | 08:34 |
| zyga | mwhudson: probably,yes | 08:34 |
| Chipaca | zyga— o/ | 08:38 |
| Chipaca | zyga— you're feeling like finishing a review today? :-D | 08:38 |
| Chipaca | zyga— snapd#3264 is gtg once green, but random tests are failing in debian? | 08:41 |
| mup | PR snapd#3264: tests: remove quoting from [[ ]] when globs <Created by zyga> <https://github.com/snapcore/snapd/pull/3264> | 08:41 |
| zyga | Chipaca: hey | 08:47 |
| zyga | Chipaca: wrt 3264 yes, I'll merge master to fix it but spread is already overloaded | 08:47 |
| zyga | Chipaca: yes, I do feel like code reviews but I want to get to the bottom of hook timeout not working first | 08:48 |
| zyga | Chipaca: how are you doing? :) | 08:48 |
| Chipaca | jdstrand— snapd#2969 has conflicts | 08:50 |
| mup | PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969> | 08:50 |
| Chipaca | zyga— doing alright i think | 08:50 |
| Chipaca | finally got an appointment with physio wrt my back (nhs physio takes ages) | 08:51 |
| Chipaca | so hopefully i'll have that fixed and be able to get back to running soonish :-) | 08:51 |
| zyga | Chipaca: I hope you will | 08:53 |
| Chipaca | zyga— what was the cause (and fix) for “hsearch_r failed for |S_IFREG: No such process”? | 08:58 |
| zyga | Chipaca: snap-confine from distro used when profile was made by snapd from core snap | 09:03 |
| zyga | Chipaca: where are you seeing tihs | 09:03 |
| * mwhudson reads the code systemd uses to process EnvironmentFile= directives... | 09:04 | |
| * Chipaca hugs mwhudson | 09:04 | |
| Chipaca | why would you do this to yourself | 09:04 |
| mwhudson | the documentation is lacking | 09:04 |
| Chipaca | zyga— running snapd from master | 09:04 |
| Chipaca | zyga— on my dev laptop | 09:04 |
| zyga | Chipaca: hmm hmm | 09:04 |
| zyga | Chipaca: self built deb? | 09:04 |
| zyga | Chipaca: build&install snap-confine | 09:05 |
| Chipaca | zyga— no deb | 09:05 |
| zyga | Chipaca: it'll help | 09:05 |
| zyga | Chipaca: tip: make hack | 09:05 |
| Chipaca | ah | 09:05 |
| zyga | (in cmd/) | 09:05 |
| Chipaca | zyga— you've probably got the autoconf invocation in your bash history; care to share? | 09:05 |
| zyga | Chipaca: ./autogen.sh | 09:06 |
| zyga | Chipaca: make hack :) | 09:06 |
| zyga | Chipaca: that's all you need | 09:06 |
| Chipaca | that had a lot more options before | 09:06 |
| Chipaca | :-) | 09:06 |
| Chipaca | whoo. i like | 09:06 |
| * Chipaca runs it again without -n | 09:06 | |
| zyga | :D | 09:07 |
| mup | PR core-build#9 opened: Add writable boot for android-boot "bootloader" <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/9> | 09:07 |
| Chipaca | zyga— that sorted it, thanks! | 09:08 |
| mup | PR snapd#3258 closed: cmd/snap-confine/tests: fix shellcheck on recently added files <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3258> | 09:23 |
| zyga | Chipaca: I found something fishy in 2.24 | 09:40 |
| zyga | Chipaca: can you look at (in master) overlord/hookmgr/context.go | 09:40 |
| Chipaca | zyga— you want chips with that? | 09:40 |
| zyga | Chipaca: ha, I wish :D | 09:40 |
| zyga | Chipaca: the Context.timeout field is unused | 09:40 |
| Chipaca | zyga— in master it's overlord/hookstate/context.go | 09:41 |
| zyga | Chipaca: but Context.Timeout uses Context.setup.Timeout | 09:41 |
| zyga | ah, right | 09:41 |
| zyga | so I know we have a test that checks hook timeouts | 09:42 |
| zyga | but I also see this reliably not time out in spread :/ | 09:42 |
| zyga | the code there looks sane. I'll try to add debugging to see what really happens | 09:42 |
| Chipaca | the tests set Timeout on the setup also | 09:43 |
| Chipaca | zyga— i reckon that timeout in the context is a leftover bugish | 09:46 |
| zyga | yep | 09:47 |
| Chipaca | zyga— do you have a snap that should time out and doesn't? for testing here | 09:47 |
| zyga | ok, I'll start with 2.24 and focus on the test that checks it really works | 09:47 |
| zyga | Chipaca: yes, upgrade/basic as of 07182f7b1b7f7679f9e32f1511cc1669179c90f8 | 09:48 |
| zyga | Chipaca: but only on debian | 09:48 |
| zyga | Chipaca: where we don't have apparmor | 09:48 |
| zyga | Chipaca: if you look at 2eda8023ca28060e5a027822969399bfe89ee508 instead you can run this reliably in qemu | 09:48 |
| zyga | Chipaca: though you need a qemu image | 09:49 |
| zyga | Chipaca: (or via linode) | 09:50 |
| Chipaca | zyga— what hook isn't timing out? | 09:50 |
| Chipaca | config? iface? | 09:50 |
| Chipaca | device? | 09:50 |
| zyga | Chipaca: the way I understand it, the upgrade/basic test installs 2.24 and upgrades to master | 09:51 |
| zyga | Chipaca: so if 2.24 already had timeouts (and I think it does based on what I read) it should not hang with the hook there forever | 09:51 |
| Chipaca | ifacestate does not set a timeout | 09:51 |
| Chipaca | neither does devicestate | 09:52 |
| Chipaca | only config does | 09:52 |
| Chipaca | and it sets it to 5 minutes, overridable by SNAPD_CONFIGURE_HOOK_TIMEOUT environ | 09:52 |
| Chipaca | prepare.sh sets SNAPD_CONFIGURE_HOOK_TIMEOUT to 30s | 09:53 |
| Chipaca | for snapd | 09:53 |
| zyga | Chipaca: configure on core | 09:53 |
| zyga | Chipaca: and there is a timeout set, it's 5 minutes | 09:55 |
| zyga | Chipaca: it hangs because seccomp is enabled and core-support is disconnected | 09:55 |
| zyga | Chipaca: so seccomp kills part of snapctl | 09:55 |
| zyga | Chipaca: that's all expected | 09:55 |
| zyga | Chipaca: what is wrong is the timeout | 09:55 |
| zyga | Chipaca: task logs does not show we even try to kill it | 09:55 |
| Chipaca | hmm | 09:55 |
| Chipaca | zyga— does it not timeout, or does the killemall or something after it hang? | 09:56 |
| zyga_ | Chipaca: re, switched to mobile | 09:57 |
| zyga_ | Chipaca: I'm uploading a debian spread image in case you want to try | 09:57 |
| Chipaca | zyga— dunno if you saw my q about killemAll | 09:58 |
| zyga_ | Chipaca: no, sorry | 09:59 |
| zyga_ | Chipaca: lost in irc transition | 09:59 |
| Chipaca | <Chipaca> zyga— does it not timeout, or does the killemall or something after it hang? | 09:59 |
| zyga_ | Chipaca: it does not, it just keeps waiting for it to run | 10:04 |
| zyga_ | Chipaca: and according to my reading of the code, if it were timing it out the task log would say so | 10:05 |
| zyga_ | Chipaca: look at... | 10:05 |
| zyga_ | https://forum.snapcraft.io/t/tests-broken-in-master/457/10 | 10:05 |
| zyga_ | the tail of that | 10:05 |
| zyga_ | Chipaca: the qemu image will be uploaded in 9 minutes | 10:05 |
| Chipaca | i think it's all Son_Goku's fault | 10:11 |
| * Chipaca hides | 10:11 | |
| zyga_ | Chipaca: https://www.dropbox.com/sh/7k7qdo82vjjscy7/AADu7UsMsYXd5NYExOysgSx9a?dl=0 | 10:13 |
| === zyga_ is now known as zyga | ||
| zyga | Chipaca: you can get that image there | 10:13 |
| Chipaca | zyga— question: why not compressed? | 10:13 |
| zyga | Chipaca: qcow2 | 10:14 |
| Chipaca | i mean, i don't mind, my connection is fast enough :-) | 10:14 |
| zyga | Chipaca: it is compressed :) | 10:14 |
| Chipaca | but your upload is slow | 10:14 |
| zyga | Chipaca: I was just _uploading_ that :) | 10:14 |
| zyga | Chipaca: yeah, I was sending it over 3G | 10:14 |
| zyga | Chipaca: landline is sllooooow 0.1MB/s | 10:14 |
| Chipaca | zyga— qcow2 isn't compressed by default, and if it is it's readonly | 10:14 |
| zyga | Chipaca: over 3G I had 0.3MB/s outdoors and (I noticed by accident) 2.5MB/s while standing on the staircase inside the house | 10:15 |
| zyga | Chipaca: aha, do you think I can make it smaller then? | 10:15 |
| Chipaca | zyga— resonant cavities ftw | 10:15 |
| zyga | yeah but I was surprised :) | 10:16 |
| Chipaca | agreed, it'd be surprising to me too :-) | 10:17 |
| Chipaca | a happy surprise | 10:17 |
| Chipaca | knowing the mechanism does not make it any less fortunate | 10:17 |
| Son_Goku | ? | 10:19 |
| zyga | Son_Goku: I think chipaca was joking | 10:19 |
| Chipaca | Son_Goku— niemeyer isn't around to blame for everything, so it's your turn | 10:20 |
| zyga | we're trying to figure out what's going on wiht an apparently non-functional timeout on configure hooj | 10:20 |
| zyga | hook | 10:20 |
| Chipaca | zyga— bzip2 of the img would've saved 26% | 10:20 |
| Chipaca | debian-9-64.img: 1.351:1, 5.920 bits/byte, 26.00% saved, 789250048 in, 584078746 out. | 10:22 |
| Chipaca | anyway | 10:22 |
| Chipaca | what was i doing? | 10:23 |
| Chipaca | coffee. | 10:23 |
| Chipaca | zyga— how do you log in to the image you sent me? | 10:24 |
| Chipaca | ah | 10:24 |
| Chipaca | debian/debian | 10:24 |
| Chipaca | :-) | 10:24 |
| zyga | Chipaca: I added a readme file now | 10:27 |
| zyga | I'll re-compress it, drat :) | 10:28 |
| zyga | though I'll check xz | 10:28 |
| zyga | xz | 10:28 |
| Chipaca | zyga— is xz threaded now? | 10:28 |
| Chipaca | actually, never mind. I was going to coffee. | 10:28 |
| zyga | haha, enjoy :) | 10:28 |
| zyga | I have no idea | 10:28 |
| zyga | the compressor seems not to be | 10:28 |
| zyga | I commented on https://forum.snapcraft.io/t/hook-timeout-mechanism-not-working-in-2-24/464 | 10:35 |
| zyga | Chipaca: downto 474MB | 10:38 |
| zyga | Chipaca: so I made this https://spread.zygoon.pl/ | 11:01 |
| Chipaca | zyga— configure: error: xfs/xqm.h unavailable | 11:07 |
| Chipaca | morphis— ^ | 11:07 |
| Chipaca | looks like build deps are wrong on debian | 11:08 |
| morphis | Chipaca: where do you get that? | 11:08 |
| zyga | Chipaca: hmm, odd, you may need xfsprogs-dev for this | 11:09 |
| morphis | zyga, Chipaca: we have xfslibs-dev in debian/control | 11:10 |
| Chipaca | morphis— i get this on debian after doing `sudo apt build-dep snapd` and then running autogen.sh from cmd/ | 11:11 |
| zyga | Chipaca: this gets you deps for what is in the distro | 11:11 |
| Chipaca | and that has not brought in xfslibs-dev | 11:11 |
| zyga | Chipaca: not for what you have in the tree | 11:12 |
| morphis | Chipaca: ah, on debian we have snapd 2.21 only | 11:12 |
| Chipaca | ah | 11:12 |
| Chipaca | i should've done build-dep ./ | 11:12 |
| morphis | yeah | 11:12 |
| Chipaca | yeah that brings it in | 11:12 |
| Chipaca | sorry for the noise then :-) | 11:12 |
| morphis | np :-) | 11:12 |
| Chipaca | zyga— and 'make hack' falls over because no apparmor_parser | 11:13 |
| Chipaca | boo, etc | 11:13 |
| morphis | Chipaca: did you configure with --disable-apparmor? | 11:15 |
| Chipaca | morphis: I ./autogen.sh --disable-apparmor | 11:16 |
| Chipaca | morphis: but I don't see that passing the option on to configure | 11:16 |
| Chipaca | morphis: but it does have debian-specific opts iin there | 11:17 |
| Chipaca | morphis: what should i do? | 11:17 |
| morphis | debian-specific opts in the configure script? | 11:18 |
| Chipaca | no, in autogen.sh | 11:18 |
| Chipaca | --libexecdir=/usr/lib/snapd | 11:18 |
| morphis | AFAIK autogen.sh checks for /etc/os-release and configures accordingly | 11:18 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | morphis: yes, but all it does for debian is the above, no --disable-apparmor | 11:19 |
| morphis | Chipaca: but for `make hack` it looks like the easiest way is to disable the apparmor profile installation manually in Makefile.am | 11:19 |
| Chipaca | and even with disable-apparmor, "make hack" tries to use apparmor_parser | 11:19 |
| Chipaca | yeap | 11:20 |
| morphis | yeah seems to be a short coming of the Makefile.am implementation | 11:20 |
| morphis | Chipaca: looks like we need a if WITH_APPARMOR in there | 11:22 |
| Chipaca | also, would be extra neat if 'make hack' dtrt wrt the go binaries as well | 11:22 |
| morphis | Chipaca: yes | 11:23 |
| * zyga breaks for lunch | 11:24 | |
| Chipaca | zyga: I think I set things up to reproduce the thing, but it didn't work (or rather, it worked). After lunch can you walk me through this? | 11:36 |
| zyga | re | 12:06 |
| zyga | Chipaca: yes | 12:06 |
| zyga | Chipaca: gladly! | 12:06 |
| Chipaca | zyga: so, how do i repro? :-) | 12:06 |
| morphis | zyga: do we want to keep our sync meeting today or do we want to drop it with Alex and Jamie both being out? | 12:06 |
| zyga | morphis: let's drop it | 12:07 |
| morphis | zyga: ok | 12:07 |
| zyga | morphis: fyi, I'd like to collect more images on http://spread.zygoon.pl/ | 12:07 |
| morphis | zyga: done | 12:07 |
| zyga | morphis: thanks | 12:07 |
| morphis | zyga: I can contribute a fedora-25-64 image | 12:08 |
| zyga | morphis: I can also start auto-building all the images and keeping them the web | 12:08 |
| zyga | morphis: great! | 12:08 |
| zyga | morphis: ideally you'd share something I can wget | 12:08 |
| zyga | Chipaca: ok, let's try this together | 12:08 |
| zyga | Chipaca: give me a sec for the current run to complete | 12:09 |
| Chipaca | zyga: i'm on detached head 2eda8023c | 12:09 |
| morphis | zyga: let me compress and upload | 12:09 |
| zyga | morphis: great | 12:09 |
| zyga | morphis: perhaps you can upload to dropbox? | 12:09 |
| Chipaca | zyga: built snap-confine, -exec, and d, running d with SNAP_REEXEC=0 et al | 12:09 |
| morphis | don't really use dropbox | 12:09 |
| zyga | morphis: ok | 12:10 |
| morphis | zyga: but will upload to my server | 12:10 |
| zyga | Chipaca: so, I didn't get that far, so far I can run it if I run the upgrade/basic test on debian-9-64 | 12:10 |
| zyga | Chipaca: this starts with 2.24 | 12:10 |
| zyga | Chipaca: and updates to master | 12:10 |
| zyga | (though the update fails) | 12:10 |
| zyga | Chipaca: give me a few more minutes for the current run to fail | 12:10 |
| zyga | Chipaca: so I think that what we need to try instead, if you want interactive session, is to get 2.24 | 12:11 |
| zyga | Chipaca: add some debugging if you like | 12:11 |
| zyga | Chipaca: build the deb and install it on debian-9 | 12:11 |
| zyga | Chipaca: and then snap install core | 12:11 |
| zyga | Chipaca: (stable) | 12:11 |
| zyga | Chipaca: and see what happens | 12:11 |
| zyga | Chipaca: it should break because of seccomp | 12:11 |
| zyga | Chipaca: but then we should time out the hook after 5 minutes | 12:11 |
| zyga | Chipaca: do you agree? | 12:11 |
| Chipaca | zyga: I'll try | 12:13 |
| zyga | Chipaca: ok I will too | 12:15 |
| jdstrand | Chipaca: re snapd#2969> ack, thanks. fixed | 12:17 |
| mup | PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969> | 12:17 |
| Chipaca | zyga: you should review stuff ^ :-) | 12:19 |
| mup | PR snapd#3252 closed: tests,cmd/snap-confine: port older snapd-discard-ns tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3252> | 12:19 |
| zyga | Chipaca: aha, I guess so | 12:20 |
| * zyga opens a new ta | 12:20 | |
| zyga | *tab | 12:20 |
| zyga | ah, it is this branch | 12:21 |
| * zyga read it already | 12:21 | |
| dragly | ogra_: I tried the after: [desktop-qt5] step you recommended. Are there any requirements for it to work? Currently, it fails on a clean build with an error "No such file or directory: [...]/mypart/install/bin", where mypart is a completely different part in snapcraft.yml. | 12:22 |
| dragly | However, if I remove it, build again, then add it, and build once more, it works. | 12:22 |
| dragly | Seems like it depends on other parts to create an install dir for some reason. | 12:22 |
| morphis | zyga: uploading .. | 12:24 |
| dragly | Checked the backgrace, and it happens in _file_collides. | 12:24 |
| dragly | backtrace* | 12:24 |
| dragly | Must be that _file_collides assumes other parts actually install something. | 12:25 |
| zyga | gah, my network, what is going on :/ | 12:36 |
| === petevg is now known as petevg_afk | ||
| Chipaca | niemeyer: if you drop by, you requested changes on snapd#3026, zyga did as requested (on 14/03, ie 50 days ago), branch LGTM, is it OK to merge as is? | 12:43 |
| mup | PR snapd#3026: cmd/snap-confine: use defensive argument parser <Created by zyga> <https://github.com/snapcore/snapd/pull/3026> | 12:43 |
| niemeyer | Chipaca: Heya | 12:44 |
| niemeyer | Chipaca: That's not true.. I've looked at this PR last week and it wasn't fixed | 12:45 |
| Chipaca | niemeyer: git disagrees, but maybe he forgot to push | 12:45 |
| niemeyer | Chipaca: Happy to have a look again when we have a break here | 12:45 |
| Chipaca | or maybe i'm misreading what github says | 12:45 |
| Chipaca | anyway, yeah, take a gander | 12:46 |
| niemeyer | Chipaca: One of us is misreading.. I see "cmd/snap-confine: simplifiy error handling from argument parser" few days ago | 12:47 |
| Chipaca | ¯\_(ツ)_/¯ | 12:48 |
| Chipaca | niemeyer: yeah, github just said "added commits on 14 mar" here | 12:49 |
| Chipaca | had to look into commits to see that detail | 12:49 |
| morphis | zyga: https://mm.gravedo.de/files/fedora-25-64.img.xz | 12:56 |
| morphis | Son_Goku: any time to check https://bugzilla.redhat.com/show_bug.cgi?id=1444819 again? | 12:57 |
| zyga | Chipaca: standp? | 13:03 |
| zyga | morphis: thanks! | 13:03 |
| zyga | morphis: thanks, I have it now | 13:04 |
| mup | PR snapd#3266 opened: interfaces: allow plugging DBus clients to introspect the slot service <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3266> | 13:07 |
| Chipaca | hmmm | 13:26 |
| Chipaca | zyga: with qemu-img we can create a local qcow2 image that used an http image as the backing file; this'd probably be faster than downloading the images | 13:26 |
| Chipaca | zyga: (but you'd have to de-xz the .img for that) | 13:27 |
| Chipaca | zyga: if you have ssh access to spread.zygoon.pl and can xunz -k, i can test this | 13:28 |
| zyga | Chipaca: yes, sure | 13:30 |
| zyga | Chipaca: it's my server | 13:30 |
| Chipaca | zyga: there exist servers that only give you ftp access, to this day /o\ | 13:30 |
| zyga | Chipaca: decompressing | 13:31 |
| zyga | Chipaca: FYI, my test is now doing this: [/] Run configure hook of "core" snap if present | 13:31 |
| Chipaca | zyga: yeah, here as well (taking way too long at it) | 13:31 |
| zyga | Chipaca: done | 13:32 |
| zyga | Chipaca: how do you make those magic qemu images? | 13:32 |
| zyga | Chipaca: and does qemu cache anything? | 13:32 |
| ogra_ | if you use http you can easily decompress during download on the fly btw ... | 13:34 |
| ogra_ | URL=http://cdimage.ubuntu.com/ubuntu-base/xenial/daily/current/xenial-base-amd64.tar.gz | 13:35 |
| ogra_ | CHROOT=xenial-test-chroot | 13:35 |
| ogra_ | wget -q -O - $URL | zcat - | sudo tar x -C $CHROOT | 13:35 |
| Chipaca | zyga: qemu-img create -f qcow2 -b https://spread.zygoon.pl/debian-9-64.img debian-9-64.img | 13:35 |
| ogra_ | that wont use any disk space and decompress during download | 13:35 |
| ogra_ | (works fine with xzcat too) | 13:35 |
| Chipaca | ogra_: my point is we don't use _most_of the image, so we can avoid downloading it | 13:35 |
| zyga | ogra_: ooh | 13:36 |
| zyga | nice | 13:36 |
| ogra_ | ah,. completely, yeah | 13:36 |
| zyga | let's try that | 13:36 |
| ogra_ | wget -q -O - $URL | html2text | grep .... <- easy way to grep through website content ;) | 13:37 |
| zyga | ogra_: .xz doesnt work | 13:37 |
| zyga | but plain does :) | 13:37 |
| zyga | it boots | 13:37 |
| cpaelzer | ogra_: worth a try for sure but is that fetching it in streaming still or will it use http range requests to read partially? | 13:37 |
| zyga | pretty neat!!! | 13:37 |
| ogra_ | cpaelzer, i think wget just streams ... | 13:37 |
| cpaelzer | ogra_: in the use as qcow backing file I meant | 13:38 |
| ogra_ | directly to stdout at lest ... so it depends whet the next command in the pipe does | 13:38 |
| Chipaca | cpaelzer: the qemu-img approach does range requests afaik fwiw | 13:38 |
| ogra_ | cpaelzer, well, i never used it in that context ... | 13:39 |
| cpaelzer | ok that I expected, be careful then | 13:39 |
| * ogra_ uses it mostly to stream tarballs to disk to avoid debootstrap | 13:39 | |
| zyga | Chipaca: ok, the test just failed for me! | 13:39 |
| cpaelzer | I'd assume something in the order of a few hundreds individual requests might take as long as the full image :-) | 13:39 |
| zyga | Chipaca: no mention of restarts! | 13:39 |
| Chipaca | yeah it never moves on from the hook | 13:40 |
| Chipaca | and yes it's snapd 2.24 | 13:45 |
| Chipaca | from core 1689 | 13:45 |
| mup | PR snapcraft#1292 closed: tests: fix the recording tests to work in multiple architectures <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1292> | 13:46 |
| Chipaca | wait no that core version is wrong (wrong terminal :-) ) | 13:48 |
| Chipaca | but how do i then have snapd 2.24 | 13:48 |
| Chipaca | with no core | 13:48 |
| Chipaca | ooooohhhhh | 13:50 |
| Chipaca | also: whaaaa | 13:50 |
| Chipaca | this is a nice bug | 13:50 |
| Chipaca | zyga: snapd restarted into the new snapd, but if it fails afterwards it does not restart back into old when rolling back | 13:51 |
| Chipaca | jdstrand: any reason not to land snapd#2969? | 13:56 |
| mup | PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969> | 13:56 |
| mpontillo | So I have a snap with stage-packages including python2.7, and upstream code looking for 'python' on the path. Looks like it only installs the 'python2.7' binary. Anyone know the best way to just make a symlink from usr/bin/python2.7 -> usr/bin/python? | 13:56 |
| zyga | Chipaca: what? :D | 14:00 |
| Chipaca | zyga: you run that test with -debug, yes? | 14:01 |
| zyga | Chipaca: wait, let me grok this | 14:01 |
| zyga | Chipaca: but don't we disable reexec for that test? | 14:01 |
| zyga | yes | 14:01 |
| Chipaca | zyga: so when it fails you get a shell | 14:01 |
| zyga | I have the shell stull open | 14:01 |
| Chipaca | zyga: in that shell, do 'snap version' | 14:01 |
| zyga | it says 2.24 | 14:01 |
| Chipaca | zyga: and snap is 2.21-something, yes? | 14:01 |
| zyga | yes | 14:02 |
| zyga | (ah, so we *do* reexec) | 14:02 |
| Chipaca | zyga: ok, so 'snap abort 1' | 14:02 |
| * zyga was confused by this then | 14:02 | |
| zyga | done | 14:02 |
| zyga | 2.21 | 14:02 |
| zyga | now I get 2.21 | 14:02 |
| zyga | of snap | 14:02 |
| zyga | but not snapd | 14:02 |
| Chipaca | zyga: for snapd as well? | 14:02 |
| zyga | aaaaah | 14:02 |
| Chipaca | right | 14:02 |
| zyga | so snapd keeps being there | 14:02 |
| Chipaca | zyga: now a 'systemctl restart snapd' gets you back the snapd 2.21 | 14:02 |
| zyga | yes | 14:03 |
| Chipaca | zyga: unless the tests are doing something weird to get that snapd version | 14:03 |
| Chipaca | (which could be!) | 14:03 |
| zyga | no, they don't | 14:03 |
| zyga | they just install it from the packge | 14:03 |
| Chipaca | so, yeah | 14:03 |
| zyga | so are we seeing two bugs now? | 14:03 |
| Chipaca | something is awry | 14:03 |
| zyga | fist of all, when it was stuck | 14:03 |
| zyga | it was already 2.24? | 14:03 |
| Chipaca | zyga: it's bugs all the way down | 14:03 |
| zyga | or was it sitll 2.21+b2 | 14:03 |
| Chipaca | zyga: 'snap change 1' will tell you that | 14:03 |
| zyga | 2017-05-03T15:22:34+02:00 INFO Requested daemon restart. | 14:04 |
| zyga | so 2.24 from the core snap | 14:04 |
| zyga | so, that version definitely has hook bug | 14:04 |
| zyga | I ran 2.24 directly on ubuntu and tried to get the spread test tha checks this to fail | 14:04 |
| zyga | and it didn't though | 14:04 |
| zyga | perhaps it's a combination of some factors that makes it hang | 14:04 |
| Chipaca | zyga: what's probably happening | 14:06 |
| Chipaca | and I'm guessing here | 14:06 |
| Chipaca | is that 2.21 did not set the timeout | 14:06 |
| Chipaca | and 2.24 gets it from state | 14:06 |
| Chipaca | ... where it was put by 2.21 | 14:06 |
| Chipaca | so the fix is: when you don't want a timeout, put a _negative_ duration as the timeout | 14:07 |
| zyga | oooh | 14:07 |
| zyga | definitely! | 14:07 |
| Chipaca | in the check to timeout, check for negative instead of > 0 | 14:07 |
| Chipaca | == 0 --> default timeout for the task (backwards compat etc) | 14:07 |
| Chipaca | < 0 --> no timeout | 14:08 |
| zyga | aha | 14:08 |
| Chipaca | > 0 --> go on holidays | 14:08 |
| Chipaca | \o/ | 14:08 |
| zyga | well, we need some form of tri-state for sure | 14:08 |
| zyga | thank you for solving that one! | 14:08 |
| zyga | I didn't think about pre 2.24 making the state | 14:08 |
| Chipaca | we need patches working again | 14:08 |
| zyga | so... | 14:08 |
| Chipaca | is what we need | 14:08 |
| zyga | yes :/ | 14:08 |
| zyga | can we do a patch that fixes it? | 14:08 |
| zyga | sets a timeout on confiugre hook if missing | 14:08 |
| zyga | it's not the end of the world if we cannot undo it | 14:08 |
| zyga | wtyt? | 14:08 |
| zyga | wdyt? | 14:09 |
| Chipaca | i think the rule is no patches until we fix them | 14:09 |
| mpontillo | Figured it out. Added python-minimal to stage-packages. | 14:09 |
| zyga | Chipaca: can we fix it anywhere eles? | 14:09 |
| zyga | Chipaca: I mean we did certainly a lot of patch-like things lately | 14:09 |
| zyga | e.g. all the fixes for plug renames | 14:09 |
| zyga | those are exactly patches but not called that | 14:09 |
| zyga | :D | 14:09 |
| Chipaca | zyga: we can do one of those patch-like things, because it's backwards-compatible | 14:09 |
| zyga | gee, let me lock the state, change it and unlock here | 14:09 |
| Chipaca | that is, if the state has a timeout, the old snap just won't load it | 14:10 |
| Chipaca | so yes we can and should do that | 14:10 |
| Chipaca | zyga: and yes, snapd being at the wrong version after that abort is another bug | 14:10 |
| zyga | Chipaca: great find, thank you! | 14:10 |
| jdstrand | Chipaca: from my perspective, no, but I was hoping morphis would glance at it since I touched a bunch of interfaces his team implemented | 14:10 |
| zyga | I was staring at it for so long without realizing it | 14:11 |
| Chipaca | morphis: can you look at snapd#2969 ? | 14:11 |
| mup | PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969> | 14:11 |
| zyga | morphis: I'll merge it when you give it +1 | 14:11 |
| zyga | Chipaca: I'll start with the patch for the hook timeout | 14:11 |
| Chipaca | morphis: no pressure :-p | 14:11 |
| Chipaca | zyga: ok | 14:11 |
| zyga | Chipaca: as for reexec back | 14:11 |
| zyga | Chipaca: do you mean that we need to figure out that something failed and we need to shutdown snapd? | 14:11 |
| zyga | Chipaca: when undoing one of the tasks? | 14:12 |
| === bdx_ is now known as bdx | ||
| * zyga has built all the spread images for ubuntu now | 14:13 | |
| zyga | it was faster to spawn a VM, build them and reattach a disk than to upload from home | 14:13 |
| Chipaca | zyga: i'm saying, doLinkSnap has maybeRestart(); there needs to be a maybeRestart on the undo path | 14:13 |
| zyga | aha, that does make sense! | 14:13 |
| Chipaca | and there is one in undoUnlinkCurrentSnap | 14:14 |
| zyga | well | 14:14 |
| zyga | I'm happy that it turned out to be double-plus-good :) | 14:14 |
| zyga | not a wasted day and no bugs found | 14:14 |
| Chipaca | so we need a test for this to figure out why it's not working :-) | 14:15 |
| morphis | Chipaca, jdstrand: didn't I comment already? thought I did as I was looking at that PR | 14:15 |
| Chipaca | (an integrationy test, not a unit test which it does have i believe) | 14:15 |
| zyga | Chipaca: aha | 14:16 |
| morphis | Chipaca, jdstrand: however I would prefer to get that into edge soon so our CI can execute against it | 14:16 |
| morphis | then we will see if anything for those interfaces is broken the best way | 14:16 |
| Chipaca | morphis: was that a "yes +1 land it plz"? | 14:20 |
| * zyga reads the hook manager code closely | 14:21 | |
| morphis | Chipaca: yes | 14:21 |
| morphis | let me add a comment | 14:21 |
| Chipaca | boom, merged | 14:22 |
| mup | PR snapd#2969 closed: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2969> | 14:22 |
| Chipaca | 33 PRs. Bring it on! | 14:22 |
| Chipaca | zyga: how's the tab completion review coming along? | 14:22 |
| zyga | Chipaca: hmm, I could switch to it now | 14:23 |
| zyga | or look at the hook manager | 14:23 |
| zyga | hmm | 14:23 |
| zyga | pick :) | 14:23 |
| Chipaca | zyga: serialise things dude :-) | 14:23 |
| zyga | Chipaca: ok, let me look for 10 minutes | 14:24 |
| zyga | with hot context | 14:24 |
| Chipaca | ah, pavel is away today | 14:24 |
| Chipaca | niemeyer: snapd#3119 is blocked waiting for a review from you, also (and it's old!) | 14:26 |
| mup | PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119> | 14:26 |
| * zyga got small electric shock | 14:30 | |
| zyga | darn uk adapters :/ | 14:30 |
| niemeyer | Chipaca: Thanks, I think there are several things in the queue which need love | 14:31 |
| Chipaca | niemeyer: need love from reviewers, or from writers? | 14:31 |
| niemeyer | I was hoping to have more time here, but turns out we're running from meeting to meeting as usual | 14:32 |
| niemeyer | Chipaca: I suspect both, but I need to go back to our review board | 14:32 |
| niemeyer | Which is out of date | 14:32 |
| Chipaca | :-) ok | 14:32 |
| Chipaca | niemeyer: i was just going through https://github.com/snapcore/snapd/pulls and poking people | 14:33 |
| Chipaca | not being particularly methodic as i was trying to repro the 2.21/2.24 debian issue above | 14:33 |
| niemeyer | Chipaca: Thanks for pushing the reviews forward! | 14:52 |
| Chipaca | niemeyer: shut up and get reviewing! | 14:52 |
| Chipaca | :-D | 14:53 |
| Chipaca | how's the sprint btw | 14:53 |
| niemeyer | More long plenaries than smaller decision meetings.. we need some more of the latter before the week is over | 14:54 |
| niemeyer | On the bright side we got the +1 to move on with our development Sprint.. I need to push its organization forward | 14:55 |
| Chipaca | niemeyer: delegate (not that i'm offering) | 15:00 |
| Chipaca | niemeyer: you've got way too much on your plate | 15:00 |
| niemeyer | Chipaca: Curiosity, I'm actually pretty hungry right now :P | 15:02 |
| niemeyer | Curiously | 15:02 |
| zyga | Chipaca: can you pull master into 3150 please? | 15:03 |
| zyga | Chipaca: or just let me... | 15:06 |
| Chipaca | zyga: snapd#3150? | 15:06 |
| mup | PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150> | 15:06 |
| zyga | Chipaca: yes | 15:06 |
| zyga | if you cna please do :) | 15:06 |
| Chipaca | sure, give me a mo | 15:06 |
| * zyga fetches --all | 15:06 | |
| zyga | thnx | 15:06 |
| Chipaca | zyga: any reason for the merge? | 15:07 |
| Chipaca | i ask because it'll trigger a retest, and i've been triggering a lot of those :-) | 15:09 |
| mup | PR snapcraft#1242 closed: kernel_plugin: use CROSS_COMPILE to override the default toolchain <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1242> | 15:10 |
| zyga | Chipaca: just to have a chance to pass all tests | 15:11 |
| * zyga read the text above as GROSS_COMPILE | 15:11 | |
| Chipaca | zyga: merged and pushed | 15:12 |
| zyga | Chipaca: thank you | 15:12 |
| mup | PR snapd#3265 closed: spread: add spread target qemu:debian-9-64 <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3265> | 15:14 |
| mup | PR snapcraft#1204 closed: target-arch: decouple target arch from deb, and use a separate field … <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1204> | 15:28 |
| Son_Goku | morphis: I'll try to squeeze some time to check it today (at Red Hat Summit atm) | 15:29 |
| Chipaca | zyga: can you answer jdstrand on snapd#3253? | 16:20 |
| mup | PR snapd#3253: cmd/snap-confine/spread-tests: discard useless --version test <Created by zyga> <https://github.com/snapcore/snapd/pull/3253> | 16:20 |
| zyga | Chipaca: looking | 16:21 |
| zyga | Chipaca: done | 16:23 |
| Chipaca | zyga: 'ppreciated | 16:23 |
| kyrofa | Hey ogra_, I thought the rpi3 had spi enabled (we talked about this before)? | 16:24 |
| kyrofa | ogra_, https://askubuntu.com/questions/911510/ubuntu-core-on-raspberry-pi-3-spi-driver-isnt-available | 16:24 |
| kyrofa | ogra_, any idea on that one? | 16:24 |
| morphis | Pharaoh_Atem: sounds good | 16:31 |
| Chipaca | zyga: snapd#3150 is now green again :-) | 16:33 |
| mup | PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150> | 16:33 |
| zyga | Chipaca: let there be merge! | 16:34 |
| * zyga does one _last_ read | 16:34 | |
| * Chipaca lifts his finger from the big green button | 16:34 | |
| * zyga notices lots of nice documentation! | 16:35 | |
| zyga | Chipaca: do we need a GPL header in the new shell script? | 16:35 |
| * zyga will add comments from now | 16:36 | |
| Chipaca | zyga: ... maybe? | 16:36 |
| Chipaca | zyga: i mean, yeah, we do :-/ | 16:36 |
| zyga | Chipaca: wait with the push as I also added small nitpick and we'll save one test slot | 16:37 |
| Chipaca | why do some spread runs take nearly an hour (coming dangerously close to being killed) | 16:38 |
| Chipaca | and, killed :-( | 16:39 |
| zyga | Chipaca: what is bounced? | 16:39 |
| zyga | Chipaca: allocation contention? | 16:39 |
| zyga | we need to figoure out queing | 16:40 |
| * zyga fetches coffee and gets right back up here | 16:40 | |
| Chipaca | zyga: bounced are things that the snap requests be tab completed, but that end up needing completing "outside" the snap | 16:40 |
| Chipaca | zyga: variable names, shell aliases, shell functions, that sort of thing | 16:41 |
| Chipaca | they're bounced from the completion mechanism inside, back to the outside to be completed there | 16:41 |
| zyga | aha | 16:45 |
| zyga | Chipaca: what is <( ... ) ? | 17:00 |
| zyga | apart from chicken head? | 17:00 |
| Chipaca | zyga: <(o_o<) | 17:01 |
| Chipaca | zyga: it's called process substitution | 17:01 |
| nacc | is that ascii-kirby? | 17:01 |
| Chipaca | zyga: man bash, look for that | 17:01 |
| zyga | thanks! | 17:01 |
| Chipaca | zyga: but basically you write foo <(bar), the shell runs bar, sends its output to a_file, and runs foo a_file | 17:03 |
| zyga | aha | 17:03 |
| zyga | right, I just read that | 17:03 |
| zyga | man, | 17:03 |
| Chipaca | whether a_file is an actual file or something more magic is system-dependent | 17:03 |
| zyga | shell | 17:03 |
| zyga | shell is insane :) | 17:03 |
| Chipaca | zyga: no, man bash, man shell is something else | 17:03 |
| zyga | ;-) | 17:04 |
| Chipaca | and then there's <( ᐛ )> | 17:05 |
| mup | PR snapcraft#1296 opened: rust snaps can now use source-subdir without failing on pull <Created by roxyd> <https://github.com/snapcore/snapcraft/pull/1296> | 17:07 |
| Chipaca | anyhow, EODish from me | 17:12 |
| zyga | Chipaca: that's the chicken looking for food | 17:12 |
| Chipaca | i'll be back to tend to these two spread runs but other than that, i'm out | 17:12 |
| Chipaca | zyga: ᕕ( ᐛ )ᕗ | 17:12 |
| zyga | d-d-dancing! | 17:13 |
| zyga | jdstrand: question about https://github.com/snapcore/snapd/pull/3266 | 17:24 |
| zyga | jdstrand: would it make sense to allow introspection on any object? | 17:24 |
| zyga | jdstrand: or is that leaking stuff? | 17:24 |
| jdstrand | zyga: fyi, I don't know if you want to merge from trunk. https://github.com/snapcore/snapd/pull/3254 seems to keep taking too long | 17:24 |
| zyga | I cannot remember if we can read properties this way, I think not though) | 17:24 |
| zyga | jdstrand: it should be fine, just needs to be re-triggered when spread is idle | 17:25 |
| jdstrand | zyga: it would leak stuff in my opinion. we should only allow introspecting the things that the interface allows access to. I don't think it should be part of default policy | 17:25 |
| zyga | jdstrand: reading the diff now, I have more questions, what does it mean that path is not object specific for unconfined? | 17:25 |
| jdstrand | look at the commented out rule and the description | 17:26 |
| jdstrand | I discussed it | 17:26 |
| * zyga reads the rest | 17:26 | |
| jdstrand | path=/ peer=(label=unconfined) | 17:26 |
| zyga | jdstrand: I still don't get one thing: what is being leaked exactly? | 17:27 |
| jdstrand | zyga: ok, well, I may have stepped on your toes cause I restarted the travis-ci tests | 17:27 |
| zyga | jdstrand: hahe, no worries :) it will be OK | 17:27 |
| mup | PR snapd#3253 closed: cmd/snap-confine/spread-tests: discard useless --version test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3253> | 17:27 |
| mup | PR snapd#3266: interfaces: allow plugging DBus clients to introspect the slot service <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3266> | 17:27 |
| mup | PR snapd#3254: tests: re-enable and moderninze /media sharing test <Created by zyga> <https://github.com/snapcore/snapd/pull/3254> | 17:27 |
| jdstrand | zyga: imagine a system with ofono, avahi-observe and fwupd all as debs | 17:28 |
| zyga | ok | 17:28 |
| jdstrand | zyga: allowing path=/ peer=(label=unconfined) means you can introspect all three | 17:28 |
| zyga | ok | 17:28 |
| jdstrand | there is nothing in the rule making it service-specific | 17:29 |
| zyga | but is the introspection data sensitive? | 17:29 |
| jdstrand | /org/freedesktop/systemd1 <-- that is service specific | 17:29 |
| zyga | AFAIR it is just XML that describes what the API is | 17:29 |
| jdstrand | zyga: it's a leak. is it a huge major world-ending leak? no | 17:29 |
| zyga | well, hardly a leak, it just lets you know something is there in the first place, is that right? | 17:30 |
| jdstrand | zyga: but for example in the network-manager api you can enumerate things just by looking at the introspected data | 17:30 |
| * zyga tries to understand what is being exposed exactly, not how serious that is | 17:30 | |
| zyga | aha! | 17:30 |
| * zyga looks at dbus specs | 17:30 | |
| zyga | I wrote some dbus code earlier and I did implement introspection support | 17:30 |
| zyga | maybe I'm missing something | 17:30 |
| zyga | I just want to be sure I understand what is going on | 17:31 |
| jdstrand | zyga: it depends on the api too. yes, it lets you enumerate services that are installed (avahi, ofono, fwupd, others, ...) but the api can put info in there. eg, org.foo is fine by itself. you hot plug baz and bar and the foo service updates the api to have org.foo.bar and org.foo.baz | 17:31 |
| jdstrand | nm does this sort of thing | 17:32 |
| jdstrand | but, it is messy | 17:32 |
| jdstrand | we have some leaky things already, sure, but we are going to be trying to fix those leaks, so I strongly prefer to not add new ones | 17:32 |
| jdstrand | zyga: really what is going on is that I am only adding new accessing and not taking anything away | 17:33 |
| jdstrand | accesses* | 17:33 |
| jdstrand | and only adding ones that don't leak | 17:33 |
| jdstrand | if there is some super-critical use case for opening up more, we can perhaps reconsider | 17:34 |
| zyga | aha | 17:34 |
| zyga | jdstrand: you are correct | 17:35 |
| zyga | jdstrand: https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format | 17:35 |
| jdstrand | but sborokov mentioned a bug with pydbus and org.freedesktop.login1, and I'm fixing that and being safely proactive with everything else | 17:35 |
| zyga | jdstrand: the smoking-gun there is the full dump of what is there | 17:35 |
| zyga | jdstrand: object paths and what not | 17:35 |
| zyga | jdstrand: thanks for explaining that | 17:35 |
| jdstrand | np | 17:36 |
| zyga | jdstrand: btw, do you think we should open bugs on the projects that use / as the object path? | 17:36 |
| jdstrand | zyga: I thought about that. if it is a new service, yes. these ancient services we unfortuately can't cause clients would break | 17:37 |
| zyga | jdstrand: ah, right | 17:38 |
| zyga | well boo | 17:38 |
| zyga | :/ | 17:38 |
| jdstrand | yeah | 17:38 |
| jdstrand | good news is lennart is doing the right thing today (he (presumably) wrote the avahi dbus api, but the systemd object paths are clean) | 17:38 |
| zyga | jdstrand: I kind of wish someone made a dbus proxy with turing-complete processing built in | 17:38 |
| zyga | jdstrand: that would be secure to run in a separate tight sandbox (old-style seccomp) | 17:39 |
| * zyga EODs | 17:57 | |
| * zyga updates https://spread.zygoon.pl/images/ | 18:10 | |
| mup | PR snapd#3267 opened: cmd: make rst2man optional <Created by morphis> <https://github.com/snapcore/snapd/pull/3267> | 18:13 |
| === JanC is now known as Guest52042 | ||
| === JanC_ is now known as JanC | ||
| === DedSec is now known as Hyperion | ||
| === Hyperion is now known as Hyperion_ | ||
| === Hyperion_ is now known as DedSec | ||
| mup | PR snapd#3268 opened: Browser support sys devices <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3268> | 20:24 |
| mup | PR snapd#3261 closed: snap-confine: init the ENTRY variable, coverity is unhappy otherwise <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3261> | 20:34 |
| mup | PR snapd#2976 opened: support users and groups with seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2976> | 21:32 |
| mup | PR snapd#2976 closed: support users and groups with seccomp <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/2976> | 21:33 |
| fede2 | I'm getting a coredump on a snap for a python (pyqt5) application called URH (universal radio hacker) | 22:03 |
| fede2 | This is the snapcraft file https://github.com/fede2cr/snapcraft-sandbox/blob/master/limesdr-urh/snapcraft.yaml | 22:03 |
| fede2 | And I'm actually getting the same error as in this post https://askubuntu.com/questions/783758/pyqt-snap-builds-successful-fails-to-run | 22:03 |
| fede2 | I'm running on a freshly installed Ubuntu 16.04 with unity. | 22:04 |
| fede2 | Any suggestions? | 22:04 |
| === sgclark_sleeping is now known as sgclark | ||
| === mcphail_ is now known as mcphail | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!