=== chihchun_afk is now known as chihchun
[05:13] <mborzecki> morning
[05:26] <Chipaca> mborzecki: morning
[05:27] <mborzecki> Chipaca: hey, i see there's a PR to spread https://github.com/snapcore/spread/pull/67
[05:28] <Chipaca> mborzecki: yup
[05:49]  * Chipaca changing locations
=== chihchun is now known as chihchun_afk
[07:02] <mvo> mborzecki: do you think you could have a look at 5592?
[07:02] <mborzecki> mvo: hi, i'm going through it now
[07:03] <mvo> mborzecki: yay, thank you! once that is in I hop eI can build a first beta(ish) image
[07:15] <mborzecki> not sure we can do anything about remaining reviews at this point
[07:21] <mvo> mborzecki: yeah, it looks like the other reviews are all blocked in one way or the other
[07:22] <mvo> mborzecki: did you write more? I got disconnected so may have missed bits
[07:23] <mborzecki> mvo: nope
[07:27] <Chipaca> hello again
[07:33] <mvo> hey Chipaca
[07:34] <mborzecki> Chipaca: welcome back
[07:35] <mborzecki> hmm noticed that experimental.parallel-instances has no effect when doing install from file :(
[08:02] <mborzecki> need moar coffee
[08:13] <mvo> ogra: does the pi3 gadget needs updates for the 4.15 kernel? when I boot it using a serial port I see: Starting kernel ...
[08:13] <mvo> �
[08:13] <mvo> ogra: and then lots of these: �f��~��� screenfulls. but the uboot messages are all normal
[08:14] <mvo> ppisati: -^
[08:29] <ogra> mvo, yes
[08:29] <mvo> ogra, ppisati pi2 with 4.15 show kernel boot message but shows https://paste.ubuntu.com/p/Zq9wqg3qfF/ and hangs
[08:29] <mvo> ogra: so we need a new/updated gadget in any case? what does need to change?
[08:30] <ogra> oh, wait, not sure about just 4.15 (4.15 on pi3 B+ needs new gadget stuff)
[08:31] <ogra> mvo, but it is likely we need new blobs all over since they are always built for a certain kernel vetrsion
[08:31] <ogra> (they are backwards compatible so it should be fine to update and keep 4.4 working)
[08:32] <mvo> ogra: ok
[08:33] <mvo> ogra: I guess raspberrypi/firmware git repo is the place?
[08:33] <ogra> mvo, try my universal gadget, it pulls new FW during build
[08:33] <mvo> ogra: ok
[08:33] <ogra> (was needed for cm3)
[08:34] <ogra> https://github.com/ogra1/pi-kiosk-gadget
[08:34] <ogra> oh, wait, it doesnt
[08:34] <ogra> damn
[08:38] <ogra> mvo, you actually want master from https://github.com/raspberrypi/firmware, all stable versions point to 4.9
[08:39] <mvo> ogra: yeah, looks like we are pulling from the 201705xx tag
[08:39] <ogra> master has at least support for 4.14
[08:39] <mvo> ogra: let me try to rev that
[08:41] <mvo> ogra: is the uboot v2017.05 version still good? or should this get an update as well?
[08:41] <ppisati> mvo: for the serial, what is the content of config.txt? do you have the 'enable_uart=1' line?
[08:42] <ogra> mvo, thats fine for 4.4 ... but i'm a bit confused .,... i merged ondra's https://github.com/snapcore/pi3-gadget/pull/15 and that sjhould have bumped use to 1.20170515 a while ago
[08:43] <mvo> ppisati: yeah, enable_uart=1 is set. but the firmware bits are pretty old, I'm trying to update those now first
[08:43] <ppisati> mvo: ack
[08:44] <ppisati> mvo: and you are using the dtb that comes with the kernel, right?
[08:44] <ogra> mvo, looks like our auto-builds are not working, i clearly see 1.20180417 in the git tree here https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml
[08:45] <mvo> ppisati: probably not, iirc the default is that those are put into the gadget still
[08:45] <ogra> ppisati, hah, the gadget indeed pulls the dtb out of the xenial-security deb
[08:45] <mvo> ogra: ok, I was looking at pi2 at this point
[08:45] <ogra> mvo, ah
[08:45] <ppisati> bionic kernel + xenial dtb = no good
[08:45] <ogra> mvo, really time to switch to the unified approach :P
[08:46] <ogra> mvo, i guess you need to manually copy the dtb around on the SD for testing
[08:47] <mvo> ogra, ppisati hm, if the dtbs must be part of the gadget we need a new gadget snap or a new track for the exiting pi2 gadget to work 4.15 kernel, right?
[08:47] <ogra> mvo, right
[08:48] <ogra> mvo, unless your and ondra's planning is far enough to have them updateable (i understand you guys discussed that)
[08:49] <mvo> ogra: it sounds like hte universal one is the most effective way forward for now, let me try that
[08:52] <ogra> mvo, it uses the new "build on" "run on" stuff for snapcraft, so if you build it, dont use --target-arch in the snapcraft call ... also, to see boot stuff on HDMI, drop "splash vt.handoff=2 and nogetty" from cmdline.txt
[08:57] <mvo> ogra: I forked it and started building it
[08:57] <mvo> ogra: will probably take a while, I keep you updated
[08:57] <ogra> 10min or so ...
[09:02] <mvo> ogra: psplash fails to build for me, its master it seems to maybe just a hickup, I disable it for now
[09:02] <ogra> mvo, ok
[09:03] <ogra> weird though ...
[09:03]  * ogra tries a build 
[09:03] <ogra> even master never changes :P
=== seb128_ is now known as seb128
[09:04] <mvo> yeah, I noticed that just now, 11month ago
[09:04] <ogra> mvo, are you building on bionic (i always build on xenial, perhaps thats the difference)
[09:04] <mvo> ogra: yeah, bionic
[09:05] <ogra> might be some build dep
[09:05] <mvo> ogra: http://paste.ubuntu.com/p/dJW7TTTzhZ/
[09:05] <ogra> oh, wow
[09:06] <mvo> ogra: heh, looks like psplash.patch is the culprit
[09:06] <mvo> ogra: what is it and where does it come from?
[09:06] <mvo> ogra: and do we need it :) ?
[09:07] <mvo> ogra: it looks like the patch either needs to rename radon-font.h to font.h or undo this
[09:07] <ogra> mvo, the gadget was made for kiosks so *it* needs it ... a normal gadget can indeed work witjhout psplash (though t would be great to have it because it exercises split-initrd ;) )
[09:07] <ogra> -		  psplash-poky-img.h psplash-bar-img.h radeon-font.h
[09:07] <ogra> +		  psplash-core-img.h psplash-bar-img.h font.h
[09:08] <ogra> that is what it does
[09:08] <ogra> and it builds here
[09:08] <mvo> ogra: yeah but there is no font.h in my parts dir, just radeon-font.h
[09:08] <ogra> https://paste.ubuntu.com/p/B74sVK8Hp2/
[09:09] <ogra> mvo,  - ttf-ubuntu-font-family is in build packages ... i suspect that name changed in bionic
[09:10] <ogra> font.h is generated IIRC
[09:10] <ogra>  ${TREE}/font-gen.sh "$FONT"
[09:11] <ogra> ogra@anubis:~/datengrab/appliances/pi-kiosk-gadget:master$ ls psplash/font-gen.sh
[09:11] <ogra> psplash/font-gen.sh
[09:11] <mvo> ogra: font-gen.sh was missing a set -e
[09:11] <mvo> ogra: now I see the error
[09:11] <ogra> mvo, there must be an error with font-gen.sh earlier in your build
[09:16] <ogra> mvo, whats the error, looking at the archive it seems all build deps are still there
[09:17] <ogra> oha ... ttf-ubuntu-font-family is an empty package !
[09:17] <ogra> https://packages.ubuntu.com/bionic/all/ttf-ubuntu-font-family/filelist
[09:17] <mvo> ogra: yeah, it can open the input file
[09:18] <ogra> right ... i wonder where Ubuntu-R.ttf moved in bionic
[09:18] <ogra> mvo, want a binary ? i have a built one here
[09:19] <mvo> ogra: thanks, appreciated. I dig a bit more, it looks like this will become the new gadget so it needs fixing at some point anyway
[09:21] <ogra> lp #851457
[09:21] <ogra> hmm, no ubottu
[09:22] <ogra> https://bugs.launchpad.net/ubuntu/+source/fonts-ubuntu/+bug/851457
[09:22] <ogra> mvo, seems "fonts-ubuntu" is the new name
[09:23] <ogra> https://launchpad.net/ubuntu/+source/fonts-ubuntu
[09:23] <mborzecki> another simple one https://github.com/snapcore/snapd/pull/5597
[09:25] <ogra> mvo, and the path in psplash/config needs to be adjusted to "/usr/share/fonts/truetype/ubuntu/"
[09:28] <ogra> mvo, here are some hints that should work: https://github.com/ogra1/pi-kiosk-gadget/commit/3ec65a9ea98e8479e1ee9f40331eadb741cf1e6e
[09:31] <mvo> ogra: yeah, I found this. now font-gen.sh is failing because I added set -e - the fun thing is that otf2bdf returns exit code 8 - because it bubbles up the result of the last fprintf call which happens to write 8 chars. this is a bit odd to say the least
[09:31] <ogra> lol
[09:31] <mborzecki> and another trivial review https://github.com/snapcore/snapd/pull/5598
[09:43] <mvo> ogra: same issues with universal gadget, pi3 prints gibberish (https://paste.ubuntu.com/p/CsmFxsvmN7/) and pi2 hangs at boot (https://paste.ubuntu.com/p/Df3TrFb69Z/) - the hang could be entropy related of course
[09:43] <mvo> ppisati: -^
[09:44] <ogra> mvo, but you did bump to the newer firmware ? like in https://github.com/ogra1/pi-kiosk-gadget/commit/3ec65a9ea98e8479e1ee9f40331eadb741cf1e6e
[09:46] <mvo> ogra: yeah, this is updated, but I noticed the dtbs are still from xenial, fixing this now
[09:46] <ogra> oh, indeed
[09:47] <mvo> ogra: https://github.com/mvo5/pi-gadget/commits/master has my bits, some probably worth cherry-picking too
[09:47] <ogra> (and who cares about serial anyway as long as you see a pretty splash screen during boot :P)
[09:48] <mvo> ogra: heh
[09:48] <ogra> mvo, will pull that in
[09:49] <mvo> ogra: hm, linux-image-4.15-....deb does no longer have any dtbs, just the kernel image, I guess some packaging changes
[09:49] <ogra> oh ... ppisati where did they go ? ^^^
[09:50] <mborzecki> need top drop by doggos off at the groomer, back in 15
[09:50] <mvo> ogra: looks like it moved to the movuldes package
[09:50] <ogra> oh, they are separate debs now
[09:51] <ogra> interesting
[09:58] <mvo> ogra: pi3 is booting now, not working but at least booting
[09:58] <ogra> yay
[09:58] <ogra> how is it not working
[09:59] <mvo> ogra: whats the most easy way to add "systemd.debug-shell=1" to the u-boot prompt cmdline?
[09:59] <mvo> ogra: seeding fails but I can't see how
[09:59] <ogra> mvo, system-boot/cmdline.txt
[09:59] <ogra> mvo, but i think that systemd debig shell doesnt support serial input
[09:59] <ogra> *debug
[10:00] <ogra> mvo, so you want to drop nogetty from the cmdline.txt too and use kbd/monitor
[10:00] <ogra> (and probably also turn off the splash)
[10:01] <ogra> (thats sadly a systemd shortcoming)
[10:01]  * mvo nods
[10:11] <mborzecki> glob := filepath.Join(dirs.SnapDesktopFilesDir, s.InstanceName()+"_*.desktop"), i sense trouble
[10:15] <ogra> pessimist :P
[10:19] <mvo> ogra: yay, its booting and seeding now with a bit of manual fiddling - it lookslike cloud-init is doing strange things in core18 at this point
[10:19] <ogra> awesome !
[10:20] <ogra> does core18 not disable cloud-init as it should ?
[10:20] <mvo> ogra: not yet
[10:20] <ogra> ah ... needs to :)
[10:21] <mvo> ogra: yeah
[10:21] <ogra> but good to hear the gadget works
[10:22] <mvo> yeah, I need to talk to gustavo but I'm inclined to make this the pi gadget/model for 18
[10:22] <ogra> \o/
[10:36] <ogra> mvo, i talked to the kernel team btw ... and they talked to the store guys ... apparently it isnt easily possible to rename pi2-kernel to just be pi-kernel (or to alias the name in the store)
[10:37] <ogra> and the kernel team douesnt want to maintain two snaps
[10:42] <mvo> ogra: yeah, renames are not done yet
[10:42] <mvo> ogra: its ok I think, not great but ok
[10:45] <ogra> yeah
[10:45] <ogra> just shows that we suck at picking names :)
[11:10] <mborzecki> and another easy win https://github.com/snapcore/snapd/pull/5599
[11:20] <Son_Goku> zyga, how are we doing on the demo for Flock?
[12:07] <Chipaca> huh,  the single biggest .a file is from asserts
[12:07] <mvo> Chipaca: interessting, crypto code?
[12:07] <mvo> Chipaca: initialization tables and all that?
[12:08] <Chipaca> mvo: wouldn't that be in its respective .a?
[12:09] <mvo> Chipaca: maybe stuff like htis https://github.com/golang/go/blob/master/src/crypto/sha512/sha512block.go#L5 but its just a guess
[12:09] <mvo> (a very wild one too!)
[12:09] <mvo> Chipaca: probably nonsese, not nearly big enough
[12:11] <Chipaca> mvo: 66K	/snap/go/current/pkg/linux_amd64/crypto/sha512.a
[12:11] <mvo> Chipaca: yeah, probably not it - how big is asserts.a?
[12:11] <Chipaca> crypto/tls is bigger
[12:11] <Chipaca> mvo: 2.5M
[12:12] <Chipaca> that's not a small difference :-)
[12:12] <Chipaca> might be stripped vs non-stripped though
[12:12] <Chipaca> dunno
[12:12] <Chipaca> just found msyelf pondering if there'd be an easy way of getting a handlde on how much each package contributed to snapd's size
[12:20] <mvo> Chipaca: interessting
[12:20] <Chipaca> mvo: bolt is 408k for ex
[12:21] <mvo> Chipaca: nice
[12:21] <Chipaca> anyhow. I should either take a nap, or get more coffee
[12:21] <mvo> Chipaca, mborzecki I had fun as well: https://github.com/jirutka/otf2bdf/pull/1
[12:21] <Chipaca> i was typing irc into the browser
[12:21] <mvo> Chipaca: haha
[12:22] <mvo> Chipaca: quick nap should be fine :)
[12:22] <mvo> Chipaca, mborzecki if the patch makes sense I will upload this to cosmic
[12:22] <mborzecki> wow
[12:22]  * Chipaca hugs  mvo 
[12:22] <Chipaca> mvo: why u writing c again
[12:22] <mvo> Chipaca: because I love it
[12:22] <mborzecki> mvo likes the grumpy feels
[12:23]  * Chipaca calls the police
[12:23] <mvo> Chipaca: just kidding, necessity is the mother of invention?
[12:23] <mvo> Chipaca: haha - the C-police
[12:23] <mvo> mborzecki: yeah, I was too happy in the morning
[12:23] <Chipaca> "this pull request rewrites the whole project in go and python because you had this bug"
[12:23] <mborzecki> da sound of c-police
[12:23] <mvo> mborzecki: actually not, I need to dive into cloud-init on core18 and I don't want to :/ I need some extra strong tea for that
[12:24] <mvo> Chipaca: lol (https://www.thinkgeek.com/product/374d/  - also not funny anymore these days)
[12:24] <mvo> or maybe, I guess very small shell scripts are still ok
[12:25] <mborzecki> mvo: as long as you don't quote and don't use redirects
[12:28] <Chipaca> mvo: necessity is the mother of grumpiness. Grumpiness might then father invention. Or war.
[12:29]  * Chipaca has cold coffee and hope
[12:42] <Chipaca> why would you need a kernel module to make a backup of a btrfs partition?
[12:54] <ogra> heh, i was wondering the same
[12:54] <Chipaca> ogra: it might be https://github.com/datto/dattobd
[12:55] <ogra> so it intercepts all write operations ? ... what could possibly go wrong :P
[12:55] <Chipaca> ogra: and it creates /proc/datto-info which is JSON
[12:55] <Chipaca> I'd ban it just based on that
[12:56] <ogra> "although filesystems with their own block device management systems such as ZFS and BTRFS can not be supported"
[12:56] <ogra> so probably not that
[13:01] <pbek> I wrote a hosts-file switcher https://github.com/pbek/hswitch that generates an /etc/hosts file. It needs to be an as root (which doesn't seem to work with the snapped version of hswitch) and needs to write to the hosts file. is that reason enough to ask for classic confinement in the snap store?
[13:01] <pbek> *ran
[13:04] <ogra> pbek, theoretically i'd expect this file to be accessible through the network-control interface, but seems it is not ... perhaps jdstrand would add access to it there though
[13:06] <ogra> i'd start a post on the forum about it
[13:06] <pbek> thank you ogra, so should I apply for classic confinement? I got the message " If your snap needs classic confinement to function, please make a request for this snap to use classic by creating a new topic in the forum using the 'store' category and detail the technical reasons why classic is required.". Do you know where that forum is duckduckgo/google couldn't help me and I dodn't find it on https://ubuntuforums.org/
[13:08] <ogra> well, classic is generally a bad idea if there is any chance to instead extend an existing interface or cover the needed task with a new interface, so i'd first ask if there is a possibility to allow write access to /etc/hosts through one of the interfaces ...
[13:08] <cjwatson> there's a link to the forum in the topic
[13:08] <ogra> if there isnt, classic is surely a possible fall-back
[13:09] <ogra> jdstrand, could we add a forum link to that review-tools message above ?
[13:18] <pbek> thank you for your help ogra and cjwatson. I wrote a post now on https://forum.snapcraft.io/t/writing-to-etc-hosts/6651
[13:18] <ogra> yup, i saw it popping up in the forum :)
[13:25] <Chipaca> mmm, hosts-control sounds good to me
[13:27] <ogra> well, i guess hostname-control would work too ...
[13:31] <Chipaca> ogra: hostname-control already exists though
[13:32] <Chipaca> ogra: and it's not clear that granting one should grant the other (and bicerveza)
[13:32] <ogra> yeah and sets the hostname ...
[13:32] <Chipaca> but, totally jdstrand land :-)
[13:32] <ogra> given that local name resolution for the host happens in /etc/hosts it might or might not be a avlid place to have /etc/hosts writable
[13:32] <ogra> *valid
[13:33] <ogra> so it could perhaps be extended instead of having a complete new interface
[13:33] <ogra> yeah, totally :)
[13:35] <jdstrand> otoh, /etc/hosts is quite different from hostname-control. /etc/hosts is about static name resolution and hostname-control is about the system hostname. sure, the system hostname is included in /etc/hosts, but for different reasons
[13:37] <ogra> yeah
[13:39] <Caelum> was just trying the gentoo overlay, I get this when installing spotify: - Fetch and check assertions for snap "spotify" (16) (parsing assertion headers: expected 4 chars nesting prefix after multiline introduction "slots:": "  mpris:")
[13:39] <jdstrand> ogra, pbek: the review-tools actually have a link and the store shows it
[13:40] <jdstrand> pbek: where did you see the message? snapcraft?
=== Guest35472 is now known as jero
[13:56] <jdstrand> mvo: hey, are there core18 images that can be used in a VM for some testing?
[13:56] <jdstrand> core18-based images...
[13:58] <mvo> jdstrand: not quite, I hope to get something ready today though, I can upload some snapshot if you want to test something specific now
[14:02] <Chipaca> mvo: if ubuntu moves to require xattrs, will that impact core18, or only from core20?
[14:03] <Chipaca> Caelum: where do you get that?
[14:03] <Chipaca> Caelum: is the 'gentoo overlay' the way you can use snapd from gentoo?
[14:04] <Chipaca> Caelum: what's the output of 'snap version'?
[14:05] <mvo> Chipaca: as long as bionic does not requuire them yet I think we are fine until core20
[14:05] <mvo> Chipaca: where is this discussed?
[14:05] <Chipaca> mvo: ubuntu-devel, 'RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps'
[14:06] <Chipaca> mvo: mtr uses caps in 16.04 already
[14:07] <Chipaca> mvo: in fact so does /usr/bin/systemd-detect-virt
[14:08] <jdstrand> mvo: what I'm thinking about is the socketcall multiplexer in the default template. I'd like that to go away and a core18 image seems like a way to do that
[14:09] <jdstrand> mvo: that said, I'm not completely sure how to achieve it. you need a new enough kernel and a new enough glibc
[14:10] <jdstrand> mvo: I don't have the details of which otoh, but assuming I had that, I could system-key the kernel bit easy enough, but would need to figure out the base snap in use I guess. then, how to know the difference between a core16 device and a core18 device?
[14:11] <Chipaca> jdstrand: and snaps using core16 on a core18 device?
[14:12] <Chipaca> jdstrand: you should be hearing https://www.youtube.com/watch?v=ZI6Qgvy33Uc about now
[14:12] <jdstrand> Chipaca: well, my assumption was I could look at snap_info to see if a base snap was specified. I could then say 'if !core16...'. I wasn't sure how to figure out the default for the system though
[14:13] <jdstrand> hehe
[14:13] <Chipaca> jdstrand: ah, so if the kernel were new enough, you'd make this per-snap?
[14:14] <jdstrand> how is that supposed to work actually. if I have a snap that was built for xenial that doesn't specify a base, and install it on a core18 device, what does the core18 device do?
[14:14] <mvo> jdstrand: snapstate can access "Model()" which can then check for model.Base() but I guess thats not ideal, ideally we would check based on some introspection of libc/kernel, no?
[14:14] <jdstrand> Chipaca: I think so
[14:14] <jdstrand> mvo: the kernel bit is easy since we already do that and that isn't subject to change
[14:15] <mvo> jdstrand: when you build a xenial snap and install it on a core18 device it will pull in core as the base and run it inside the core environment (effectively core16)
[14:15] <jdstrand> mvo: so from now until the end of time you'll have to specify a base snap for anything other than core16?
[14:16] <Caelum> Chipaca: the overlay is https://github.com/zyga/gentoo-snappy the version of snapd is 2.15.2
[14:16] <jdstrand> ie, not specifying base will always get you core16?
[14:16] <Caelum> I guess that's really old
[14:16] <Caelum> and the overlay needs to be updated
[14:16] <Caelum> I'll work with zyga on that
[14:17] <Chipaca> Caelum: yeah. Error could be better though.
[14:17] <Chipaca> Caelum: i thought somebody was looking at gentoo recently, but not sure who
[14:17] <Chipaca> maybe it was you :-)
[14:17] <Caelum> nah not me, I just barely got it installed
[14:17] <mvo> jdstrand: we want to transition people gently with snapcraft
[14:17] <mvo> jdstrand: i.e. warn (or add core16) as the base when nothing is specified
[14:18] <Caelum> I was going to help zyga get snapd into the main opensuse repos too
[14:18] <Caelum> dunno how that all went
[14:18] <jdstrand> mvo: sure, but what I'm getting at is that if a base snap is not specified in the snap.yaml, you'll always default to core16?
[14:18] <Chipaca> Caelum: the person I'd ask about this _just_ EOWed
[14:18] <Chipaca> Caelum: (the might've seen you asking and made a runner)
[14:18] <jdstrand> cause then I could do 'if not specified or is core or is core16...' or something
[14:19] <Chipaca> s/made/done/
[14:19] <jdstrand> mvo: ^
[14:19] <mvo> jdstrand: yes
[14:19] <mvo> jdstrand: but note that people might use "base: fedora-core" or whatnot in the (near) future
[14:19] <Chipaca> base: bo
[14:20] <jdstrand> yeah
[14:21] <jdstrand> I didn't really want to have to if core18 or fedore-core or core20 or core22 or core24 or arch-core or...'
[14:21] <jdstrand> but I might have to
[14:21] <jdstrand> I guess we could peek at the libc6.so in /snap/<base>/<current> but youchie
[14:22] <jdstrand> yowchie
[14:22]  * jdstrand likes to make sure he spells his made up words correctly
[14:23] <ogra> heh
[14:23] <jdstrand> mvo: I could just check the kernel and arch. that would, for example, at least remove it for amd64. hmm, but compat mode..
[14:24] <jdstrand> mvo: do you have other ideas on how to migrate away from it?
[14:25] <mvo> jdstrand: hm, hm, there is no way to introspect libc somehow I guess?
[14:25] <jdstrand> actually, socketcall doesn't exist on amd64 or arm
[14:26] <jdstrand> mvo: well, but which one? I mean, the snap isn't going to get the one on the system on a core18 device with a base: core16 snap
[14:26] <mvo> jdstrand: could we look at the base and look at the bases filesystem when we generate the apparmor profiles?
[14:27] <mvo> jdstrand: or maybe we can add hints to the bases, we talked about this before
[14:27] <mvo> jdstrand: hints like "you need these special confinement rules"
[14:28] <jdstrand> mvo: possibly, but I don't think libc6.so is guaranteed to be in the same place
[14:28] <jdstrand> I mean, on base: bo and base: core16 it won't be (multiarch), let alone fedora-core
[14:28] <mvo> jdstrand: yeah, its a rathole, the code would have to inspect the elf file(s) :/
[14:29] <jdstrand> mvo: let me get completely up to speed on the conditions that would guarantee where it can be removed
[14:30] <jdstrand> mvo: maybe that will give some more details for inspiration
[14:30] <mvo> jdstrand: ok, its also friday afternoon for me, so I'm not 100% fresh  :)
[14:30] <mvo> jdstrand: so I'm probably also lacking inspiration
[14:31] <jdstrand> mvo: sure. assuming we can come up with something reasonable, is this something you'd be willing to accept for core18 devices?
[14:31] <jdstrand> mvo: or is it too late to make this type of change?
[14:31] <Chipaca> mvo: jdstrand: we could have a .yaml for bases that described things
[14:31] <jdstrand> Chipaca: that might be useful for more than just this
[14:32] <Chipaca> mhmm
[14:32] <mvo> mwhudson: just in case you are around, I get the following error on the pi3 with core18: https://paste.ubuntu.com/p/7rFKyY5Zbs/ when running console-conf
[14:33] <mvo> mwhudson: the generated netplan yaml: http://paste.ubuntu.com/p/pQ8W9544cw/
[14:33] <mvo> jdstrand, Chipaca yeah, some meta data would be fine - we just need blessing from gustavo but I think its not too late for this
[14:34] <mvo> sil2100: hey, great to have you around - I have questions :) I get the following error on the pi3 with core18: https://paste.ubuntu.com/p/7rFKyY5Zbs/ when running console-conf the generated netplan yaml: http://paste.ubuntu.com/p/pQ8W9544cw/  any ideas?
[14:35] <jdstrand> mvo: we could infer from the base snap name though. that would be simple. eg, 'if kernel >4.3 and base in [core18, fedora-core]: don't add socketcall'
[14:35] <jdstrand> mvo: that would at least separate the need for said base.yaml
[14:36] <jdstrand> mvo: and if it that yaml was interesting enough on its own, we could modify this check for it
[14:37] <jdstrand> mvo: we still aren't expecting a huge number of bases, right? that said, even if we did, we don't *today* and an internal list is a fast way to get socketcall out
[14:37] <jdstrand> and we could refine that check going forward
[14:40] <mvo> jdstrand: yeah, today checking for core18 is fine
[14:40] <mvo> jdstrand: and when we get new bases we just add them there
[14:41] <Chipaca> it'd have to be a very long list to be slower than parsing yaml :-)
[14:45] <mvo> Chipaca: heh :)
[14:45] <mvo> Chipaca: I guess what might be slow is that snapd will need updates for new bases but I guess thats ok
[14:46] <Chipaca> this is for a generated file, that somebody could tweak by hand for development/
[14:46] <Chipaca> ?
[14:50] <sil2100> mvo: hey! Let me take a look
[14:50] <Chipaca> mup: are you back?
[14:51] <Chipaca> i guess no
[14:53] <mvo> Chipaca: no, very sad
[14:56] <mvo> sil2100: I also removed (temporarily?) cloud-init from core18 as it was interfering with the pi boots
[14:56] <mvo> sil2100: we should probably talk next week aobut this :)
[14:56] <mvo> sil2100: and congrats for the 16.04.5 releass btew
[14:56] <mvo> sil2100: btw
[15:00] <Chipaca> Son_Goku: zyga is away
[15:01] <Chipaca> Son_Goku: (i saw you ask him something earlier)
[15:01] <Chipaca> Son_Goku: should be reachable on telegram though
[15:01] <Son_Goku> ah
[15:03] <Son_Goku> Chipaca, what's his name on Telegram?
[15:03] <Chipaca> Son_Goku: pm
[15:03] <Son_Goku> ok
[15:04] <Chipaca> Son_Goku: on irc, i meant :-)
[15:06] <sil2100> mvo: thanks! Yeah, let's do that - btw. good that you're testing this on pi3 as well, do you know if there was anyone looking at core18 on arm64 hardware? (since I suppose the pi3 you're testing on is the armhf one, right?)
[15:07] <sil2100> mvo: as for the netplan issue, I wonder why it's only a problem now! set-name requires match: since like 2 years IIRC
[15:07] <mvo> sil2100: I don't have arm64 hardware but cachio has, he is keen to test it. but I guess there will be some work, hte pi2,pi3 required dtb updates
[15:07] <mvo> sil2100: no idea :) it also works on my amd64 VM
[15:07] <mvo> sil2100: it just happens on my pi3 test image
[15:08] <sil2100> huh, let me dive into that
[15:08] <sil2100> mvo: awesome
[15:10] <mvo> sil2100: thank you, I can make hte image available if that helps
[15:11] <Chipaca> jdstrand: quesiton about a denial
[15:11] <Chipaca> jdstrand: [  512.654826] audit: type=1400 audit(1533308845.960:41): apparmor="DENIED" operation="capable" profile="snap.test-snapd-hostname-control.sh" pid=948 comm="hostnamectl" capability=12  capname="net_admin"
[15:12] <Chipaca> jdstrand: that's what I get when I try to run 'hostnamectl', in 18.04, from a snap that's got hostname-control
[15:13] <Chipaca> jdstrand: but only if it's got to start the dbus wotsit
[15:13] <Chipaca> if it's already running, it works
[15:13] <Chipaca> when I say 'in 18.04' I do _not_ mean core18, fwiw
[15:15] <Chipaca> the dbus wotsit is /lib/systemd/systemd-hostnamed fwiw
[15:15] <Chipaca> cachio: ^ this is why your hostname-control PR is red
[15:16] <cachio> Chipaca, ahhh
[15:16] <cachio> nice
[15:16] <Chipaca> cachio: good on you for catching this
[15:17] <cachio> Chipaca, thanks
[15:17] <ogra> mvo, sil2100, note that we set net.ifnames=0 in core images (and thats essential) perhaps netplan is unhappy about that one ?
[15:18] <ogra> (thogh i guess that wouldnt be device/board specific )
[15:21] <sil2100> mvo: interesting, console-conf for an amd64 doesn't spit out set-name: eth0
[15:22] <sil2100> mvo: when you think about it, he shouldn't, I guess I'll take a look what causes that
[15:22] <sil2100> (anyway, looking at it!)
[15:23] <jdstrand> Chipaca, cachio: I suspect something is falling back to sethostname()
[15:24] <Chipaca> jdstrand: this is running  'hostnamectl' on its own, which shouldn't be setting anything (it just prints something afaik)
[15:24] <Chipaca> jdstrand: https://github.com/snapcore/snapd/pull/5593 if you want to repro this yourself
[15:24] <Chipaca> anyhoo, i need to run
[15:24] <Chipaca> ttfn
[15:27] <jdstrand> cachio: it's possible that if the service isn't running, hostnamectl is using setsockopt with particular options that need net_admin. see man 7 capabilities (I haven't investigated this)
[15:28] <sil2100> mvo: btw. I'm preparing and testing a new subiquity for core18 based on what's in git, if it turns out to be good I guess I could push it to ppa:snappy-dev/image
[15:29] <sil2100> (with all the console-conf fixes and branding changes)
[15:29] <cachio> jdstrand, I'll check that
[15:30] <mvo> sil2100: sounds good, we may need to tweak the build to pull from the ppa, iirc right now we only pull from the main archive
[15:32] <sil2100> Yeah, the subiquity in the archives didn't get any uploads in ages, so I want to test this here locally first (building in my PPA)
[15:33] <mvo> sil2100: *nod*
=== abeato is now known as abeato-away
[20:48] <kyrofa> When I `sudo snap install --revision=<blah>` it always says "installing <revision> from stable"
[20:48] <kyrofa> This is released to no channel
=== ads20000_ is now known as ads20000
[20:57] <kyrofa> noise][, I've been waiting 10 minutes for a review to even start. Things are starting to queue up
[20:58] <kyrofa> Are there issues, or just increased load?
[20:58] <kyrofa> Ah, one finally happened. Must just be load