[00:30] Anyone around here have any GPIO experience on raspberry pi 2? https://forum.snapcraft.io/t/raspberry-pi-2-missing-gpio-slot/2979 [01:06] sorry for sounding like a broken record kyrofa ... [01:07] ogra_, oh you're being super helpful, and I know this isn't on you :) [01:07] ogra_, but I... just can't believe it : [01:07] :P [01:10] kyrofa, well, seems niemeyer thinks it is safe ... so we'll see what happens [01:11] the answer sounds like a "soon" :) [01:12] 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:13] 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:15] (specifically the overlay dtbs ... and even more specifically the graphics stack (which is actually used by customers in production) ...) [01:16] (IIRC the kernel in stable did not even have the vc4 driver enabled so the dtb overlay will be missing or broken) [01:17] but i trust that you guys tested all this :) [01:19] ogra_: No, you actually don't.. this is called irony, and also passive aggressiveness. It's unhealthy when we work together with people. [01:23] niemeyer, i meant what i said ... sorry that you interpreted the smiley as irony, i was just trying to be firendly ... [01:24] ogra_: No, you really didn't. The fact you can't be honest to yourself about this is part of the issue. [01:33] 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:40] ogra_: We are not updating any of those dtbs.. We are updating the kernel. [01:40] err [01:41] ogra_: Yes, things can break, always, on any update. [01:41] ogra_: We'll do our best to keep things stable and working. [01:41] 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] The release will go into beta, and into candidate, and then into stable. [01:47] Issue snapcraft#1709 closed: Extract macaroon retrieval into more generic place [01:47] PR snapcraft#1765 closed: store: refactor acquirement of attenuated macaroon [02:24] niemeyer, are your mongodb snapcraft.yamls anywhere public ? [02:24] ( i dont see a mongo repo under your GH account) [02:24] ogra_: Haven't been updated in a while, but haven't changed much either: [02:25] github.com/niemeyer/snaps [02:25] thanks ! [02:25] np [02:29] 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] I can't seem to find anything useful in the docs regarding this. [02:30] specificall I need to be able to write in a NFS network mounted home dir. [02:30] +y [02:32] Issue snapcraft#1752 closed: export the arch triplet variable during build time [02:32] PR snapcraft#1768 closed: project: export the arch triplet into the environment [02:36] lundmar, https://forum.snapcraft.io/t/snaps-and-nfs-home/438 discussed this [02:47] PR snapcraft#1557 closed: cleanbuild: add a --image option to build in a different image [02:47] PR snapcraft#1769 opened: lxd: add an --image argument to cleanbuild [03:01] ogra_: ok thanks. So it looks like NFS mounted home suppor is arriving in snap v2.29 [03:01] support* [03:01] which should technically be released already [03:02] * ogra_ sees 2.29.3 in "snap version" [03:02] too bad many if the distributions running snapd are hopelessly behind in snapd version :/ [03:02] of* [03:03] well, it will eventually dripple down into all of them [03:05] true [03:06] (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:10] ogra_: oh, thats clear. So that way the old snapd process gets replaced by the new snapd. [03:11] yeah [03:12] and snapd does just update along with the core snap [03:12] so you dont need to wait for a distro package to be updated === chihchun_afk is now known as chihchun [03:26] PR snapcraft#1770 opened: Add codespell support [04:02] PR snapcraft#1764 closed: snapcraft.yaml: use gcc to determine tuple [04:08] PR snapcraft#1771 opened: lxd: suppress traceback when lxc launch / init fails [04:23] PR snapcraft#1772 opened: Release changelog for 2.36 [04:23] snappy-m-o autopkgtest 1772 xenial:amd64 [04:23] sergiusens: I've just triggered your test. [04:25] grrr ... why is vt.handoff= not working right in core [04:30] * ogra_ wonders if thats subiquitys fault ... === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:05] morning [06:21] mborzecki, hey [07:01] PR snapd#4224 closed: cmd/snap-update-ns: teach update logic to handle synthetic changes [07:04] good morning [07:06] mvo: hey, what are your release / branch plans for today? [07:06] mvo: looking at the 2.30 tags we have a few branches still open [07:07] zyga-ubuntu: morning [07:07] hey :) [07:08] mvo: hey [07:09] zyga-ubuntu: hey, good morning. yeah, branch happens as soon as we get the blockers out of the way [07:09] mborzecki: hey, good morning [07:09] mvo: I recall pedronis said something about some blocker yesterday, is that already reflected in the list of PRs? [07:12] https://github.com/snapcore/snapd/commit/308c7ca6315a56fcc1028f3d9aeddb465c51c0d4 other distros should do the same I suppose? [07:12] zyga-ubuntu: yes, the list should be accurate [07:13] mborzecki: yeah, I was thinking about htat [07:13] mborzecki: idea [07:13] mborzecki: add a make install code to data [07:13] mborzecki: let that handle all mkdir's [07:14] mborzecki: and let that handle distro differences as well [07:14] mborzecki: then drop the random code from packaging that just creates those directories [07:14] mborzecki: then we have one place [07:14] mborzecki: and packaging will at most complain about unpackaged directories [07:14] mborzecki: +1/-1? [07:14] iirc you'll still have to list the directories, eg in rpm spec [07:15] mborzecki: yes but then you know when you messed up in packaigng [07:15] mborzecki: and the directories are the same in one central place [07:15] right [07:15] but yeah, sounds like a good idea [07:16] * zyga-ubuntu needs a review on 4315 [07:17] 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] mborzecki: is configure setting any environment we can reuse? [07:17] mborzecki: anyway, I'm sure you can refactor it to be nicer :) [07:19] something to explore perhaps [07:19] where do we keep a backlog of things to explore/revisit? [07:20] mborzecki: on the forum [07:20] mborzecki: tag with your name and "backlog" [07:20] oh, ok [07:23] discourse ux is not what i expected it to be after hearing so many good things about [07:39] zyga-ubuntu: https://forum.snapcraft.io/t/2984 [07:40] * zyga-ubuntu looks [07:41] at least there'd be no need to pass various *DIR settings to data/Makefile [07:50] 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:51] haisheng: hello [07:52] haisheng: can you tell me more about what you mean [07:52] I want to customize the base snap image. [07:52] https://tutorials.ubuntu.com/tutorial/create-your-own-core-image#2 [07:52] haisheng: do you intend your base snap to be used for booting the system or just as a runtime for some apps? [07:53] used for booting the system [07:53] mvo: ^ [07:54] I am from china. And my english is not good. sorry for that. [07:54] haisheng: I think this is something we are still exploring/building but mvo is focusing on that more than I do [07:54] haisheng: no worries :) [07:55] haisheng: what kind of changes would you like to make to your base snap? [07:56] 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:57] 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. [08:02] ok,thanks. show can i modify the "core" snap, and info can be provided for reference. [08:03] haisheng: can you describe the kind of changes you want to make? [08:09] In fact, I just want to know how the roofs can be packaged the snap [08:09] how base system can be packaged the snap [08:09] haisheng: ikey here is making use of base snaps for app runtimes; he builds a non-ubuntu based rootfs [08:10] haisheng: but he uses it for apps, not for booting the system [08:10] * ikey flicks into life [08:10] (in his case the system is a classic distribution like ubuntu or solus) [08:14] 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] mborzecki: can you do a 2nd review on 4291 [08:14] mborzecki: this will help chipaca's other branch [08:14] ok, looking now [08:15] thank you [08:17] ok , zyga-ubuntu, thanks. how can i customize the base snaps for app runtimes. any info about it can be provided. [08:17] haisheng: please look at the forum (forum.snapcraft.io), it's documented there [08:19] ogra_: aha, nice [08:19] so spit initrd for modules shouldnt be any prob either ... [08:19] *split [08:20] (testing it on grub was the remaining missing bit) [08:50] 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] PR #4291: osutil/sys: reimplement getuid and chown with the right int type [08:53] mborzecki: yeah, I thought about that when reviewing this and I assumed that the older syscall is just not exposed [08:53] mborzecki: but indeed worth checking [08:54] john is not around yet, it seems [08:55] PR snapd#4161 closed: snapstate: add support for refresh.schedule=managed [08:56] looks like Go uses SYS_GETUID32 on 32bit arches, https://github.com/golang/go/search?utf8=%E2%9C%93&q=SYS_GETUID32&type= [09:00] rewrite snapd in C when? [09:00] *runs* [09:00] pfft ... [09:01] shell ... C is boring [09:02] :O === __chip__ is now known as Chipaca [09:07] zyga-ubuntu: good catch on the GETUID32 thing! i shall now add a test and do penance [09:08] * Chipaca wonders if people will notice penance is actually just more coffee [09:08] Chipaca: is it, I'm not sure if your syscall is wrong, I didn't check the number [09:09] zyga-ubuntu: yes [09:09] * ikey starts on libsoup/glib2/libxml2/glib-networking/gnutls/gobject powered "lightweight" snapd fork [09:10] ikey: don't forget adding scheme "for scripting" [09:10] ikey: WAT [09:10] oh we could use libpeas [09:10] python plugins [09:10] no no, use guile [09:11] yeah i think you might be right there [09:11] >_> [09:11] am i missing context for this, or is it just too early? [09:11] i can go away and come back at noon [09:12] Chipaca, im just on a wind up [09:12] proposing the most offensive combination of technology possible :p [09:12] hm I *did* forget the bytecode VM .. [09:19] 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] PR #4281: snapstate: support for pre-refresh hook [09:20] zyga-ubuntu: yes, it is in the list, #4310 [09:20] PR #4310: many: allow to configure core before it is installed [09:20] pedronis: great, thank you for confirming [09:22] zyga-ubuntu: added some questions to #4315 [09:22] PR #4315: cmd/snap-update-ns: add execWritableMimic [09:22] mborzecki: thank you [09:24] mborzecki: replied, thanks [09:42] ugh, more snow [09:50] #4310 needs a 2nd review [09:50] PR #4310: many: allow to configure core before it is installed [09:51] Issue snapcraft#1773 opened: Please upgrade brew version [10:09] ok, i've got to go see the doc; bbl === chihchun is now known as chihchun_afk [10:20] pedronis: re 4281> checking it now [10:32] 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:36] pedronis: let me look, probably sorting [10:47] pedronis: I cannot reproduce this [10:47] pedronis: I tried watch -n 1 -d "go test -cover -coverprofile=coverage.out && go tool cover -func=coverage.out" [10:47] pedronis: (in the cmd/snap-update-ns) directory [10:47] pedronis: and the only thing that varies slightly is time [10:47] pedronis: which commit are you on? [10:48] ok, just weirdness then [11:18] * zyga-ubuntu -> tea [11:21] PR snapd#4316 opened: cmd/snap-mgmt: introduce snap-mgmt tool [11:43] Chipaca: should "snap switch --devmode" be a thing? [11:44] zyga-ubuntu: only if snap switch --undevmode is a thig [11:44] Chipaca: snap switch --strict [11:45] I think there's no way to toggle devmode now [11:47] zyga-ubuntu: that is correct [11:47] i mean, it is a correct description [11:47] or a true statement [11:47] there, it's a true statement. [11:52] o/ [11:56] hey niemeyer [11:58] which plug do I need to avoid this kind of denial: operation="capable" comm="snap-confine" capability=2 capname="dac_read_search" [12:00] pdefreitas: what did you do to get that error? [12:00] pdefreitas: snap-confine should never experience that [12:02] snapping an electron app from a deb like the discord one available in snapcrafters github [12:02] pdefreitas: can you be more specific, this error can only happen at runtime, what did you run next? [12:03] installed the app and when I ran it it crashed, checked the syslog and I got that [12:03] running in devmode ofc [12:04] on what kind of host? [12:05] latest artful [12:05] x64 [12:13] niemeyer: hi [12:14] pedronis: Heya [12:14] niemeyer: #4281 needs a re-review from you [12:14] PR #4281: snapstate: support for pre-refresh hook [12:19] pedronis: Two trivials and LGTM, thanks for the ping [12:19] ahasenack: ping [12:19] niemeyer: hi [12:19] ahasenack: Heya! [12:19] ahasenack: Can I abuse your knowledge for a moment? :) [12:20] sure [12:20] ahasenack: It's about PAM.. [12:20] ahasenack: Is there: [12:20] 1. A standard protocol between PAM and its modules that doesn't involve linking with libpam [12:20] or, alternatively [12:21] 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] ? [12:21] 1. I think not [12:21] the "conversation" happens within the libraries/modules [12:21] * mborzecki is away for half an hour [12:22] mborzecki: / [12:22] o/ [12:22] PR snapcraft#1774 opened: Push binary metadata to the Store [12:22] I haven't heard about 2 [12:23] ahasenack: Okay, thanks :( [12:23] ahasenack: I was hoping for some luck [12:23] tl;dr you want to benefit from existing pam modules but without linking with libpam? [12:24] ahasenack: Yeah, the key issue is ABI stability [12:24] ahasenack: Well, actually, not really [12:25] ahasenack: The thing I'd like to do is enable a typical libpam-linked application to use a stable ABI to authenticate [12:25] did you just encounter an abi breakage? [12:25] between xenial and xenial+N perhaps? [12:25] ahasenack: So *inside* the snap we need to offer something to that application that will answer auth questions [12:26] ahasenack: No.. I'm anticipating that there will definitely be ABI breakages and differences across snaps [12:26] ok [12:27] ahasenack: I'm surprised nobody did a "Hey, here is how to do a PAM module in shell!" kind of thing [12:27] ahasenack: Although that's arguably for the best ;P [12:27] I quickly searched for pam over dbus (!) [12:27] but what I found isn't that [12:27] ahasenack: I suspect that will find a huge amount of people doing the authentication part of it [12:27] ahasenack: Instead of the extension [12:28] or just the very simple bits of the authentication [12:28] ahasenack: Yeah, our problem is really not authenticating.. it's giving to a typical application that uses PAM something it can use [12:28] I mean, we'd then have to bridge it into the real modules, but that's easier [12:29] do you have some sort of pam interface in snaps? for snaps to use the host's pam? [12:30] ahasenack: Exactly :) [12:30] interesting [12:31] ahasenack: I'm figuring if we can do that at all [12:31] and I can see that breaking indeed [12:31] Without major pain, of course [12:31] 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:32] 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:34] ahasenack: Not just that, but it implies every application in the world would use that same .so ABI [12:34] ahasenack: Which we know is a time bomb [12:34] yeah [12:34] you need some sort of pam broker [12:37] Issue snapcraft#1773 closed: Please upgrade brew version [12:40] ahasenack: Thanks for those details [12:56] ahasenack: If you're interested: [12:56] https://forum.snapcraft.io/t/user-authentication-in-snapd/2915/4 [12:57] zyga-ubuntu: do you have an armhf board on core handy? [12:58] Hi guys, does anyone knows how can I override the GOGCCFLAGS for a crosscompilation of Go that imports C libs ? [12:59] niemeyer: good real world case [12:59] brunosfer: is it for -ldflags? [12:59] of course, it had to be about printers :) [13:00] ahasenack: :P [13:01] chipaca: yes, but when I do it through ubuntu artful it always loads the predefined flags and I can't move on. [13:02] brunosfer: is this for go inside snapcraft? [13:03] yep [13:03] ah [13:03] but first I want to make sure I can compile it, to move further with the snapcraft tool... [13:06] brunosfer: how are you trying to compile it? [13:08] 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:09] it works if I compile to my host platform amd64, but I want to compile for arm. [13:10] 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:14] brunosfer: how are you compiling it for arm? [13:22] Chipaca: yes, sure [13:22] Chipaca: I can give you access in a moment [13:22] Chipaca: pi2 and dragon running core [13:29] zyga-ubuntu: thanks [13:37] how can I get more detailed logging of which permissions is my snap failing in devmode? [13:37] Is /var/log/syslog the only way to debug ? [13:38] 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:40] pdefreitas: snapd core team is in a meeting right now [13:45] cjwatson if this is a test, can you try using 2.35 (it is in xenial-proposed currently) [13:47] 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:48] * sergiusens checks pending-sru [13:48] Yeah, this is just me testing that my launchpad-buildd changes work. Let's see ... [13:53] 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:54] pdefreitas: we have a helper snap (snapd-debug) for that [13:55] 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:57] zuga-ubuntu: but that helper just don't watch /var/log/syslog [13:57] *zyga-ubuntu [14:01] it tails me to the same issue I reported lol [14:02] just a syslog watcher === chihchun_afk is now known as chihchun [14:04] mwhudson: can I use netplan to assign metric to my interfaces so that I can use pi3 over eth in preference to wifi [14:13] How can I install classic snap in ubuntu snappy core on RPi3 ? [14:14] I've tried sudo snap install --devmode classic but it doesn't recognize classic as a valid snap... [14:24] brunosfer: please try "sudo snap install --devmode --beta classic [14:27] mv: thank you very much, it worked perfectly. [14:27] mvo: thank you very much, it worked perfectly. [14:29] yw [14:31] btw, is there any gcc snap package for snappy core? [14:35] PR snapd#4317 opened: tests: make interfaces-snapd-control-with-manage more robust [14:39] lunch! [14:45] PR snapd#4318 opened: snapstate: fix unkeyed fields error [14:45] ^ guys, a really trivial fix [14:49] pstolowski: I fear I had to add a couple comments on the last feedback changes in #4281 [14:49] PR #4281: snapstate: support for pre-refresh hook [14:50] Chipaca: sha512 doesn't seem interesting, we would need something cheaper [14:50] pedronis: crc32 ftw [14:52] pedronis, no worries & thanks [14:53] pstolowski: thx [14:53] pedronis: sha256? din't know if that's any cheaper, there are hardware acceleration implementations of both sha256 and sha512 [14:54] even in golang [14:54] network failed [14:54] mvo: is it still expected not to be able to go from edge to candidate? [14:55] ah, linode is busy [14:55] jdstrand: hey [14:55] jdstrand: I have an exciting PR to review [14:56] 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] cyphermox: looking! [14:56] cyphermox: thanks! [14:57] 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] 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] zyga-ubuntu: more exciting than 4315? [14:57] jdstrand: yes, https://github.com/snapcore/snapd/compare/master...zyga:fix/discard-stale-base-snap?expand=1 [14:58] jdstrand: I'll open it when there are more linode things available [14:58] ok [14:58] jdstrand: something mvo might include in 2.30 if you deem it safe [14:59] you've really been keeping me busy... [14:59] 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] (Raspberry pi not rip) [15:01] sborovkov: but rip is so appropriate here ;) [15:01] sborovkov: are those extra snaps a factor? [15:01] zyga-ubuntu: oh, stale mount namespace fix? that sounds sweet [15:02] zyga-ubuntu: re edge -> candiate - almost there, I think the fix landed last night [15:02] zyga-ubuntu: so the next core build in edge should be good again [15:03] mvo: aha, do we need the fix in candidate or just in edge? [15:03] 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:04] But this one just died 3 times in a row after such update. I was thinking that it is faulty sd card first [15:05] 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] as* [15:06] anyone know what sets the license field? [15:07]