| kyrofa | Anyone around here have any GPIO experience on raspberry pi 2? https://forum.snapcraft.io/t/raspberry-pi-2-missing-gpio-slot/2979 | 00:30 |
|---|---|---|
| ogra_ | sorry for sounding like a broken record kyrofa ... | 01:06 |
| kyrofa | ogra_, oh you're being super helpful, and I know this isn't on you :) | 01:07 |
| kyrofa | ogra_, but I... just can't believe it : | 01:07 |
| kyrofa | :P | 01:07 |
| ogra_ | kyrofa, well, seems niemeyer thinks it is safe ... so we'll see what happens | 01:10 |
| ogra_ | the answer sounds like a "soon" :) | 01:11 |
| niemeyer | ogra_: No, I don't just think it is safe.. I'm saying the specific reason for which these images were held back for a very long time was investigated and turned out to be a non-issue in practice, after actual verification of the specific differences between the old kernel and the new kernel... the kernel team agrees this is a good path to take. | 01:12 |
| ogra_ | niemeyer, well, it is not "old vs new kernel" but old dtb in the gadget with new kernel binary ... if the research showed that all HW works 100% in that constellation, thats fine indeed (though given that we changed config options for peripherials over time this surprises me) | 01:13 |
| ogra_ | (specifically the overlay dtbs ... and even more specifically the graphics stack (which is actually used by customers in production) ...) | 01:15 |
| ogra_ | (IIRC the kernel in stable did not even have the vc4 driver enabled so the dtb overlay will be missing or broken) | 01:16 |
| ogra_ | but i trust that you guys tested all this :) | 01:17 |
| niemeyer | ogra_: No, you actually don't.. this is called irony, and also passive aggressiveness. It's unhealthy when we work together with people. | 01:19 |
| ogra_ | niemeyer, i meant what i said ... sorry that you interpreted the smiley as irony, i was just trying to be firendly ... | 01:23 |
| niemeyer | ogra_: No, you really didn't. The fact you can't be honest to yourself about this is part of the issue. | 01:24 |
| ogra_ | niemeyer, well, i had different results when testing it myself, there are 98 overlay dtbs shipped in the gadget for addon HW along with the main dtb and there were many changes ... but i also fully trust paolos expertise if he says it is fine, he is definitely more expert than me ... i really dont try to be ironic oer anything | 01:33 |
| niemeyer | ogra_: We are not updating any of those dtbs.. We are updating the kernel. | 01:40 |
| ogra_ | err | 01:40 |
| niemeyer | ogra_: Yes, things can break, always, on any update. | 01:41 |
| niemeyer | ogra_: We'll do our best to keep things stable and working. | 01:41 |
| niemeyer | ogra_: And it's exactly for that sort of reason we have a release process. Anyone using Ubuntu Core and the kernel snap in real production environment *must* be testing it. | 01:41 |
| niemeyer | The release will go into beta, and into candidate, and then into stable. | 01:41 |
| mup | Issue snapcraft#1709 closed: Extract macaroon retrieval into more generic place <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1709> | 01:47 |
| mup | PR snapcraft#1765 closed: store: refactor acquirement of attenuated macaroon <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1765> | 01:47 |
| ogra_ | niemeyer, are your mongodb snapcraft.yamls anywhere public ? | 02:24 |
| ogra_ | ( i dont see a mongo repo under your GH account) | 02:24 |
| niemeyer | ogra_: Haven't been updated in a while, but haven't changed much either: | 02:24 |
| niemeyer | github.com/niemeyer/snaps | 02:25 |
| ogra_ | thanks ! | 02:25 |
| niemeyer | np | 02:25 |
| lundmar | anyone know if there is a plug interface available that allows access to NFS network mounted home directories? (the 'home' interface is apparently not sufficient). | 02:29 |
| lundmar | I can't seem to find anything useful in the docs regarding this. | 02:29 |
| lundmar | specificall I need to be able to write in a NFS network mounted home dir. | 02:30 |
| lundmar | +y | 02:30 |
| mup | Issue snapcraft#1752 closed: export the arch triplet variable during build time <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1752> | 02:32 |
| mup | PR snapcraft#1768 closed: project: export the arch triplet into the environment <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1768> | 02:32 |
| ogra_ | lundmar, https://forum.snapcraft.io/t/snaps-and-nfs-home/438 discussed this | 02:36 |
| mup | PR snapcraft#1557 closed: cleanbuild: add a --image option to build in a different image <Created by mwhudson> <Closed by mwhudson> <https://github.com/snapcore/snapcraft/pull/1557> | 02:47 |
| mup | PR snapcraft#1769 opened: lxd: add an --image argument to cleanbuild <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1769> | 02:47 |
| lundmar | ogra_: ok thanks. So it looks like NFS mounted home suppor is arriving in snap v2.29 | 03:01 |
| lundmar | support* | 03:01 |
| ogra_ | which should technically be released already | 03:01 |
| * ogra_ sees 2.29.3 in "snap version" | 03:02 | |
| lundmar | too bad many if the distributions running snapd are hopelessly behind in snapd version :/ | 03:02 |
| lundmar | of* | 03:02 |
| ogra_ | well, it will eventually dripple down into all of them | 03:03 |
| lundmar | true | 03:05 |
| ogra_ | (would be great if all of them would do re-exec like ubuntu does .... then it wouldnt really matter since snapd would com from the core snap) | 03:06 |
| lundmar | ogra_: oh, thats clear. So that way the old snapd process gets replaced by the new snapd. | 03:10 |
| ogra_ | yeah | 03:11 |
| ogra_ | and snapd does just update along with the core snap | 03:12 |
| ogra_ | so you dont need to wait for a distro package to be updated | 03:12 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#1770 opened: Add codespell support <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1770> | 03:26 |
| mup | PR snapcraft#1764 closed: snapcraft.yaml: use gcc to determine tuple <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1764> | 04:02 |
| mup | PR snapcraft#1771 opened: lxd: suppress traceback when lxc launch / init fails <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1771> | 04:08 |
| mup | PR snapcraft#1772 opened: Release changelog for 2.36 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1772> | 04:23 |
| sergiusens | snappy-m-o autopkgtest 1772 xenial:amd64 | 04:23 |
| snappy-m-o | sergiusens: I've just triggered your test. | 04:23 |
| ogra_ | grrr ... why is vt.handoff= not working right in core | 04:25 |
| * ogra_ wonders if thats subiquitys fault ... | 04:30 | |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mborzecki | morning | 06:05 |
| koza | mborzecki, hey | 06:21 |
| mup | PR snapd#4224 closed: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4224> | 07:01 |
| zyga-ubuntu | good morning | 07:04 |
| zyga-ubuntu | mvo: hey, what are your release / branch plans for today? | 07:06 |
| zyga-ubuntu | mvo: looking at the 2.30 tags we have a few branches still open | 07:06 |
| mborzecki | zyga-ubuntu: morning | 07:07 |
| zyga-ubuntu | hey :) | 07:07 |
| mborzecki | mvo: hey | 07:08 |
| mvo | zyga-ubuntu: hey, good morning. yeah, branch happens as soon as we get the blockers out of the way | 07:09 |
| mvo | mborzecki: hey, good morning | 07:09 |
| zyga-ubuntu | mvo: I recall pedronis said something about some blocker yesterday, is that already reflected in the list of PRs? | 07:09 |
| mborzecki | https://github.com/snapcore/snapd/commit/308c7ca6315a56fcc1028f3d9aeddb465c51c0d4 other distros should do the same I suppose? | 07:12 |
| mvo | zyga-ubuntu: yes, the list should be accurate | 07:12 |
| zyga-ubuntu | mborzecki: yeah, I was thinking about htat | 07:13 |
| zyga-ubuntu | mborzecki: idea | 07:13 |
| zyga-ubuntu | mborzecki: add a make install code to data | 07:13 |
| zyga-ubuntu | mborzecki: let that handle all mkdir's | 07:13 |
| zyga-ubuntu | mborzecki: and let that handle distro differences as well | 07:14 |
| zyga-ubuntu | mborzecki: then drop the random code from packaging that just creates those directories | 07:14 |
| zyga-ubuntu | mborzecki: then we have one place | 07:14 |
| zyga-ubuntu | mborzecki: and packaging will at most complain about unpackaged directories | 07:14 |
| zyga-ubuntu | mborzecki: +1/-1? | 07:14 |
| mborzecki | iirc you'll still have to list the directories, eg in rpm spec | 07:14 |
| zyga-ubuntu | mborzecki: yes but then you know when you messed up in packaigng | 07:15 |
| zyga-ubuntu | mborzecki: and the directories are the same in one central place | 07:15 |
| mborzecki | right | 07:15 |
| mborzecki | but yeah, sounds like a good idea | 07:15 |
| * zyga-ubuntu needs a review on 4315 | 07:16 | |
| mborzecki | on top of this, i'm not quite fond of data/ makefile taking some vars in command line while we pass those to cmd/ configur already | 07:17 |
| zyga-ubuntu | mborzecki: is configure setting any environment we can reuse? | 07:17 |
| zyga-ubuntu | mborzecki: anyway, I'm sure you can refactor it to be nicer :) | 07:17 |
| mborzecki | something to explore perhaps | 07:19 |
| mborzecki | where do we keep a backlog of things to explore/revisit? | 07:19 |
| zyga-ubuntu | mborzecki: on the forum | 07:20 |
| zyga-ubuntu | mborzecki: tag with your name and "backlog" | 07:20 |
| mborzecki | oh, ok | 07:20 |
| mborzecki | discourse ux is not what i expected it to be after hearing so many good things about | 07:23 |
| mborzecki | zyga-ubuntu: https://forum.snapcraft.io/t/2984 | 07:39 |
| * zyga-ubuntu looks | 07:40 | |
| mborzecki | at least there'd be no need to pass various *DIR settings to data/Makefile | 07:41 |
| haisheng | how should I package the base system(customized base ubuntu) to the snap ? I don't wamt to use the maintained Ubuntu one. any info about it can be provided ? Thanks. | 07:50 |
| zyga-ubuntu | haisheng: hello | 07:51 |
| zyga-ubuntu | haisheng: can you tell me more about what you mean | 07:52 |
| haisheng | I want to customize the base snap image. | 07:52 |
| haisheng | https://tutorials.ubuntu.com/tutorial/create-your-own-core-image#2 | 07:52 |
| zyga-ubuntu | haisheng: do you intend your base snap to be used for booting the system or just as a runtime for some apps? | 07:52 |
| haisheng | used for booting the system | 07:53 |
| zyga-ubuntu | mvo: ^ | 07:53 |
| haisheng | I am from china. And my english is not good. sorry for that. | 07:54 |
| zyga-ubuntu | haisheng: I think this is something we are still exploring/building but mvo is focusing on that more than I do | 07:54 |
| zyga-ubuntu | haisheng: no worries :) | 07:54 |
| zyga-ubuntu | haisheng: what kind of changes would you like to make to your base snap? | 07:55 |
| mvo | haisheng: hey, welcome! for now you can explore by just modifying the "core" snap. however very soon you will be able to make bootable base snaps. but right now the base snaps are not integrated into the boot process, so you can use base snaps today for applications but not yet to boot the system. but we are currently working on making this happen | 07:56 |
| haisheng | the ubuntu base snap has three snap at least. include a core snap and a kernel snap .and i want to customize that core snap and kernel snap. | 07:57 |
| haisheng | ok,thanks. show can i modify the "core" snap, and info can be provided for reference. | 08:02 |
| zyga-ubuntu | haisheng: can you describe the kind of changes you want to make? | 08:03 |
| haisheng | In fact, I just want to know how the roofs can be packaged the snap | 08:09 |
| haisheng | how base system can be packaged the snap | 08:09 |
| zyga-ubuntu | haisheng: ikey here is making use of base snaps for app runtimes; he builds a non-ubuntu based rootfs | 08:09 |
| zyga-ubuntu | haisheng: but he uses it for apps, not for booting the system | 08:10 |
| * ikey flicks into life | 08:10 | |
| zyga-ubuntu | (in his case the system is a classic distribution like ubuntu or solus) | 08:10 |
| ogra_ | mvo, proof of concept ... https://github.com/ogra1/pc-splash-gadget/commit/b8ea0f98fb5c3e5dfa40b7ed14a652a43a39458d (using split-initrd for showing a splash screen in a grub based image ... works great) | 08:14 |
| zyga-ubuntu | mborzecki: can you do a 2nd review on 4291 | 08:14 |
| zyga-ubuntu | mborzecki: this will help chipaca's other branch | 08:14 |
| mborzecki | ok, looking now | 08:14 |
| zyga-ubuntu | thank you | 08:15 |
| haisheng | ok , zyga-ubuntu, thanks. how can i customize the base snaps for app runtimes. any info about it can be provided. | 08:17 |
| zyga-ubuntu | haisheng: please look at the forum (forum.snapcraft.io), it's documented there | 08:17 |
| mvo | ogra_: aha, nice | 08:19 |
| ogra_ | so spit initrd for modules shouldnt be any prob either ... | 08:19 |
| ogra_ | *split | 08:19 |
| ogra_ | (testing it on grub was the remaining missing bit) | 08:20 |
| mborzecki | zyga-ubuntu: added comments to #4291, I'm not sure sure about SYS_GETUID and SYS_GETUID32, perhaps you can comment on this as well but it feels like something that should be looked at | 08:50 |
| mup | PR #4291: osutil/sys: reimplement getuid and chown with the right int type <Created by chipaca> <https://github.com/snapcore/snapd/pull/4291> | 08:50 |
| zyga-ubuntu | mborzecki: yeah, I thought about that when reviewing this and I assumed that the older syscall is just not exposed | 08:53 |
| zyga-ubuntu | mborzecki: but indeed worth checking | 08:53 |
| zyga-ubuntu | john is not around yet, it seems | 08:54 |
| mup | PR snapd#4161 closed: snapstate: add support for refresh.schedule=managed <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4161> | 08:55 |
| mborzecki | looks like Go uses SYS_GETUID32 on 32bit arches, https://github.com/golang/go/search?utf8=%E2%9C%93&q=SYS_GETUID32&type= | 08:56 |
| ikey | rewrite snapd in C when? | 09:00 |
| ikey | *runs* | 09:00 |
| ogra_ | pfft ... | 09:00 |
| ogra_ | shell ... C is boring | 09:01 |
| ikey | :O | 09:02 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | zyga-ubuntu: good catch on the GETUID32 thing! i shall now add a test and do penance | 09:07 |
| * Chipaca wonders if people will notice penance is actually just more coffee | 09:08 | |
| zyga-ubuntu | Chipaca: is it, I'm not sure if your syscall is wrong, I didn't check the number | 09:08 |
| Chipaca | zyga-ubuntu: yes | 09:09 |
| * ikey starts on libsoup/glib2/libxml2/glib-networking/gnutls/gobject powered "lightweight" snapd fork | 09:09 | |
| zyga-ubuntu | ikey: don't forget adding scheme "for scripting" | 09:10 |
| Chipaca | ikey: WAT | 09:10 |
| ikey | oh we could use libpeas | 09:10 |
| ikey | python plugins | 09:10 |
| zyga-ubuntu | no no, use guile | 09:10 |
| ikey | yeah i think you might be right there | 09:11 |
| ikey | >_> | 09:11 |
| Chipaca | am i missing context for this, or is it just too early? | 09:11 |
| Chipaca | i can go away and come back at noon | 09:11 |
| ikey | Chipaca, im just on a wind up | 09:12 |
| ikey | proposing the most offensive combination of technology possible :p | 09:12 |
| ikey | hm I *did* forget the bytecode VM .. | 09:12 |
| pedronis | mvo: hi, #4281 looks in a sane state to me, don't know if you want to wait for Gustavo to re-review | 09:19 |
| mup | PR #4281: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281> | 09:19 |
| pedronis | zyga-ubuntu: yes, it is in the list, #4310 | 09:20 |
| mup | PR #4310: many: allow to configure core before it is installed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4310> | 09:20 |
| zyga-ubuntu | pedronis: great, thank you for confirming | 09:20 |
| mborzecki | zyga-ubuntu: added some questions to #4315 | 09:22 |
| mup | PR #4315: cmd/snap-update-ns: add execWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315> | 09:22 |
| zyga-ubuntu | mborzecki: thank you | 09:22 |
| zyga-ubuntu | mborzecki: replied, thanks | 09:24 |
| zyga-ubuntu | ugh, more snow | 09:42 |
| pedronis | #4310 needs a 2nd review | 09:50 |
| mup | PR #4310: many: allow to configure core before it is installed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4310> | 09:50 |
| mup | Issue snapcraft#1773 opened: Please upgrade brew version <Created by fengerzh> <https://github.com/snapcore/snapcraft/issue/1773> | 09:51 |
| Chipaca | ok, i've got to go see the doc; bbl | 10:09 |
| === chihchun is now known as chihchun_afk | ||
| mvo | pedronis: re 4281> checking it now | 10:20 |
| pedronis | zyga-ubuntu: judging from the coverage report on one of my branches it seems the snap-update-ns are not deterministic I see random coverage changes there, and I haven't touched them | 10:32 |
| zyga-ubuntu | pedronis: let me look, probably sorting | 10:36 |
| zyga-ubuntu | pedronis: I cannot reproduce this | 10:47 |
| zyga-ubuntu | pedronis: I tried watch -n 1 -d "go test -cover -coverprofile=coverage.out && go tool cover -func=coverage.out" | 10:47 |
| zyga-ubuntu | pedronis: (in the cmd/snap-update-ns) directory | 10:47 |
| zyga-ubuntu | pedronis: and the only thing that varies slightly is time | 10:47 |
| zyga-ubuntu | pedronis: which commit are you on? | 10:47 |
| pedronis | ok, just weirdness then | 10:48 |
| * zyga-ubuntu -> tea | 11:18 | |
| mup | PR snapd#4316 opened: cmd/snap-mgmt: introduce snap-mgmt tool <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4316> | 11:21 |
| zyga-ubuntu | Chipaca: should "snap switch --devmode" be a thing? | 11:43 |
| Chipaca | zyga-ubuntu: only if snap switch --undevmode is a thig | 11:44 |
| zyga-ubuntu | Chipaca: snap switch --strict | 11:44 |
| zyga-ubuntu | I think there's no way to toggle devmode now | 11:45 |
| Chipaca | zyga-ubuntu: that is correct | 11:47 |
| Chipaca | i mean, it is a correct description | 11:47 |
| Chipaca | or a true statement | 11:47 |
| Chipaca | there, it's a true statement. | 11:47 |
| niemeyer | o/ | 11:52 |
| zyga-ubuntu | hey niemeyer | 11:56 |
| pdefreitas | which plug do I need to avoid this kind of denial: operation="capable" comm="snap-confine" capability=2 capname="dac_read_search" | 11:58 |
| zyga-ubuntu | pdefreitas: what did you do to get that error? | 12:00 |
| zyga-ubuntu | pdefreitas: snap-confine should never experience that | 12:00 |
| pdefreitas | snapping an electron app from a deb like the discord one available in snapcrafters github | 12:02 |
| zyga-ubuntu | pdefreitas: can you be more specific, this error can only happen at runtime, what did you run next? | 12:02 |
| pdefreitas | installed the app and when I ran it it crashed, checked the syslog and I got that | 12:03 |
| pdefreitas | running in devmode ofc | 12:03 |
| pedronis | on what kind of host? | 12:04 |
| pdefreitas | latest artful | 12:05 |
| pdefreitas | x64 | 12:05 |
| pedronis | niemeyer: hi | 12:13 |
| niemeyer | pedronis: Heya | 12:14 |
| pedronis | niemeyer: #4281 needs a re-review from you | 12:14 |
| mup | PR #4281: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281> | 12:14 |
| niemeyer | pedronis: Two trivials and LGTM, thanks for the ping | 12:19 |
| niemeyer | ahasenack: ping | 12:19 |
| ahasenack | niemeyer: hi | 12:19 |
| niemeyer | ahasenack: Heya! | 12:19 |
| niemeyer | ahasenack: Can I abuse your knowledge for a moment? :) | 12:19 |
| ahasenack | sure | 12:20 |
| niemeyer | ahasenack: It's about PAM.. | 12:20 |
| niemeyer | ahasenack: Is there: | 12:20 |
| niemeyer | 1. A standard protocol between PAM and its modules that doesn't involve linking with libpam | 12:20 |
| niemeyer | or, alternatively | 12:20 |
| niemeyer | 2. A standard module provided with most distributions that links with libpam and offers a more stable protocol that doesn't involve linking with libpam | 12:21 |
| niemeyer | ? | 12:21 |
| ahasenack | 1. I think not | 12:21 |
| ahasenack | the "conversation" happens within the libraries/modules | 12:21 |
| * mborzecki is away for half an hour | 12:21 | |
| niemeyer | mborzecki: / | 12:22 |
| niemeyer | o/ | 12:22 |
| mup | PR snapcraft#1774 opened: Push binary metadata to the Store <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/1774> | 12:22 |
| ahasenack | I haven't heard about 2 | 12:22 |
| niemeyer | ahasenack: Okay, thanks :( | 12:23 |
| niemeyer | ahasenack: I was hoping for some luck | 12:23 |
| ahasenack | tl;dr you want to benefit from existing pam modules but without linking with libpam? | 12:23 |
| niemeyer | ahasenack: Yeah, the key issue is ABI stability | 12:24 |
| niemeyer | ahasenack: Well, actually, not really | 12:24 |
| niemeyer | ahasenack: The thing I'd like to do is enable a typical libpam-linked application to use a stable ABI to authenticate | 12:25 |
| ahasenack | did you just encounter an abi breakage? | 12:25 |
| ahasenack | between xenial and xenial+N perhaps? | 12:25 |
| niemeyer | ahasenack: So *inside* the snap we need to offer something to that application that will answer auth questions | 12:25 |
| niemeyer | ahasenack: No.. I'm anticipating that there will definitely be ABI breakages and differences across snaps | 12:26 |
| ahasenack | ok | 12:26 |
| niemeyer | ahasenack: I'm surprised nobody did a "Hey, here is how to do a PAM module in shell!" kind of thing | 12:27 |
| niemeyer | ahasenack: Although that's arguably for the best ;P | 12:27 |
| ahasenack | I quickly searched for pam over dbus (!) | 12:27 |
| ahasenack | but what I found isn't that | 12:27 |
| niemeyer | ahasenack: I suspect that will find a huge amount of people doing the authentication part of it | 12:27 |
| niemeyer | ahasenack: Instead of the extension | 12:27 |
| ahasenack | or just the very simple bits of the authentication | 12:28 |
| niemeyer | ahasenack: Yeah, our problem is really not authenticating.. it's giving to a typical application that uses PAM something it can use | 12:28 |
| niemeyer | I mean, we'd then have to bridge it into the real modules, but that's easier | 12:28 |
| ahasenack | do you have some sort of pam interface in snaps? for snaps to use the host's pam? | 12:29 |
| niemeyer | ahasenack: Exactly :) | 12:30 |
| ahasenack | interesting | 12:30 |
| niemeyer | ahasenack: I'm figuring if we can do that at all | 12:31 |
| ahasenack | and I can see that breaking indeed | 12:31 |
| niemeyer | Without major pain, of course | 12:31 |
| ahasenack | you could tie it to pam in the core snap, but then the user db (for example) would have to live there, and that won't be practical | 12:31 |
| sborovkov | Hi! When did CA bundle was last updated for core? For some reason my browser on the core stopped opening google maps due to ssl handshake error. And initially it worked on some older snapd (from 2 months ago) | 12:32 |
| niemeyer | ahasenack: Not just that, but it implies every application in the world would use that same .so ABI | 12:34 |
| niemeyer | ahasenack: Which we know is a time bomb | 12:34 |
| ahasenack | yeah | 12:34 |
| ahasenack | you need some sort of pam broker | 12:34 |
| mup | Issue snapcraft#1773 closed: Please upgrade brew version <Created by fengerzh> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1773> | 12:37 |
| niemeyer | ahasenack: Thanks for those details | 12:40 |
| niemeyer | ahasenack: If you're interested: | 12:56 |
| niemeyer | https://forum.snapcraft.io/t/user-authentication-in-snapd/2915/4 | 12:56 |
| Chipaca | zyga-ubuntu: do you have an armhf board on core handy? | 12:57 |
| brunosfer | Hi guys, does anyone knows how can I override the GOGCCFLAGS for a crosscompilation of Go that imports C libs ? | 12:58 |
| ahasenack | niemeyer: good real world case | 12:59 |
| Chipaca | brunosfer: is it for -ldflags? | 12:59 |
| ahasenack | of course, it had to be about printers :) | 12:59 |
| niemeyer | ahasenack: :P | 13:00 |
| brunosfer | chipaca: yes, but when I do it through ubuntu artful it always loads the predefined flags and I can't move on. | 13:01 |
| Chipaca | brunosfer: is this for go inside snapcraft? | 13:02 |
| brunosfer | yep | 13:03 |
| Chipaca | ah | 13:03 |
| brunosfer | but first I want to make sure I can compile it, to move further with the snapcraft tool... | 13:03 |
| Chipaca | brunosfer: how are you trying to compile it? | 13:06 |
| brunosfer | I have a static lib in C inside my main.go file and I'm trying to build with: go build --ldflags '-extldflags "-static"' main.go | 13:08 |
| brunosfer | it works if I compile to my host platform amd64, but I want to compile for arm. | 13:09 |
| brunosfer | But I can open a topic on the forum, I think it's the best option, since it doesn't seem to exist a straight answer for that. | 13:10 |
| Chipaca | brunosfer: how are you compiling it for arm? | 13:14 |
| zyga-ubuntu | Chipaca: yes, sure | 13:22 |
| zyga-ubuntu | Chipaca: I can give you access in a moment | 13:22 |
| zyga-ubuntu | Chipaca: pi2 and dragon running core | 13:22 |
| Chipaca | zyga-ubuntu: thanks | 13:29 |
| pdefreitas | how can I get more detailed logging of which permissions is my snap failing in devmode? | 13:37 |
| pdefreitas | Is /var/log/syslog the only way to debug ? | 13:37 |
| cjwatson | sergiusens,elopio: Are there any constraints on when SNAPCRAFT_BUILD_INFO=1 produces a manifest file? I've tried a couple of noddy test snaps and I'm not getting one, so I'm wondering if I'm missing something | 13:38 |
| Chipaca | pdefreitas: snapd core team is in a meeting right now | 13:40 |
| sergiusens | cjwatson if this is a test, can you try using 2.35 (it is in xenial-proposed currently) | 13:45 |
| sergiusens | cjwatson but every build should produce at a minimum a manifest with the core attributes set (stage- and build-packages, host, kernel) and a give or take depending on the plugin (from the top of my head, parts using the python plugin are fully captured) | 13:47 |
| * sergiusens checks pending-sru | 13:48 | |
| cjwatson | Yeah, this is just me testing that my launchpad-buildd changes work. Let's see ... | 13:48 |
| cjwatson | sergiusens: No, I can't seem to get this to work. Do you have a known-good-with-this test snap I could try? | 13:53 |
| zyga-ubuntu | pdefreitas: we have a helper snap (snapd-debug) for that | 13:54 |
| cjwatson | sergiusens: Ah, never mind, I was just looking in the wrong place! Shows up in prime/snap/ but not in snap/, so that confused me slightly | 13:55 |
| pdefreitas | zuga-ubuntu: but that helper just don't watch /var/log/syslog | 13:57 |
| pdefreitas | *zyga-ubuntu | 13:57 |
| pdefreitas | it tails me to the same issue I reported lol | 14:01 |
| pdefreitas | just a syslog watcher | 14:02 |
| === chihchun_afk is now known as chihchun | ||
| zyga-ubuntu | mwhudson: can I use netplan to assign metric to my interfaces so that I can use pi3 over eth in preference to wifi | 14:04 |
| brunosfer | How can I install classic snap in ubuntu snappy core on RPi3 ? | 14:13 |
| brunosfer | I've tried sudo snap install --devmode classic but it doesn't recognize classic as a valid snap... | 14:14 |
| mvo | brunosfer: please try "sudo snap install --devmode --beta classic | 14:24 |
| brunosfer | mv: thank you very much, it worked perfectly. | 14:27 |
| brunosfer | mvo: thank you very much, it worked perfectly. | 14:27 |
| mvo | yw | 14:29 |
| brunosfer | btw, is there any gcc snap package for snappy core? | 14:31 |
| mup | PR snapd#4317 opened: tests: make interfaces-snapd-control-with-manage more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/4317> | 14:35 |
| Chipaca | lunch! | 14:39 |
| mup | PR snapd#4318 opened: snapstate: fix unkeyed fields error <Created by stolowski> <https://github.com/snapcore/snapd/pull/4318> | 14:45 |
| pstolowski | ^ guys, a really trivial fix | 14:45 |
| pedronis | pstolowski: I fear I had to add a couple comments on the last feedback changes in #4281 | 14:49 |
| mup | PR #4281: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281> | 14:49 |
| pedronis | Chipaca: sha512 doesn't seem interesting, we would need something cheaper | 14:50 |
| Chipaca | pedronis: crc32 ftw | 14:50 |
| pstolowski | pedronis, no worries & thanks | 14:52 |
| pedronis | pstolowski: thx | 14:53 |
| mborzecki | pedronis: sha256? din't know if that's any cheaper, there are hardware acceleration implementations of both sha256 and sha512 | 14:53 |
| mborzecki | even in golang | 14:54 |
| zyga-ubuntu | network failed | 14:54 |
| zyga-ubuntu | mvo: is it still expected not to be able to go from edge to candidate? | 14:54 |
| zyga-ubuntu | ah, linode is busy | 14:55 |
| zyga-ubuntu | jdstrand: hey | 14:55 |
| zyga-ubuntu | jdstrand: I have an exciting PR to review | 14:55 |
| cyphermox | zyga-ubuntu: mtu> you may be able to set routes: like in the very last example from the netplan manpage; there you can set a metric | 14:56 |
| zyga-ubuntu | cyphermox: looking! | 14:56 |
| zyga-ubuntu | cyphermox: thanks! | 14:56 |
| cyphermox | basically, a route to 0.0.0.0 via whatever your default gateway is, and a metric lower than whatever you already have otherwise | 14:57 |
| mborzecki | i recall a fosdem talk from one of the minio guys, they implemented sha256 in golang on armv8 and were basically beating xeon with avx2 | 14:57 |
| jdstrand | zyga-ubuntu: more exciting than 4315? | 14:57 |
| zyga-ubuntu | jdstrand: yes, https://github.com/snapcore/snapd/compare/master...zyga:fix/discard-stale-base-snap?expand=1 | 14:57 |
| zyga-ubuntu | jdstrand: I'll open it when there are more linode things available | 14:58 |
| jdstrand | ok | 14:58 |
| zyga-ubuntu | jdstrand: something mvo might include in 2.30 if you deem it safe | 14:58 |
| jdstrand | you've really been keeping me busy... | 14:59 |
| sborovkov | Hi, I built an image yesterday using ubuntu-image. It includes extra snaps. When I log in into that system and refresh snap from stable to candidate. On the next boot I get loaded into busy box as system is corrupt. (Rip) | 14:59 |
| sborovkov | (Raspberry pi not rip) | 14:59 |
| zyga-ubuntu | sborovkov: but rip is so appropriate here ;) | 15:01 |
| zyga-ubuntu | sborovkov: are those extra snaps a factor? | 15:01 |
| mvo | zyga-ubuntu: oh, stale mount namespace fix? that sounds sweet | 15:01 |
| mvo | zyga-ubuntu: re edge -> candiate - almost there, I think the fix landed last night | 15:02 |
| mvo | zyga-ubuntu: so the next core build in edge should be good again | 15:02 |
| zyga-ubuntu | mvo: aha, do we need the fix in candidate or just in edge? | 15:03 |
| sborovkov | zyga-ubuntu, I am not sure, I have older image that works fine. There I can update from the stable to candidate with no issues | 15:03 |
| sborovkov | But this one just died 3 times in a row after such update. I was thinking that it is faulty sd card first | 15:04 |
| lundmar | Hmm, the licens of my open source lxi-tools snap is listed a having a proprietary licens here: https://uappexplorer.com/snap/ubuntu/lxi-tools (?) | 15:05 |
| lundmar | as* | 15:05 |
| lundmar | anyone know what sets the license field? | 15:06 |
| mup | PR snapcraft#1772 closed: Release changelog for 2.36 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1772> | 15:07 |
| zyga-ubuntu | lundmar: maybe robert_ancell does? | 15:08 |
| brunosfer | Hi guys, does anyone knows how can I install gcc in ubuntu snappy core for RPi3? | 15:08 |
| zyga-ubuntu | brunosfer: hey, just install the "classic" snap | 15:09 |
| zyga-ubuntu | brunosfer: and then you can apt-get install your toolchains | 15:09 |
| mvo | zyga-ubuntu: just edge | 15:10 |
| brunosfer | zyga-ubuntu: I've alredy done that, however when I type apt-get update or any apt-get option, the system shows me the error "Ubuntu Core does not use apt-get, see 'snap --help'!" | 15:17 |
| === cachio is now known as cachio_lunch | ||
| mup | PR snapd#4319 opened: tests: add support for autopkgtests on s390x <Created by mvo5> <https://github.com/snapcore/snapd/pull/4319> | 15:24 |
| zyga-ubuntu | brunosfer: you must run "sudo classic" | 15:25 |
| brunosfer | zyga-ubuntu: Thanks, it worked ;) | 15:26 |
| zyga-ubuntu | cool, cheers :) | 15:29 |
| * zyga-ubuntu -> coffee | 15:29 | |
| niemeyer | mvo, zyga-ubuntu: Did we get rid of the outdated snap-confine apparmor profiles for good? | 15:31 |
| niemeyer | Sorry, let me fix the phrase | 15:31 |
| niemeyer | mvo, zyga-ubuntu: Did we get rid of the issue regarding outdated snap-confine apparmor profiles for good? | 15:31 |
| niemeyer | mvo: Just wondering as otherwise #4312 will bite us due to a new snap-confine trying to create a directory it doesn't have access to | 15:32 |
| mup | PR #4312: snap-confine: create mount target for lib32,vulkan on demand <Created by mvo5> <https://github.com/snapcore/snapd/pull/4312> | 15:32 |
| niemeyer | pedronis: Question on #4310 | 15:51 |
| mup | PR #4310: many: allow to configure core before it is installed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4310> | 15:51 |
| zyga-ubuntu | hmmmm | 15:53 |
| * zyga-ubuntu wonders why unsquashfs chowns files to test:test | 15:53 | |
| zyga-ubuntu | drwxr-xr-x 24 test test 4096 Nov 29 05:22 squashfs-root | 15:54 |
| zyga-ubuntu | and this runs as root | 15:54 |
| pedronis | niemeyer: answered, I agree maybe we need a different name, a bit unsure what to use though | 15:54 |
| zyga-ubuntu | omg | 15:54 |
| zyga-ubuntu | acutally | 15:54 |
| zyga-ubuntu | the core snap is owned by test.test!!! | 15:55 |
| * zyga-ubuntu runs -shell-before | 15:55 | |
| zyga-ubuntu | (as in, files inside are test.test) | 15:55 |
| === cachio_lunch is now known as cachio | ||
| zyga-ubuntu | cachio: ^ | 16:08 |
| zyga-ubuntu | my box is busy building a fresh image for inspection | 16:08 |
| zyga-ubuntu | cachio: I found that, for some reason, files in the core snap were not owned by root but instead by 12345 | 16:08 |
| mup | PR snapd#4312 closed: snap-confine: create mount target for lib32,vulkan on demand <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4312> | 16:09 |
| zyga-ubuntu | mvo: hey | 16:12 |
| zyga-ubuntu | mvo: drwxr-xr-x 2 test test 1937 Nov 29 05:22 bin | 16:13 |
| mvo | zyga-ubuntu: uh, where? | 16:13 |
| zyga-ubuntu | spread -v -shell-before qemu:ubuntu-16.04-64:tests/main | 16:13 |
| zyga-ubuntu | mvo: my test cannot have caused that, I'm trying master now | 16:14 |
| zyga-ubuntu | mvo: (this is most unexpected) | 16:15 |
| zyga-ubuntu | mvo: I'll look at project-prepare | 16:15 |
| mvo | zyga-ubuntu: could be a bug in the setup | 16:15 |
| mvo | zyga-ubuntu: worth fixing but not omg in my book just yet :) | 16:15 |
| mvo | zyga-ubuntu: thanks for tracking it down though | 16:15 |
| zyga-ubuntu | mvo: looks like create_test_user does something weird | 16:15 |
| mvo | zyga-ubuntu: still curious given that we install it from a deb that should have sane permissions | 16:15 |
| zyga-ubuntu | mvo: I was OMG for a second, assuming it's in edge | 16:16 |
| zyga-ubuntu | chown test.test -R .. | 16:16 |
| zyga-ubuntu | this is what we do | 16:16 |
| brunosfer | zyga-ubuntu: I just installed gcc toolchain with classic on ubuntu snappy core on RPi3 however I can't find it anywhere, /usr/bin, /usr/sbin... Do you have any idea? | 16:16 |
| mvo | zyga-ubuntu: oh, right, that would have been a OMG moment for sure :) | 16:16 |
| zyga-ubuntu | brunosfer: in the same shell you installed them in | 16:17 |
| zyga-ubuntu | brunosfer: you need to sudo classic | 16:17 |
| zyga-ubuntu | brunosfer: those are not available outside | 16:17 |
| cachio | zyga-ubuntu, can I help on this? | 16:17 |
| pdefreitas | how can I debug plugs needed? | 16:17 |
| zyga-ubuntu | cachio: yes, perhaps, do you remember what's the purpose of that chown? | 16:19 |
| zyga-ubuntu | pdefreitas: can you please ask a more specific question? | 16:19 |
| zyga-ubuntu | cachio: should that just be chown test.test -R "$SPREAD_PATH" | 16:20 |
| niemeyer | pedronis: The problem with having a flags option is that we cannot import configstate from snapstate due to the cycle | 16:20 |
| niemeyer | pedronis: and "true" wouldn't improve the situation much | 16:20 |
| niemeyer | pedronis: How about Configure and ConfigureTasks | 16:20 |
| pedronis | that works for me | 16:20 |
| niemeyer | pedronis: Or Task? (is it one) | 16:21 |
| niemeyer | Ah, no Tasks, since it's a set | 16:21 |
| pedronis | that works too | 16:21 |
| pdefreitas | zyga-ubuntu: I'm working in porting a electron app, just for learning purposes, so I have a binary, I have no idea which system APIs it may use. When I run the devmode it gives me an access denied in snap-confine... No clue what it is trying to that that violates since it just crashes after that (sig fault) | 16:21 |
| pedronis | it would be similar to other methods | 16:21 |
| niemeyer | pedronis: Okay, so let's please rename the var inside snapstate too, so it's ConfigureTasks | 16:21 |
| niemeyer | pedronis: So it doesn't feel like we're calling the wrong thing | 16:21 |
| zyga-ubuntu | pdefreitas: not sure, can you please open a thread about this, if you include the snap or snapcraft instructions on how to build it people can try and debug | 16:22 |
| niemeyer | pedronis: It's not 100% ideal since both of them returns tasks, but I cannot come up with anything better either.. they are doing the same thing.. it's just that one is checked and the other is not | 16:23 |
| pedronis | yea | 16:23 |
| niemeyer | pedronis: We might say ConfigureInstalled for the first one, but then core is an exception | 16:23 |
| cachio | zyga-ubuntu, mmm I dont remember | 16:23 |
| cachio | zyga-ubuntu, let me check the code | 16:23 |
| niemeyer | pedronis: Perhaps that's better? We can live with the exception.. | 16:23 |
| pedronis | niemeyer: I was looking at other things similar, we have: | 16:23 |
| niemeyer | pedronis: At least the name makes more clear why we have both | 16:24 |
| pedronis | snapstate.SetupInstallHook = SetupInstallHook | 16:24 |
| zyga-ubuntu | cachio: I'll let you know what I find | 16:24 |
| pedronis | so that would make SetupConfigureHook ? seems a bit verbose though | 16:24 |
| pedronis | also those return a single *state.Task | 16:25 |
| niemeyer | pedronis: Hmm | 16:26 |
| niemeyer | pedronis: We'd still have the same issue I guess | 16:26 |
| pedronis | ? | 16:26 |
| pedronis | I mean have Configure and SetupConfigureHook | 16:26 |
| niemeyer | pedronis: In the sense we need a delta between the two names so we can tell why we have two names | 16:27 |
| niemeyer | pedronis: They are both setting up the configure hook :) | 16:27 |
| niemeyer | pedronis: I suggest going with something close to your suggestion | 16:27 |
| niemeyer | pedronis: ConfigureInstalled and Configure | 16:27 |
| pedronis | ConfigureInstalled is the one that checks? | 16:28 |
| niemeyer | pedronis: The first one is a lie in the case of "core", but at least we know exactly why we have the two, and it's clear what's going on when we call one of them | 16:28 |
| pedronis | ok | 16:28 |
| niemeyer | pedronis: Yeah.. also makes for a smaller delta on the PR, which is a small win | 16:28 |
| zyga-ubuntu | cachio, mvo: https://github.com/snapcore/snapd/compare/master...zyga:fix/overzealous-chown-in-spread?expand=1 | 16:28 |
| zyga-ubuntu | can you please comment before I open the PR, I don't want to waste spread time | 16:28 |
| pedronis | niemeyer: let me take a short break, and then make that change | 16:28 |
| niemeyer | pedronis: Thanks! | 16:28 |
| zyga-ubuntu | mvo: I see you play with fire | 16:29 |
| zyga-ubuntu | mvo: s390x :) | 16:29 |
| lundmar | Hi. I assume I'm following the correct procedure when I make this request? https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976 | 16:29 |
| mvo | zyga-ubuntu: haha | 16:30 |
| cachio | zyga-ubuntu, nice catch | 16:30 |
| mup | PR snapd#4320 opened: tests: don't chown the whole world to test.test <Created by zyga> <https://github.com/snapcore/snapd/pull/4320> | 16:31 |
| cachio | zyga-ubuntu, the change makes sense for me | 16:31 |
| mup | PR snapd#4321 opened: configmgr: simplify ConfigManager <Created by mvo5> <https://github.com/snapcore/snapd/pull/4321> | 16:33 |
| kyrofa | jdstrand, how would you feel about an interface that allows access to /dev/gpiomem? Context: https://forum.snapcraft.io/t/raspberry-pi-2-denials-using-rpi-gpio/2982/4 | 16:33 |
| zyga-ubuntu | mvo: I assume the s390x PR is for 2.30 | 16:37 |
| * sergiusens heads out to physiotherapy | 16:38 | |
| mvo | zyga-ubuntu: its not strictly needed but would be nice | 16:39 |
| mvo | zyga-ubuntu: there are three open ones right now, two are musts so we can still pull targets of opportunity in but if it does not make it I will not shed a tear, it will be in .31 | 16:39 |
| mup | PR snapd#4318 closed: devicestate: fix unkeyed fields error <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4318> | 16:42 |
| zyga-ubuntu | mvo: I think we are SOM - so out of machines | 16:45 |
| mvo | zyga-ubuntu: we are, but also quite advanced | 16:46 |
| zyga-ubuntu | :) | 16:47 |
| zyga-ubuntu | mvo: look at 4317 please | 16:48 |
| brunosfer | zyga-ubuntu: I'm trying to set the CC variable in "go env" to include C libs inside a go file and I can't set it with "classic gcc"? Is there another way to set the gcc path in the go env variables? | 16:48 |
| zyga-ubuntu | brunosfer: classic is like "ssh into this box as classic" | 16:49 |
| zyga-ubuntu | brunosfer: just build your stuff inside classic | 16:49 |
| zyga-ubuntu | brunosfer: once you are in the classic shell you can do whatever you want | 16:49 |
| zyga-ubuntu | brunosfer: don't try to run classic tools from the core system to build things | 16:49 |
| brunosfer | zyga-ubuntu: I'll look for that, thanks ;) | 16:49 |
| zyga-ubuntu | brunosfer: also note that the filesystem is different | 16:50 |
| zyga-ubuntu | brunosfer: after you sudo classic only /home and a few other places are the same as before | 16:50 |
| zyga-ubuntu | brunosfer: most of /usr is different | 16:50 |
| zyga-ubuntu | mvo: I wonder what it would take to shellcheck our spread scripts | 16:50 |
| === lamont` is now known as lamont | ||
| mvo | zyga-ubuntu: ta | 16:50 |
| zyga-ubuntu | mvo: I think it would be very useful | 16:50 |
| mvo | zyga-ubuntu: +10 | 16:50 |
| mvo | or even +100 | 16:50 |
| zyga-ubuntu | mvo: I can look into that tomorrow | 16:51 |
| zyga-ubuntu | mvo: maybe something as simple as "spread -shellcheck" | 16:51 |
| brunosfer | zyga-ubuntu: Yeah, It's everything new for me, so I'm still getting acquainted to this paradigm shift. Thanks for the support ;) | 16:51 |
| zyga-ubuntu | brunosfer: sure, it's a brave new world :) | 16:51 |
| === chihchun is now known as chihchun_afk | ||
| zyga-ubuntu | brunosfer: note that you can build stuff with snapcraft | 16:51 |
| zyga-ubuntu | brunosfer: and snapcraft does a lot of magic heavy lifting | 16:51 |
| zyga-ubuntu | (and makes snaps :) | 16:52 |
| brunosfer | zyga-ubuntu: Yeah, that's my final goal. However I do have to understand the process first. Full hands on ;) | 16:53 |
| niemeyer | Just got mail with the subject "Remote Work: The Complete Guide" | 16:55 |
| niemeyer | Finally someone will explain to me how this thing works.. :P | 16:56 |
| mvo | haha | 16:56 |
| kyrofa | niemeyer, haha, from trello? | 16:57 |
| niemeyer | Yeah :) | 16:57 |
| kyrofa | Pretty sure they need "insider advice" from US | 16:57 |
| * zyga-ubuntu doesn't believe any such guide unless it starts with "step one, get dressed" | 16:59 | |
| niemeyer | "step two, go back to step one.. we didn't mean pijamas" | 17:00 |
| zyga-ubuntu | hmm | 17:00 |
| zyga-ubuntu | hahaha | 17:00 |
| pedronis | niemeyer: pushed changes to #4310 | 17:00 |
| mup | PR #4310: many: allow to configure core before it is installed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4310> | 17:00 |
| kyrofa | Crap... /me goes back to step 1 | 17:00 |
| niemeyer | pedronis: That was all, LGTM otherwise | 17:00 |
| niemeyer | Oops.. meeting | 17:01 |
| niemeyer | Still trying to figure the algorithm for hangouts to decide whether you need to click join or not. | 17:02 |
| mup | PR snapd#4322 opened: corecfg: rename package to overlord/configstate/configcore <Created by mvo5> <https://github.com/snapcore/snapd/pull/4322> | 17:03 |
| niemeyer | I thought it was number of people, but it just got me through to a meeting with 4 people with no questions | 17:04 |
| mvo | reviews for https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.30 would be appreciated | 17:04 |
| mvo | well, I think the first has two already | 17:05 |
| mvo | and 4281 probably just need a final review from niemeyer | 17:05 |
| niemeyer | mvo: It's got my +1 already, and I'm half way through default-provider | 17:06 |
| pedronis | mvo: no, first two just need to get green | 17:06 |
| pedronis | now | 17:06 |
| === Guest21343 is now known as jero- | ||
| m4sk1n | hi | 17:26 |
| m4sk1n | `/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /snap/otter-browser/x1/lib/x86_64-linux-gnu/libsystemd.so.0)` when trying to run my snap | 17:26 |
| m4sk1n | lubuntu 17.10, up-to-date | 17:26 |
| zyga-ubuntu | m4sk1n: is that snap using classic confinement? | 17:27 |
| m4sk1n | no | 17:27 |
| m4sk1n | devmode | 17:27 |
| zyga-ubuntu | m4sk1n: how did you build it? | 17:28 |
| m4sk1n | how “how”? | 17:28 |
| m4sk1n | cmake | 17:33 |
| zyga-ubuntu | m4sk1n: did you use snapcraft? | 17:38 |
| zyga-ubuntu | m4sk1n: snapcraft ensures that the right toolchain is used | 17:39 |
| m4sk1n | yes | 17:39 |
| zyga-ubuntu | m4sk1n: matching what is in the base snap at runtime | 17:39 |
| zyga-ubuntu | m4sk1n: if this was with snapcraft then I guess that kyrofa wants to know | 17:39 |
| zyga-ubuntu | m4sk1n: if it's not a secret, can you please open a forum thread and share your snapcraft.yaml source? | 17:39 |
| m4sk1n | i tried to test my snap on the same pc that i used to build it | 17:39 |
| kyrofa | m4sk1n, you need to build your snap on Xenial, or with cleanbuild | 17:39 |
| m4sk1n | (on the same os) | 17:40 |
| kyrofa | You're building against a libc that is too new | 17:40 |
| kyrofa | When you run your snap, it runs against the libc in the core snap, which is based on xenial | 17:40 |
| m4sk1n | I understand | 17:40 |
| zyga-ubuntu | kyrofa: ah, I would have assumed snapcraft would not allow that | 17:40 |
| kyrofa | zyga-ubuntu, how could it not? | 17:41 |
| zyga-ubuntu | kyrofa: you could read /etc/os-release | 17:41 |
| m4sk1n | what's the easiest way? `classic`? | 17:41 |
| kyrofa | zyga-ubuntu, just bail on newer releases? | 17:41 |
| zyga-ubuntu | kyrofa: and say "OMG dude, cleanbuild" | 17:41 |
| kyrofa | Hahaha | 17:41 |
| zyga-ubuntu | kyrofa: well, this or build useless snaps that don't work? | 17:41 |
| kyrofa | Yeah perhaps so | 17:41 |
| kyrofa | Indeed | 17:42 |
| kyrofa | m4sk1n, the best way to build on xenial when you're running a newer release is to use a container. Are you familiar with LXD? | 17:42 |
| m4sk1n | no, but it's a good moment to start… | 17:43 |
| ikey | btw when reading os-release you should do so in a cascading order | 17:43 |
| zyga-ubuntu | ikey: ? | 17:43 |
| ikey | [/etc/os-release, /usr/lib/os-release, /run/os-release] | 17:43 |
| zyga-ubuntu | ikey: ah, that | 17:44 |
| kyrofa | ikey, that's good to know actually. We don't do that today | 17:44 |
| zyga-ubuntu | kyrofa: this is in the manual page AFAIK | 17:44 |
| ikey | aye just future++ cruft | 17:44 |
| zyga-ubuntu | haha | 17:44 |
| zyga-ubuntu | I just did "man ikey" | 17:44 |
| zyga-ubuntu | wanting to do man os-release | 17:44 |
| zyga-ubuntu | we should do this | 17:44 |
| ikey | lulz | 17:44 |
| zyga-ubuntu | manual pages for people | 17:44 |
| ikey | man: ENOMAN | 17:44 |
| zyga-ubuntu | the package could be called | 17:44 |
| kyrofa | m4sk1n, it's pretty easy. Are you familiar with containers in general? e.g. docker? | 17:45 |
| zyga-ubuntu | manpages-devs (vs -dev) ;) | 17:45 |
| ikey | hah | 17:45 |
| * zyga-ubuntu writes ikey's manual page | 17:45 | |
| Chipaca | zyga-ubuntu: like netscape's old about:<dev> thing | 17:45 |
| ikey | this is like a nerd dream come true | 17:45 |
| m4sk1n | yup | 17:45 |
| ikey | my biography, in groff | 17:45 |
| zyga-ubuntu | Chipaca: I never heard about that but I'm curious now :) | 17:45 |
| zyga-ubuntu | hahaha | 17:45 |
| zyga-ubuntu | ikey: just wait for it | 17:45 |
| zyga-ubuntu | patches welcome | 17:45 |
| zyga-ubuntu | crazy ideas that should be made | 17:45 |
| ikey | 80 columns of goodness | 17:45 |
| Chipaca | zyga-ubuntu: https://www.jwz.org/doc/about-jwz.html | 17:45 |
| Chipaca | zyga-ubuntu: maybe instead of 'man ikey' we want 'tldr ikey' | 17:49 |
| Chipaca | or just apropos ikey | 17:49 |
| ikey | nah, whatis has the right idea | 17:49 |
| ikey | whatis ikey | 17:49 |
| ikey | ikey: nothing appropriate. | 17:49 |
| Chipaca | finger ikey | 17:49 |
| Chipaca | … nobody runs fingerd any more | 17:49 |
| ikey | might wanna buy a drink first | 17:50 |
| Chipaca | :-) | 17:50 |
| mup | PR snapcraft#1770 closed: Add codespell support <Created by daniellim2000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1770> | 17:50 |
| ikey | I once wrote a fingerd in java | 17:50 |
| ikey | because freenode was bugging me with the ~ | 17:50 |
| Chipaca | remind me not to upset you | 17:51 |
| ikey | lol | 17:51 |
| zyga-ubuntu | ikey: in java? | 17:52 |
| zyga-ubuntu | ikey: oh man | 17:52 |
| ikey | ikr? | 17:52 |
| zyga-ubuntu | shall I include this shameful fact in your manual page? | 17:52 |
| zyga-ubuntu | ;D | 17:52 |
| ikey | pre nio | 17:52 |
| ikey | lol | 17:52 |
| ikey | my manpage would probably be included with the insults portion of fortune | 17:53 |
| jdstrand | kyrofa: I don't know anything about gpiomem otoh. I would need to look into it | 17:54 |
| pedronis | mvo: btw, in principle do we still need core-support (the interface) now that we don't have a configure hook in core anymore? | 18:01 |
| kyrofa | jdstrand, would you mind putting that on your list? sysfs is deprecated, is slow, and doesn't support everything. It's actually hard to find rpi docs that don't use /dev/mem or /dev/gpiomem | 18:04 |
| jdstrand | kyrofa: it is already on my list | 18:04 |
| kyrofa | jdstrand, excellent, thank you :) . I'd happily contribute the interface if you think it deserves to be there | 18:05 |
| kyrofa | Until then, /me starts on on a soft PWM using sysfs. /me cries | 18:05 |
| jdstrand | kyrofa: on the face of it, having gpiomem access in a 'gpiomem' interface is not contentious. the question is, what does that allow? do gpio devices show up in /dev after using it? if so, how does that interact with the device cgroup? if not, what other accesses are needed? | 18:05 |
| jdstrand | kyrofa: or maybe we have a gpio-raw interface that is analgous to usb-raw | 18:06 |
| pedronis | mvo: I have a question about your 2.30 open PR, left it in it | 18:06 |
| jdstrand | where everything is allowed | 18:06 |
| jdstrand | I'm not suggesting that, cause the usb-raw interface only exists as astop gab for dynamic hotplug and isn't really the type of interface we like to have | 18:07 |
| kyrofa | jdstrand, both approaches seem reasonable, but I suspect... yes exactly | 18:07 |
| jdstrand | as a stop gap* | 18:07 |
| kyrofa | I want to be able to respond favorably to automatic connection requests if possible | 18:07 |
| kyrofa | It may not be. As you say, we don't know much about this | 18:08 |
| jdstrand | kyrofa: since I don't know gpio well, and you have experience (and hardware) with it, perhaps you could play with gpiomem in strict mode. add /dev/gpiomem to the apparmor profile and then see what else pops out | 18:08 |
| kyrofa | jdstrand, doing now | 18:09 |
| jdstrand | if it is just gpiomem, then having a gpiomem or gpiomem-control implicit core interface seems quite fine | 18:09 |
| kyrofa | jdstrand, also happy to give SSH access if you want to poke about | 18:09 |
| jdstrand | kyrofa: that could work if you tell me the commands to use. eg, if you have a devmode snap that is representative of gpiomem use, I could put it in strict mode and run the commands that exercise the snap | 18:11 |
| kyrofa | jdstrand, I have a strict one, indeed. Totally up to you, not sure what your schedule looks like | 18:12 |
| * zyga-ubuntu started https://github.com/zyga/manpages-devs | 18:12 | |
| jdstrand | kyrofa: what priority is this? there is a lot of stuff that is high priority atm. I really need to get to the mir issue for greyback | 18:13 |
| kyrofa | jdstrand, high for me, but I would not presume to suggest priorities for you! Why don't I play with it and see what I can turn up, maybe I can iron things out | 18:15 |
| kyrofa | If you're available for a few questions along the way, I bet we can make things work | 18:17 |
| zyga-ubuntu | kyrofa: just make the interface | 18:19 |
| zyga-ubuntu | kyrofa: it should be easy | 18:19 |
| jdstrand | kyrofa: that would be excellent. if your snap ends up with a device cgroup, then you can add the device to the cgroup by doing: echo 'c <major>:<minor> rwm' > /sys/fs/cgroup/devices/snap.name.command/devices.allow | 18:19 |
| zyga-ubuntu | kyrofa: and then you can play with it | 18:19 |
| zyga-ubuntu | kyrofa: and jdstrand can review it once it's ready | 18:19 |
| zyga-ubuntu | kyrofa: it should be a no-brainer nowadays | 18:19 |
| jdstrand | kyrofa: alternatively, see https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 for stuff with device cgroups | 18:19 |
| kyrofa | zyga-ubuntu, right, that's my plan. Just want to make sure we understand what we're getting into with it | 18:19 |
| kyrofa | zyga-ubuntu, I've made a few nowadays | 18:20 |
| zyga-ubuntu | kyrofa: :) | 18:20 |
| jdstrand | kyrofa: note, if echoing into sysfs, use snap run --shell snap.name.command, then in another terminal do the echo, then in the snap shell, run your commands | 18:20 |
| * jdstrand is curious what 'udevadm info /dev/gpiomem' does | 18:22 | |
| jdstrand | kyrofa: ^ | 18:22 |
| zyga-ubuntu | jdstrand: FYI, I have a pi3 and dragonboard available over ssh if you want | 18:22 |
| zyga-ubuntu | jdstrand: http://pastebin.ubuntu.com/26073757/ | 18:23 |
| jdstrand | zyga-ubuntu: I have a dragonboard, but it doesn't have /dev/gpiomem | 18:23 |
| kyrofa | jdstrand, from outside of the snap? https://pastebin.ubuntu.com/26073768/ | 18:23 |
| zyga-ubuntu | jdstrand: just saying, available 24/7 :) | 18:24 |
| jdstrand | zyga-ubuntu (cc kyrofa): ok good, it is udev taggable | 18:24 |
| zyga-ubuntu | jdstrand: yep, that's a good call to check this :) | 18:25 |
| jdstrand | depending on what it does, /dev/gpiomem and some sysfs entries may be sufficient. it really depends on how pin access works now | 18:25 |
| jdstrand | do they magically pop up in /dev, are they virtual devices (eg, like tun/tap), etc | 18:26 |
| jdstrand | I actually have an rpi2. I just don't have things plugged into pins, etc, etc | 18:26 |
| kyrofa | jdstrand, it's just memory mapped | 18:27 |
| kyrofa | jdstrand, take a look here: http://paste.ubuntu.com/26073822/ | 18:28 |
| mvo | pedronis: I noticed it, I ponder a bit and will reply, probably in my morning, will EOD soon | 18:28 |
| kyrofa | This is part of the python lib I'm using | 18:28 |
| jdstrand | kyrofa: that is my undersatnding, but lets see what blackbox testing reveals :) | 18:28 |
| kyrofa | jdstrand, oops, too late, it's gray box now | 18:28 |
| kyrofa | jdstrand, adding /dev/gpiomem rw, works | 18:32 |
| mup | PR snapcraft#1775 opened: Add --help command for the runtests.sh script <Created by m4sk1n> <https://github.com/snapcore/snapcraft/pull/1775> | 18:32 |
| zyga-ubuntu | m4sk1n: whee, thanks! | 18:33 |
| ikey | q: when is 2.30 gonna drop? | 18:33 |
| ikey | think ill do my call for testing on LSI when 2.30 is generally available | 18:33 |
| jdstrand | kyrofa: ok, that's great. I then suggest sending up an interface for it. happy to review it. please remember the udev backend. you'll need to figure out what to add. I suggest looking at interfaces/builtin/physical_memory_control.go and seeing if you can just use it as a template | 18:35 |
| zyga-ubuntu | kyrofa: you should all good with just common interface nowadays | 18:36 |
| jdstrand | physical-memory-control uses 'common' | 18:36 |
| popey | jdstrand: i have a command line application which needs xdg-open. Do I really have to add 'desktop' or 'unity7' plugs? Won't that complain about a missing desktop file? | 18:36 |
| popey | Or is it either/or, just ship xdg-open and no extra plugs? | 18:37 |
| zyga-ubuntu | popey: don't ship xdg-open :) | 18:37 |
| popey | snappy-debug.security tells me to! | 18:37 |
| zyga-ubuntu | jdstrand: ^ | 18:37 |
| jdstrand | note that snappy-debug is not the sharpest tool in the shed. I can add an exception for xdg-open to not recommend shipping it | 18:38 |
| kyrofa | jdstrand, say someone requests an interface auto-connection. Would you be more likely to grant gpiomem than physical-memory-control? | 18:39 |
| jdstrand | popey: but today, you need desktop or unity7, yes. you can add a forum topic describing your use case and why it should be allowed by default | 18:40 |
| popey | ok, will do | 18:40 |
| popey | thanks! | 18:40 |
| jdstrand | np | 18:40 |
| jdstrand | kyrofa: gpiomem is a more specific interface so if the snap is something that clearly needs access to gpio pins, then sure, that would be a candidate for auto-connection as much as a snap that needs access to a specific pin | 18:41 |
| kyrofa | jdstrand, okay excellent. This will be the first interface I've done that has any udev component, so I'll take a closer look at that now | 18:42 |
| jdstrand | kyrofa: hopefully using physical-memory-control as a template will make that easy (eg, KERNEL=="gpiomem") | 18:43 |
| jdstrand | kyrofa: you can test that out for yourself on the live system without a new snapd if you look at https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 | 18:44 |
| kyrofa | jdstrand, similar to physical-memory-*, think it's worth adding gpiomem-observe as well as control? | 18:44 |
| jdstrand | kyrofa: will anyone just need read access? | 18:44 |
| kyrofa | jdstrand, I... doubt it | 18:45 |
| kyrofa | And I'm uncertain how that would work given the memory mapping needed | 18:45 |
| jdstrand | kyrofa: you could name it gpiomem-control but just not add gpiomem-observe to leave the option for the future | 18:45 |
| kyrofa | Good call | 18:45 |
| zyga-ubuntu | travis is starving us | 18:46 |
| zyga-ubuntu | man, it wants me to say "EOD man" | 18:46 |
| zyga-ubuntu | I just want to see my fix work in practice | 18:46 |
| jdstrand | kyrofa: is there anything special about python3-coverage that would cause it to not be installed if in build-packages? | 18:54 |
| kyrofa | jdstrand, not that I know of. Any chance it's already installed? | 18:55 |
| kyrofa | Or is this a cleanbuild? | 18:55 |
| jdstrand | it is already installe | 18:55 |
| jdstrand | d | 18:55 |
| jdstrand | Building review-tools | 18:56 |
| jdstrand | python3 -m coverage run ./run-tests | 18:56 |
| jdstrand | /home/ubuntu/snappy-apps/review-tools.git/parts/review-tools/install/usr/bin/python3: No module named coverage | 18:56 |
| jdstrand | kyrofa: I'm using a prepare scriptlet to run tests. I thought it would be cool to run my coverage tests | 18:56 |
| jdstrand | kyrofa: but adding python3-coverage to build-packages doesn't seem to be pulling it down | 18:57 |
| kyrofa | jdstrand, ah, it's probably using the snap's environment, which looks inside the part for python packages | 18:57 |
| jdstrand | or using what is on the system... | 18:57 |
| kyrofa | jdstrand, try staging it, does that work? | 18:57 |
| jdstrand | kyrofa: no | 18:58 |
| jdstrand | kyrofa: it works fine for all the other ones. eg, python3-yaml, execstack, pep8, etc | 18:58 |
| kyrofa | Oh interesting indeed | 18:58 |
| jdstrand | it is just python3-coverage | 18:58 |
| kyrofa | jdstrand, I've run into similar issues before with staging python debs. Sometimes they create __init__.py files in a postinst | 18:59 |
| kyrofa | Which means when staged, they aren't actually packages | 18:59 |
| kyrofa | (since hooks aren't run) | 18:59 |
| kyrofa | Do you see coverage in the installdir at all? | 19:00 |
| * jdstrand uninstalled python3-coverage from the 'host' and still didn't work | 19:00 | |
| jdstrand | let me look at the postinst | 19:00 |
| kyrofa | jdstrand, if I see this, I assume that means my udev tagging works properly? https://pastebin.ubuntu.com/26074073/ | 19:01 |
| jdstrand | kyrofa: indeed | 19:02 |
| kyrofa | (KERNEL=="gpiomem" got me there, which seems to work like physical-memory-control) | 19:02 |
| kyrofa | Okay good deal | 19:02 |
| jdstrand | great | 19:02 |
| kyrofa | Heck, this should take about five minutes or so | 19:02 |
| jdstrand | kyrofa: so, python3-yaml, which works has: py3compile -p python3-yaml. python3-coverage, which doesn't, has: py3compile -p python3-coverage -V 3.2- | 19:03 |
| jdstrand | kyrofa: does that ring any bells? | 19:03 |
| kyrofa | jdstrand, I'm afraid not. Let me test something... | 19:03 |
| jdstrand | kyrofa: it isn't hugely important. I'm about to bail on it and just run the tests without coverage | 19:04 |
| jdstrand | kyrofa: I just thought it was weird, and since we were already chatting... | 19:04 |
| kyrofa | jdstrand, haha, you can always ping me, even if we're not chatting :) . I agree that it's weird! | 19:05 |
| jdstrand | kyrofa: btw, is my use of the prepare scriptlet to run build tests not too weird? | 19:05 |
| jdstrand | I wanted to fail the build if the tests fail | 19:05 |
| jdstrand | and thought that might be a good way to do it | 19:05 |
| kyrofa | jdstrand, yeah seems reasonable to me, although note that until the most recent release, failing scriptlets did not fail the build process | 19:06 |
| * jdstrand notes that prepare runs before the build, but in this case, that is ok-- I don't actually build anything so running before works fine | 19:06 | |
| jdstrand | I'm on 2.35. it fails the build | 19:07 |
| kyrofa | jdstrand, yeah, `install` runs after. Note that we're also going to get more generic with pre/post instead of those names | 19:07 |
| kyrofa | Good, 2.35 is what you need | 19:07 |
| kyrofa | Okay so staging it seems to work properly here | 19:07 |
| kyrofa | Let me actually try using it | 19:07 |
| jdstrand | kyrofa: I'm using 'python3 -m coverage run <something>' | 19:08 |
| kyrofa | Huh... it's working for me | 19:09 |
| kyrofa | I mean, I have no tests so it's bailing, but it's saying "no file to run" instead of "blah coverage doesn't exist" | 19:09 |
| kyrofa | jdstrand, any chance your YAML is public? | 19:09 |
| jdstrand | kyrofa: http://paste.ubuntu.com/26074189/ | 19:15 |
| zyga-ubuntu | kyrofa: is there an acronym for 'too long to explain, give me the source'? | 19:15 |
| jdstrand | kyrofa: not committed yet cause not working. ./run-snap-build-tests runs 'make coverage'. https://code.launchpad.net/review-tools is the full tree | 19:16 |
| kyrofa | jdstrand, I can confirm that using coverage as a build-package doesn't work. However, using it as a stage-package does | 19:18 |
| jdstrand | kyrofa: how did you use it as a stage-packages? add the scriptlet there? | 19:19 |
| kyrofa | jdstrand, if you want to use build-packages, you can do `export PYTHONHOME="/usr"` in your scriptlet | 19:21 |
| kyrofa | That will force it to use the host's python instead of the one in your snap | 19:21 |
| kyrofa | jdstrand, I used stage-packages like this: https://pastebin.ubuntu.com/26074229/ | 19:22 |
| jdstrand | ok, so I have options | 19:23 |
| jdstrand | kyrofa: is this a bug in snapcraft? | 19:23 |
| kyrofa | jdstrand, well, I'm not sure. When you use the `python` plugin, you're essentially creating a venv inside the snap, which is desired. We also assume you want to use that environment when building | 19:24 |
| kyrofa | It feels weird to then say "Yes I know I've created that environment there, but I'd actually like to not use it for a sec" | 19:24 |
| jdstrand | kyrofa: so why isn't python3-coverage ending up in there, when everyting else is? | 19:24 |
| jdstrand | oh | 19:25 |
| kyrofa | jdstrand, you have it set as a build-package, which only gets installed on the host | 19:25 |
| kyrofa | jdstrand, if you want to get it into the part with everything else, you need to use stage-packages | 19:25 |
| jdstrand | ok, so the issue is that I'm calling 'python3' directly in the scriptlet | 19:27 |
| jdstrand | with -m coverage | 19:28 |
| jdstrand | kyrofa: ok, thanks | 19:35 |
| mup | PR snapd#4310 closed: many: allow to configure core before it is installed <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4310> | 19:35 |
| mup | PR snapd#4281 closed: snapstate: support for pre-refresh hook <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4281> | 19:37 |
| sergiusens | kyrofa look at this trick https://travis-ci.org/snapcore/snapcraft/builds/309146667?utm_source=github_status&utm_medium=notification :-) | 19:41 |
| kyrofa | sergiusens, dude! | 19:41 |
| mup | PR snapcraft#1776 opened: ci: name the travis jobs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1776> | 19:41 |
| kyrofa | sergiusens, so much better | 19:41 |
| sergiusens | I agree | 19:42 |
| sergiusens | it will need to be that way until the issue under consideration on the issue tracker for travis is decided upon | 19:42 |
| sergiusens | but given how the matrix stuff works, I think that this is the intended mechanism for this | 19:43 |
| pedronis | just one 2.30 PR lef but tomorrow | 19:43 |
| pdefreitas | gtk-update-icon-cache: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found | 19:49 |
| pdefreitas | Artful using a different glibc version? | 19:49 |
| pdefreitas | I got snapcraft 2.35 | 19:49 |
| zyga-ubuntu | pdefreitas: yes | 19:51 |
| zyga-ubuntu | pdefreitas: use cleanbuild | 19:51 |
| kyrofa | zyga-ubuntu, jdstrand https://github.com/snapcore/snapd/pull/4323 FYI | 19:53 |
| mup | PR #4323: interfaces: add gpio-memory-control interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/4323> | 19:53 |
| mup | PR snapd#4323 opened: interfaces: add gpio-memory-control interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/4323> | 19:53 |
| zyga-ubuntu | kyrofa: ack | 19:56 |
| mup | PR snapd#4320 closed: tests: don't chown the whole world to test.test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4320> | 19:57 |
| pdefreitas | zyga-ubuntu: I'm using electron.. how do I cleanbuild since npm produces the snap ? | 20:38 |
| === jero- is now known as jero | ||
| zyga-ubuntu | pdefreitas: I don't know what you just said, sorry, | 20:52 |
| zyga-ubuntu | pdefreitas: cleanbuild is for snapcrat | 20:52 |
| zyga-ubuntu | *snapcraft | 20:52 |
| jdstrand | kyrofa: reviewed | 20:54 |
| zyga-ubuntu | jdstrand: it passes!!! | 21:04 |
| zyga-ubuntu | jdstrand: I updated my patch, it still shows the bug in apparmor (now easy to reproduce) but it passes now (hopefully in a sane way) | 21:05 |
| zyga-ubuntu | jdstrand: it did pass before because I didn't notice I made a mistake | 21:05 |
| zyga-ubuntu | jdstrand: and I never unmounted the old namespace, just bind mounted over it again (which probably did the right thing) | 21:05 |
| zyga-ubuntu | jdstrand: having tried to unmount it I found the pattern that confuses apparmor | 21:07 |
| zyga-ubuntu | jdstrand: it's a combination of an open file descriptor, that we keep open, across two setns calls | 21:08 |
| zyga-ubuntu | jdstrand: and fchdir that is used to re-locate us to a directory prior to an unmount call | 21:08 |
| zyga-ubuntu | jdstrand: (that uses relative name) | 21:08 |
| zyga-ubuntu | jdstrand: what I did was to unmount the file with an aboslute name | 21:08 |
| zyga-ubuntu | jdstrand: (this started to fail with EBUSY for unknown reason) | 21:09 |
| zyga-ubuntu | jdstrand: (as nothing inhabits that namespace anymore) | 21:09 |
| zyga-ubuntu | jdstrand: and I switched that to MNT_DETACH | 21:09 |
| zyga-ubuntu | jdstrand: this passed my spread test | 21:09 |
| zyga-ubuntu | jdstrand: I'm going to trim the appamor profile to remove things I added while shooting in the dark | 21:09 |
| mup | Issue snapcraft#1777 opened: Proxy support? <Created by array42> <https://github.com/snapcore/snapcraft/issue/1777> | 21:12 |
| jdstrand | zyga-ubuntu: nice! jjohansen, fyi ^ | 21:14 |
| jdstrand | zyga-ubuntu: can you update the bug with that info? | 21:14 |
| zyga-ubuntu | jdstrand: yes, I will! | 21:14 |
| zyga-ubuntu | jdstrand: I had an euphoria and panic attack today | 21:14 |
| jdstrand | zyga-ubuntu: sounds like quite a day :) | 21:14 |
| jjohansen | uh, setns is a known problem, double setns doesn't change that | 21:15 |
| zyga-ubuntu | jdstrand: when I realized that it worked (on my laptop) and then that it fails the spread test (which was more careful) and then that it finally worked with those extra hacks in place | 21:15 |
| zyga-ubuntu | jjohansen: this doesn't explain why setns is not causing massive failures, we setns for every single started snap | 21:15 |
| zyga-ubuntu | jjohansen: (well, except the first of a given snap) | 21:15 |
| zyga-ubuntu | jjohansen: hey :) long time no see btw | 21:16 |
| zyga-ubuntu | jjohansen: would you have some time to look at the code in the patch and at the denial (also documented in the patch) and see what you make of this? | 21:16 |
| sergiusens | kyrofa mind reviewing snapcraft#1774 before you EOD today? | 21:17 |
| mup | PR snapcraft#1774: Push binary metadata to the Store <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/1774> | 21:17 |
| jjohansen | hey zyga-ubuntu, setns won't necessarily break everything dependent on several things. Partly to due with how mounts are shared or whether they are cloned .. | 21:17 |
| kyrofa | sergiusens, sure thing | 21:17 |
| jjohansen | zyga-ubuntu: yes I will look into it | 21:17 |
| mup | Issue snapcraft#1777 closed: Proxy support? <Created by array42> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1777> | 21:18 |
| zyga-ubuntu | jjohansen: I see | 21:18 |
| zyga-ubuntu | jjohansen: thank you, I'll open the PR in 10 minutes | 21:18 |
| mup | PR snapd#4324 opened: cmd/snap-confine: discard stale mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/4324> | 21:23 |
| zyga-ubu1tu | jjohansen, jdstrand ^ | 21:24 |
| jdstrand | jjohansen: so, what is supposed to be happening here (zyga-ubu1tu can correct me) is that we do the setns for the persistent mount namespace. that thing sticks around until it becomes 'stale'. if no processes are using the mount namespace, snap-confine will remove the persistent mount namespace so that it can be started anew the next time | 21:28 |
| jdstrand | jjohansen: eg, foo.bar starts and a persistent mount namespace is setup and foo.bar is put into it | 21:30 |
| jdstrand | jjohansen: foo.baz comes along, sees that foo's persistent mount namespace is available and doesn't have to be setup, then setns into it | 21:30 |
| jdstrand | jjohansen: things might be added to the mount namespace through snap connections, but if they are removed, the namespace is considered stale. | 21:32 |
| jdstrand | jjohansen: running processes continue to use the stale namespace until no processes are using it, at which point, the next foo.whatever invocation tears it down and reconstructs it | 21:33 |
| jdstrand | zyga-ubu1tu: please correct me ^ | 21:33 |
| jdstrand | jjohansen: snaps themselves are not allowed to use setns or mount to escape | 21:35 |
| jjohansen | jdstrand: that wouldn't be a double setns, setns in, and then setns out | 21:35 |
| zyga-ubu1tu | jdstrand: one thing I would correct is that we only consider it stale when the base snap revision (the rootfs) changes and we want to follow by starting with a fresh namespace | 21:35 |
| jjohansen | and that should not be a problem, unless the ns being reaped is lazily unmounted, at which everything within that namespace becomes disconnected, as it no longer has a namespace | 21:36 |
| zyga-ubu1tu | jjohansen: the double setns is when we consider using a namespace, we jump inside (1st setns), see that it is stale and then jump out (2nd setns by folling /proc/1/ns/mnt) in order to be able to do the unmount (the bind mounted namespace is only visible on the main namespace) | 21:36 |
| jdstrand | jjohansen: I don't know what the 'double setns' talk is about. I think zyga-ubu1tu was saying he made a coding mistake that he since corrected | 21:36 |
| zyga-ubu1tu | jdstrand: I did use MNT_DETACH, as described in the patch | 21:37 |
| zyga-ubu1tu | er, jjohansen ^ | 21:37 |
| jjohansen | zyga-ubu1tu: that is basically known as a chroot escape, and it is very bad form | 21:37 |
| zyga-ubu1tu | jjohansen: though I don't quite know why that is needed, I got EBUSY otherwise | 21:37 |
| jdstrand | oh yes, the setns to pid 1's namespace | 21:37 |
| jdstrand | that is only for snap-confine though, not snaps | 21:37 |
| zyga-ubu1tu | jjohansen: when we lazily unmount there should be no more processes there | 21:37 |
| jjohansen | jdstrand: your point being? | 21:38 |
| zyga-ubu1tu | jjohansen: measured using a freezer cgroup that all processes from this snap inhait | 21:38 |
| zyga-ubu1tu | *inhabit | 21:38 |
| jjohansen | zyga-ubu1tu: I am going to have to dig into your specific case more | 21:39 |
| jjohansen | before I can say exactly what is going on to cause the failure | 21:40 |
| zyga-ubu1tu | jjohansen: sure, thank you for looking | 21:40 |
| jdstrand | zyga-ubu1tu: this only reason for doing the /proc/1 stuff is for the devmode/checkbox snap, correct? | 21:41 |
| zyga-ubu1tu | jdstrand: the only other reason | 21:42 |
| zyga-ubu1tu | jdstrand: here it's a "legitimate" way to jump out | 21:42 |
| zyga-ubu1tu | jdstrand: as a variant where we don't jump out I could use the capture helper (process forked earlier still in the original namespace) and re-distribute the flow of the code so that it does the work | 21:42 |
| kyrofa | Hey cprov, can I not generate an attenuated macaroon for a specific project if I'm only a collaborator on that project? | 21:43 |
| zyga-ubu1tu | jdstrand: in general I think we can refactor snap-confine, re-write it if necessary if we get directions on what to do and what not to do to stay in the bounds of the limitations of the kernel | 21:43 |
| zyga-ubu1tu | attenuated macaroon, boy, and I find my job confusing sometimes ^_^ | 21:44 |
| zyga-ubu1tu | kyrofa: what is an attenuated macaroon, a very small cookie? | 21:44 |
| === zyga-ubu1tu is now known as zyga-ubuntu | ||
| cprov | kyrofa: let me check the code, but it's possible that is restricted to the publisher. | 21:44 |
| zyga-ubuntu | ok, I'm EOD, it far too late already | 21:45 |
| zyga-ubuntu | niemeyer: ^^ | 21:46 |
| jdstrand | zyga-ubuntu: you say "this" is a legitmate reason to jump out... can you explain the flow for this legitimate use case? | 21:46 |
| zyga-ubuntu | jdstrand: yes | 21:46 |
| zyga-ubuntu | jdstrand: we start in whatever the namespace is (let's say the main one), look at /var/lib/snapd/ns/$SNAP_NAME.mnt and setns inside (successfully) in an attempt to reuse it | 21:47 |
| cprov | kyrofa: can you file a bug on the snapstore project with the traceback of the request you are doing ? | 21:47 |
| zyga-ubuntu | jdstrand: once inside we measure / and see that it's not the one we expect and we consider if we can clean it up | 21:47 |
| zyga-ubuntu | jdstrand: we measure /sys/fs/cgroup/freezer/snap.$SNAP_NAME/cgroup.procs and look for inhabitants, | 21:48 |
| zyga-ubuntu | jdstrand: finding none we consider it safe to unmount and start over | 21:48 |
| zyga-ubuntu | jdstrand: we setns on /proc/1/ns/mnt to have a perspective in which we can unmount /var/lib/snapd/ns/$SNAP_NAME.mnt (remember that ... oh drat, I meant /run/snapd/ns above and here) has private mount sharing | 21:49 |
| jdstrand | zyga-ubuntu: another way to do it would not setns in it at all. just look for inhabitants. if none, reconstruct | 21:49 |
| zyga-ubuntu | jdstrand: then we umount with MNT_DETACH and re-start the procedure (where we see the that .mnt file is no longer a namespace bind mount so we construct a fresh one and bind over it) | 21:49 |
| zyga-ubuntu | jdstrand: yes but the current detection logic depends on looking at / from the inside (I think this is not a problem and we could adjust) and also this would make the cache effectively useless | 21:50 |
| zyga-ubuntu | jdstrand: as a cache that is | 21:50 |
| zyga-ubuntu | jdstrand: it would still function for as long as we have a living process inside | 21:50 |
| zyga-ubuntu | jdstrand: it could probably cause some issues for snaps that keep data in /tmp and (currently, unaware of this) depend on it to stick around | 21:51 |
| zyga-ubuntu | jdstrand: I would rather setns and exit and then continue from a forked child that hasn't setns at all yet | 21:51 |
| jdstrand | zyga-ubuntu: the /tmp case is still there regardless. consider a snap disconnect | 21:51 |
| zyga-ubuntu | jdstrand: (and since we already fork for the bind mount that captures the namespace, due to how the kernel requires this to be done, we could do this without additional "cost") | 21:52 |
| zyga-ubuntu | jdstrand: yes? what about it? | 21:52 |
| zyga-ubuntu | jdstrand: (we don't lose /tmp then) | 21:52 |
| jdstrand | zyga-ubuntu: you said that 'it could probably cause some issues...'. I'm saying that is still the case | 21:53 |
| zyga-ubuntu | jdstrand: yes but today this is less frequent (both in master and with this patch) | 21:53 |
| zyga-ubuntu | jdstrand: but otherwise I agree | 21:53 |
| zyga-ubuntu | jdstrand: I just didn't understand why "snap disconnect" matters | 21:53 |
| kyrofa | cprov, will do... but I may have broken this | 21:53 |
| zyga-ubuntu | jdstrand: we should never discard a namespace on disconnect | 21:53 |
| jdstrand | zyga-ubuntu: I was just mentioning a case where the mount namespace might have to be updated | 21:54 |
| jdstrand | eg, you disconnect a content interface. sure, you don't discard *then*, but you will whenever no processes are there | 21:54 |
| zyga-ubuntu | jdstrand: right, but we don't change /tmp in that case, I really did mean /tmp specifically where software just keeps various files | 21:54 |
| zyga-ubuntu | jdstrand: agreed on all that | 21:54 |
| jdstrand | anyway | 21:54 |
| jdstrand | zyga-ubuntu: so, it feels really weird to setns in and then out and then in again | 21:55 |
| zyga-ubuntu | jdstrand: well, in, out, and then unshare technically | 21:55 |
| zyga-ubuntu | jdstrand: we never setns three times | 21:56 |
| jdstrand | sure | 21:56 |
| zyga-ubuntu | jdstrand: if I adjust the logic for staleness detection I think it's equally possible to not setns again, but I'd have to see how much code needs refactoring to allow that | 21:57 |
| zyga-ubuntu | (some of the code is a victim of evolutionary approach there) | 21:57 |
| jdstrand | zyga-ubuntu: I think with the myriad of PRs over weeks/months it was hard for me to understand where we were heading. I'm sorry for that (not blaming you or anything. I just feel bad about not seeing this early) | 21:57 |
| jdstrand | on the one hand, we are talking about 'only' snap-confine needing this access to jump out | 21:58 |
| jdstrand | *but* snap-confine is setuid root and an attack vector, so we are trying to minimize what it can do | 21:58 |
| jdstrand | zyga-ubuntu: there are certainly other ways to do this, but fork/exec'ing a helper in the namespace to detect staleness and communicating to the parent (snap-confine) how to proceed would avoid the issue | 22:00 |
| jdstrand | zyga-ubuntu: so, snap-confine starts in the original ns, it launches a helper that detects staleness, it gets back the results and snap-confine decides what to do | 22:02 |
| jdstrand | zyga-ubuntu: this way, snap confine doesn | 22:03 |
| jdstrand | 't have any extra permissions. the helper could have a small subset of the current profile and snap-confine could have some rules removed that are only in the staleness detector | 22:03 |
| jdstrand | zyga-ubuntu: this should avoid the kernel issue you are seeing. that kernel issue is, I think, indicative of the fact that one shouldn't really be jumping around with setns() | 22:05 |
| zyga-ubuntu | jdstrand: yeah, I think there are ways to do this | 22:05 |
| jdstrand | which is why it isn't surprising that it isn't working as expected | 22:05 |
| zyga-ubuntu | jdstrand: though here I'll repeat what I said earlier in the conversation: knowing the limitations would help to desing this better | 22:05 |
| zyga-ubuntu | jdstrand: if there's a rule to setns at most once, that's a valuable fact | 22:06 |
| zyga-ubuntu | jdstrand: note that setns(2) doesn't really documenta any constraints | 22:06 |
| zyga-ubuntu | *document | 22:06 |
| zyga-ubuntu | jdstrand: though I know this is all tricky business and there dragons around :) | 22:06 |
| jdstrand | zyga-ubuntu: I don't think my helper idea would require a ton of refactoring or anything. maybe you can think of something else, but the fork/exec with the parent and child in different namespaces is clean design-wise | 22:06 |
| zyga-ubuntu | jdstrand: agreed | 22:07 |
| zyga-ubuntu | jdstrand: but I think we still don't (at least not me) have a very clear idea of what is off limits and what is allowed | 22:07 |
| zyga-ubuntu | jdstrand: why is 2nd setns special? | 22:07 |
| jdstrand | zyga-ubuntu: well, we are pushing the boundaries here. I think the only one setns() is implied rather than explicit | 22:07 |
| zyga-ubuntu | jdstrand: I think we need to wait for a deeper analysis | 22:07 |
| zyga-ubuntu | jdstrand: well, it works if you unconfine :) | 22:08 |
| jdstrand | zyga-ubuntu: so, namespaces are, in part, meant to address shortcomings in things like chroot | 22:08 |
| * zyga-ubuntu should get to bed, day starts soon | 22:09 | |
| jdstrand | zyga-ubuntu: so if you can setns in and out of a namespace all the time, that isn't great, so people, I think, are really thinking about a single setns that you shouldn't leave | 22:09 |
| zyga-ubuntu | jdstrand: I will shift my timezone to match yours next year | 22:09 |
| zyga-ubuntu | jdstrand: and I will probably (likely) be off most of december to burn my holidays | 22:09 |
| zyga-ubuntu | jdstrand: at one point in time I was hoping we can keep a thread in each namespace permanently but then, unfortunately, I learned that sents must be called when there's only one thread | 22:10 |
| jdstrand | jjohansen: sorry it is late for you. note that jjohansen can be considered a kernel expert in this area. the fork/exec idea is confirmed as fine | 22:10 |
| jdstrand | meh | 22:10 |
| jdstrand | jjohansen: nm | 22:10 |
| jdstrand | zyga-ubuntu: ^ | 22:10 |
| zyga-ubuntu | jdstrand: it would be really cool to design snapd in a way that keeps a pool of threads in each namespace | 22:10 |
| zyga-ubuntu | :-) | 22:10 |
| zyga-ubuntu | jdstrand: I will look at reworking it tomorrow if you desire | 22:11 |
| jdstrand | zyga-ubuntu: I do. it is a significant deparature in design-- you still detect and decide, it is just a tweak on how to organize that | 22:12 |
| jdstrand | err | 22:12 |
| jdstrand | zyga-ubuntu: it isn't* | 22:12 |
| jdstrand | zyga-ubuntu: and that tweak makes a big difference in what snap-confine is allowed to do, and keeps a cleaner separation of the namespaces, which is more inline with kernel expectations | 22:13 |
| zyga-ubuntu | ack | 22:14 |
| jdstrand | zyga-ubuntu: so, there is still the sc_reassociate_with_pid1_mount_ns() that is called unconditionally in snap-confine.c when !classic confinement | 22:20 |
| pedronis | it's a bit annoying that there's no way to measure the namespace from outside even being root | 22:21 |
| jdstrand | zyga-ubuntu: don't worry about that for now. I want to think through that (I never cared for this-- can checkbox not just be classic)? | 22:21 |
| jdstrand | I guess it is really all devmode snaps. but now that we have classic and devmode is a step to strict, I don't see the problem with disallowing calling other snaps from devmode. but that conversation has been had. anyway, let me think about it | 22:24 |
| mup | PR snapcraft#1775 closed: Add --help command for the runtests.sh script <Created by m4sk1n> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1775> | 23:00 |
| sergiusens | kyrofa any idea why from one stage to the next the built snap wouldn't be available? -> https://travis-ci.org/snapcore/snapcraft/builds/309146667?utm_source=github_status&utm_medium=notification | 23:12 |
| mwhudson | er is there a reason snap run uses snap-exec from the host system not the core snap? | 23:17 |
| mwhudson | sounds like a fourm question | 23:19 |
| kyrofa | Hmm.... I'm not sure how that works sergiusens | 23:20 |
| kyrofa | sergiusens, I mean, that dir is cached | 23:21 |
| kyrofa | I don't think there's magic beyond that | 23:21 |
| sergiusens | kyrofa maybe the next stage ran somewhere else? I am going to just click on rebuild for everything and if not wait for the transfer.sh work to finish ;-) | 23:22 |
| kyrofa | sergiusens, unless lxc file pull can fail without exiting non-zero... super weird | 23:23 |
| kyrofa | sergiusens, but yeah, I've seen the stages run out of order before, elopio had to close/re-open to get it to run again | 23:23 |
| kyrofa | Correctly, I mean | 23:23 |
| sergiusens | I saw these ran in order, but with a lot of time in between each stage | 23:25 |
| mup | PR snapd#4325 opened: Adding test for netlink-connector interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4325> | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!