/srv/irclogs.ubuntu.com/2018/08/03/#snappy.txt

=== chihchun_afk is now known as chihchun
mborzeckimorning05:13
Chipacamborzecki: morning05:26
mborzeckiChipaca: hey, i see there's a PR to spread https://github.com/snapcore/spread/pull/6705:27
Chipacamborzecki: yup05:28
* Chipaca changing locations05:49
=== chihchun is now known as chihchun_afk
mvomborzecki: do you think you could have a look at 5592?07:02
mborzeckimvo: hi, i'm going through it now07:02
mvomborzecki: yay, thank you! once that is in I hop eI can build a first beta(ish) image07:03
mborzeckinot sure we can do anything about remaining reviews at this point07:15
mvomborzecki: yeah, it looks like the other reviews are all blocked in one way or the other07:21
mvomborzecki: did you write more? I got disconnected so may have missed bits07:22
mborzeckimvo: nope07:23
Chipacahello again07:27
mvohey Chipaca07:33
mborzeckiChipaca: welcome back07:34
mborzeckihmm noticed that experimental.parallel-instances has no effect when doing install from file :(07:35
mborzeckineed moar coffee08:02
mvoogra: 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
mvo08:13
mvoogra: and then lots of these: �f��~��� screenfulls. but the uboot messages are all normal08:13
mvoppisati: -^08:14
ogramvo, yes08:29
mvoogra, ppisati pi2 with 4.15 show kernel boot message but shows https://paste.ubuntu.com/p/Zq9wqg3qfF/ and hangs08:29
mvoogra: so we need a new/updated gadget in any case? what does need to change?08:29
ograoh, wait, not sure about just 4.15 (4.15 on pi3 B+ needs new gadget stuff)08:30
ogramvo, but it is likely we need new blobs all over since they are always built for a certain kernel vetrsion08:31
ogra(they are backwards compatible so it should be fine to update and keep 4.4 working)08:31
mvoogra: ok08:32
mvoogra: I guess raspberrypi/firmware git repo is the place?08:33
ogramvo, try my universal gadget, it pulls new FW during build08:33
mvoogra: ok08:33
ogra(was needed for cm3)08:33
ograhttps://github.com/ogra1/pi-kiosk-gadget08:34
ograoh, wait, it doesnt08:34
ogradamn08:34
ogramvo, you actually want master from https://github.com/raspberrypi/firmware, all stable versions point to 4.908:38
mvoogra: yeah, looks like we are pulling from the 201705xx tag08:39
ogramaster has at least support for 4.1408:39
mvoogra: let me try to rev that08:39
mvoogra: is the uboot v2017.05 version still good? or should this get an update as well?08:41
ppisatimvo: for the serial, what is the content of config.txt? do you have the 'enable_uart=1' line?08:41
ogramvo, 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 ago08:42
mvoppisati: yeah, enable_uart=1 is set. but the firmware bits are pretty old, I'm trying to update those now first08:43
ppisatimvo: ack08:43
ppisatimvo: and you are using the dtb that comes with the kernel, right?08:44
ogramvo, 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.yaml08:44
mvoppisati: probably not, iirc the default is that those are put into the gadget still08:45
ograppisati, hah, the gadget indeed pulls the dtb out of the xenial-security deb08:45
mvoogra: ok, I was looking at pi2 at this point08:45
ogramvo, ah08:45
ppisatibionic kernel + xenial dtb = no good08:45
ogramvo, really time to switch to the unified approach :P08:45
ogramvo, i guess you need to manually copy the dtb around on the SD for testing08:46
mvoogra, 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
ogramvo, right08:47
ogramvo, unless your and ondra's planning is far enough to have them updateable (i understand you guys discussed that)08:48
mvoogra: it sounds like hte universal one is the most effective way forward for now, let me try that08:49
ogramvo, 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.txt08:52
mvoogra: I forked it and started building it08:57
mvoogra: will probably take a while, I keep you updated08:57
ogra10min or so ...08:57
mvoogra: psplash fails to build for me, its master it seems to maybe just a hickup, I disable it for now09:02
ogramvo, ok09:02
ograweird though ...09:03
* ogra tries a build 09:03
ograeven master never changes :P09:03
=== seb128_ is now known as seb128
mvoyeah, I noticed that just now, 11month ago09:04
ogramvo, are you building on bionic (i always build on xenial, perhaps thats the difference)09:04
mvoogra: yeah, bionic09:04
ogramight be some build dep09:05
mvoogra: http://paste.ubuntu.com/p/dJW7TTTzhZ/09:05
ograoh, wow09:05
mvoogra: heh, looks like psplash.patch is the culprit09:06
mvoogra: what is it and where does it come from?09:06
mvoogra: and do we need it :) ?09:06
mvoogra: it looks like the patch either needs to rename radon-font.h to font.h or undo this09:07
ogramvo, 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.h09:07
ogra+  psplash-core-img.h psplash-bar-img.h font.h09:07
ograthat is what it does09:08
ograand it builds here09:08
mvoogra: yeah but there is no font.h in my parts dir, just radeon-font.h09:08
ograhttps://paste.ubuntu.com/p/B74sVK8Hp2/09:08
ogramvo,  - ttf-ubuntu-font-family is in build packages ... i suspect that name changed in bionic09:09
ografont.h is generated IIRC09:10
ogra ${TREE}/font-gen.sh "$FONT"09:10
ograogra@anubis:~/datengrab/appliances/pi-kiosk-gadget:master$ ls psplash/font-gen.sh09:11
ograpsplash/font-gen.sh09:11
mvoogra: font-gen.sh was missing a set -e09:11
mvoogra: now I see the error09:11
ogramvo, there must be an error with font-gen.sh earlier in your build09:11
ogramvo, whats the error, looking at the archive it seems all build deps are still there09:16
ograoha ... ttf-ubuntu-font-family is an empty package !09:17
ograhttps://packages.ubuntu.com/bionic/all/ttf-ubuntu-font-family/filelist09:17
mvoogra: yeah, it can open the input file09:17
ograright ... i wonder where Ubuntu-R.ttf moved in bionic09:18
ogramvo, want a binary ? i have a built one here09:18
mvoogra: thanks, appreciated. I dig a bit more, it looks like this will become the new gadget so it needs fixing at some point anyway09:19
ogralp #85145709:21
ograhmm, no ubottu09:21
ograhttps://bugs.launchpad.net/ubuntu/+source/fonts-ubuntu/+bug/85145709:22
ogramvo, seems "fonts-ubuntu" is the new name09:22
ograhttps://launchpad.net/ubuntu/+source/fonts-ubuntu09:23
mborzeckianother simple one https://github.com/snapcore/snapd/pull/559709:23
ogramvo, and the path in psplash/config needs to be adjusted to "/usr/share/fonts/truetype/ubuntu/"09:25
ogramvo, here are some hints that should work: https://github.com/ogra1/pi-kiosk-gadget/commit/3ec65a9ea98e8479e1ee9f40331eadb741cf1e6e09:28
mvoogra: 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 least09:31
ogralol09:31
mborzeckiand another trivial review https://github.com/snapcore/snapd/pull/559809:31
mvoogra: 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 course09:43
mvoppisati: -^09:43
ogramvo, but you did bump to the newer firmware ? like in https://github.com/ogra1/pi-kiosk-gadget/commit/3ec65a9ea98e8479e1ee9f40331eadb741cf1e6e09:44
mvoogra: yeah, this is updated, but I noticed the dtbs are still from xenial, fixing this now09:46
ograoh, indeed09:46
mvoogra: https://github.com/mvo5/pi-gadget/commits/master has my bits, some probably worth cherry-picking too09:47
ogra(and who cares about serial anyway as long as you see a pretty splash screen during boot :P)09:47
mvoogra: heh09:48
ogramvo, will pull that in09:48
mvoogra: hm, linux-image-4.15-....deb does no longer have any dtbs, just the kernel image, I guess some packaging changes09:49
ograoh ... ppisati where did they go ? ^^^09:49
mborzeckineed top drop by doggos off at the groomer, back in 1509:50
mvoogra: looks like it moved to the movuldes package09:50
ograoh, they are separate debs now09:50
ograinteresting09:51
mvoogra: pi3 is booting now, not working but at least booting09:58
ograyay09:58
ograhow is it not working09:58
mvoogra: whats the most easy way to add "systemd.debug-shell=1" to the u-boot prompt cmdline?09:59
mvoogra: seeding fails but I can't see how09:59
ogramvo, system-boot/cmdline.txt09:59
ogramvo, but i think that systemd debig shell doesnt support serial input09:59
ogra*debug09:59
ogramvo, so you want to drop nogetty from the cmdline.txt too and use kbd/monitor10:00
ogra(and probably also turn off the splash)10:00
ogra(thats sadly a systemd shortcoming)10:01
* mvo nods10:01
mborzeckiglob := filepath.Join(dirs.SnapDesktopFilesDir, s.InstanceName()+"_*.desktop"), i sense trouble10:11
ograpessimist :P10:15
mvoogra: yay, its booting and seeding now with a bit of manual fiddling - it lookslike cloud-init is doing strange things in core18 at this point10:19
ograawesome !10:19
ogradoes core18 not disable cloud-init as it should ?10:20
mvoogra: not yet10:20
ograah ... needs to :)10:20
mvoogra: yeah10:21
ograbut good to hear the gadget works10:21
mvoyeah, I need to talk to gustavo but I'm inclined to make this the pi gadget/model for 1810:22
ogra\o/10:22
ogramvo, 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:36
ograand the kernel team douesnt want to maintain two snaps10:37
mvoogra: yeah, renames are not done yet10:42
mvoogra: its ok I think, not great but ok10:42
ograyeah10:45
ograjust shows that we suck at picking names :)10:45
mborzeckiand another easy win https://github.com/snapcore/snapd/pull/559911:10
Son_Gokuzyga, how are we doing on the demo for Flock?11:20
Chipacahuh,  the single biggest .a file is from asserts12:07
mvoChipaca: interessting, crypto code?12:07
mvoChipaca: initialization tables and all that?12:07
Chipacamvo: wouldn't that be in its respective .a?12:08
mvoChipaca: maybe stuff like htis https://github.com/golang/go/blob/master/src/crypto/sha512/sha512block.go#L5 but its just a guess12:09
mvo(a very wild one too!)12:09
mvoChipaca: probably nonsese, not nearly big enough12:09
Chipacamvo: 66K/snap/go/current/pkg/linux_amd64/crypto/sha512.a12:11
mvoChipaca: yeah, probably not it - how big is asserts.a?12:11
Chipacacrypto/tls is bigger12:11
Chipacamvo: 2.5M12:11
Chipacathat's not a small difference :-)12:12
Chipacamight be stripped vs non-stripped though12:12
Chipacadunno12:12
Chipacajust found msyelf pondering if there'd be an easy way of getting a handlde on how much each package contributed to snapd's size12:12
mvoChipaca: interessting12:20
Chipacamvo: bolt is 408k for ex12:20
mvoChipaca: nice12:21
Chipacaanyhow. I should either take a nap, or get more coffee12:21
mvoChipaca, mborzecki I had fun as well: https://github.com/jirutka/otf2bdf/pull/112:21
Chipacai was typing irc into the browser12:21
mvoChipaca: haha12:21
mvoChipaca: quick nap should be fine :)12:22
mvoChipaca, mborzecki if the patch makes sense I will upload this to cosmic12:22
mborzeckiwow12:22
* Chipaca hugs mvo 12:22
Chipacamvo: why u writing c again12:22
mvoChipaca: because I love it12:22
mborzeckimvo likes the grumpy feels12:22
* Chipaca calls the police12:23
mvoChipaca: just kidding, necessity is the mother of invention?12:23
mvoChipaca: haha - the C-police12:23
mvomborzecki: yeah, I was too happy in the morning12:23
Chipaca"this pull request rewrites the whole project in go and python because you had this bug"12:23
mborzeckida sound of c-police12:23
mvomborzecki: actually not, I need to dive into cloud-init on core18 and I don't want to :/ I need some extra strong tea for that12:23
mvoChipaca: lol (https://www.thinkgeek.com/product/374d/  - also not funny anymore these days)12:24
mvoor maybe, I guess very small shell scripts are still ok12:24
mborzeckimvo: as long as you don't quote and don't use redirects12:25
Chipacamvo: necessity is the mother of grumpiness. Grumpiness might then father invention. Or war.12:28
* Chipaca has cold coffee and hope12:29
Chipacawhy would you need a kernel module to make a backup of a btrfs partition?12:42
ograheh, i was wondering the same12:54
Chipacaogra: it might be https://github.com/datto/dattobd12:54
ograso it intercepts all write operations ? ... what could possibly go wrong :P12:55
Chipacaogra: and it creates /proc/datto-info which is JSON12:55
ChipacaI'd ban it just based on that12:55
ogra"although filesystems with their own block device management systems such as ZFS and BTRFS can not be supported"12:56
ograso probably not that12:56
pbekI 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*ran13:01
ograpbek, 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 though13:04
ograi'd start a post on the forum about it13:06
pbekthank 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:06
ograwell, 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
cjwatsonthere's a link to the forum in the topic13:08
ograif there isnt, classic is surely a possible fall-back13:08
ograjdstrand, could we add a forum link to that review-tools message above ?13:09
pbekthank you for your help ogra and cjwatson. I wrote a post now on https://forum.snapcraft.io/t/writing-to-etc-hosts/665113:18
ograyup, i saw it popping up in the forum :)13:18
Chipacammm, hosts-control sounds good to me13:25
ograwell, i guess hostname-control would work too ...13:27
Chipacaogra: hostname-control already exists though13:31
Chipacaogra: and it's not clear that granting one should grant the other (and bicerveza)13:32
ograyeah and sets the hostname ...13:32
Chipacabut, totally jdstrand land :-)13:32
ogragiven that local name resolution for the host happens in /etc/hosts it might or might not be a avlid place to have /etc/hosts writable13:32
ogra*valid13:32
ograso it could perhaps be extended instead of having a complete new interface13:33
ograyeah, totally :)13:33
jdstrandotoh, /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 reasons13:35
ograyeah13:37
Caelumwas 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
jdstrandogra, pbek: the review-tools actually have a link and the store shows it13:39
jdstrandpbek: where did you see the message? snapcraft?13:40
=== Guest35472 is now known as jero
jdstrandmvo: hey, are there core18 images that can be used in a VM for some testing?13:56
jdstrandcore18-based images...13:56
mvojdstrand: not quite, I hope to get something ready today though, I can upload some snapshot if you want to test something specific now13:58
Chipacamvo: if ubuntu moves to require xattrs, will that impact core18, or only from core20?14:02
ChipacaCaelum: where do you get that?14:03
ChipacaCaelum: is the 'gentoo overlay' the way you can use snapd from gentoo?14:03
ChipacaCaelum: what's the output of 'snap version'?14:04
mvoChipaca: as long as bionic does not requuire them yet I think we are fine until core2014:05
mvoChipaca: where is this discussed?14:05
Chipacamvo: ubuntu-devel, 'RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps'14:05
Chipacamvo: mtr uses caps in 16.04 already14:06
Chipacamvo: in fact so does /usr/bin/systemd-detect-virt14:07
jdstrandmvo: 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 that14:08
jdstrandmvo: that said, I'm not completely sure how to achieve it. you need a new enough kernel and a new enough glibc14:09
jdstrandmvo: 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:10
Chipacajdstrand: and snaps using core16 on a core18 device?14:11
Chipacajdstrand: you should be hearing https://www.youtube.com/watch?v=ZI6Qgvy33Uc about now14:12
jdstrandChipaca: 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 though14:12
jdstrandhehe14:13
Chipacajdstrand: ah, so if the kernel were new enough, you'd make this per-snap?14:13
jdstrandhow 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
mvojdstrand: 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
jdstrandChipaca: I think so14:14
jdstrandmvo: the kernel bit is easy since we already do that and that isn't subject to change14:14
mvojdstrand: 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
jdstrandmvo: so from now until the end of time you'll have to specify a base snap for anything other than core16?14:15
CaelumChipaca: the overlay is https://github.com/zyga/gentoo-snappy the version of snapd is 2.15.214:16
jdstrandie, not specifying base will always get you core16?14:16
CaelumI guess that's really old14:16
Caelumand the overlay needs to be updated14:16
CaelumI'll work with zyga on that14:16
ChipacaCaelum: yeah. Error could be better though.14:17
ChipacaCaelum: i thought somebody was looking at gentoo recently, but not sure who14:17
Chipacamaybe it was you :-)14:17
Caelumnah not me, I just barely got it installed14:17
mvojdstrand: we want to transition people gently with snapcraft14:17
mvojdstrand: i.e. warn (or add core16) as the base when nothing is specified14:17
CaelumI was going to help zyga get snapd into the main opensuse repos too14:18
Caelumdunno how that all went14:18
jdstrandmvo: 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
ChipacaCaelum: the person I'd ask about this _just_ EOWed14:18
ChipacaCaelum: (the might've seen you asking and made a runner)14:18
jdstrandcause then I could do 'if not specified or is core or is core16...' or something14:18
Chipacas/made/done/14:19
jdstrandmvo: ^14:19
mvojdstrand: yes14:19
mvojdstrand: but note that people might use "base: fedora-core" or whatnot in the (near) future14:19
Chipacabase: bo14:19
jdstrandyeah14:20
jdstrandI didn't really want to have to if core18 or fedore-core or core20 or core22 or core24 or arch-core or...'14:21
jdstrandbut I might have to14:21
jdstrandI guess we could peek at the libc6.so in /snap/<base>/<current> but youchie14:21
jdstrandyowchie14:22
* jdstrand likes to make sure he spells his made up words correctly14:22
ograheh14:23
jdstrandmvo: I could just check the kernel and arch. that would, for example, at least remove it for amd64. hmm, but compat mode..14:23
jdstrandmvo: do you have other ideas on how to migrate away from it?14:24
mvojdstrand: hm, hm, there is no way to introspect libc somehow I guess?14:25
jdstrandactually, socketcall doesn't exist on amd64 or arm14:25
jdstrandmvo: 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 snap14:26
mvojdstrand: could we look at the base and look at the bases filesystem when we generate the apparmor profiles?14:26
mvojdstrand: or maybe we can add hints to the bases, we talked about this before14:27
mvojdstrand: hints like "you need these special confinement rules"14:27
jdstrandmvo: possibly, but I don't think libc6.so is guaranteed to be in the same place14:28
jdstrandI mean, on base: bo and base: core16 it won't be (multiarch), let alone fedora-core14:28
mvojdstrand: yeah, its a rathole, the code would have to inspect the elf file(s) :/14:28
jdstrandmvo: let me get completely up to speed on the conditions that would guarantee where it can be removed14:29
jdstrandmvo: maybe that will give some more details for inspiration14:30
mvojdstrand: ok, its also friday afternoon for me, so I'm not 100% fresh  :)14:30
mvojdstrand: so I'm probably also lacking inspiration14:30
jdstrandmvo: sure. assuming we can come up with something reasonable, is this something you'd be willing to accept for core18 devices?14:31
jdstrandmvo: or is it too late to make this type of change?14:31
Chipacamvo: jdstrand: we could have a .yaml for bases that described things14:31
jdstrandChipaca: that might be useful for more than just this14:31
Chipacamhmm14:32
mvomwhudson: 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-conf14:32
mvomwhudson: the generated netplan yaml: http://paste.ubuntu.com/p/pQ8W9544cw/14:33
mvojdstrand, Chipaca yeah, some meta data would be fine - we just need blessing from gustavo but I think its not too late for this14:33
mvosil2100: 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:34
jdstrandmvo: 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
jdstrandmvo: that would at least separate the need for said base.yaml14:35
jdstrandmvo: and if it that yaml was interesting enough on its own, we could modify this check for it14:36
jdstrandmvo: 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 out14:37
jdstrandand we could refine that check going forward14:37
mvojdstrand: yeah, today checking for core18 is fine14:40
mvojdstrand: and when we get new bases we just add them there14:40
Chipacait'd have to be a very long list to be slower than parsing yaml :-)14:41
mvoChipaca: heh :)14:45
mvoChipaca: I guess what might be slow is that snapd will need updates for new bases but I guess thats ok14:45
Chipacathis is for a generated file, that somebody could tweak by hand for development/14:46
Chipaca?14:46
sil2100mvo: hey! Let me take a look14:50
Chipacamup: are you back?14:50
Chipacai guess no14:51
mvoChipaca: no, very sad14:53
mvosil2100: I also removed (temporarily?) cloud-init from core18 as it was interfering with the pi boots14:56
mvosil2100: we should probably talk next week aobut this :)14:56
mvosil2100: and congrats for the 16.04.5 releass btew14:56
mvosil2100: btw14:56
ChipacaSon_Goku: zyga is away15:00
ChipacaSon_Goku: (i saw you ask him something earlier)15:01
ChipacaSon_Goku: should be reachable on telegram though15:01
Son_Gokuah15:01
Son_GokuChipaca, what's his name on Telegram?15:03
ChipacaSon_Goku: pm15:03
Son_Gokuok15:03
ChipacaSon_Goku: on irc, i meant :-)15:04
sil2100mvo: 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:06
sil2100mvo: as for the netplan issue, I wonder why it's only a problem now! set-name requires match: since like 2 years IIRC15:07
mvosil2100: 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 updates15:07
mvosil2100: no idea :) it also works on my amd64 VM15:07
mvosil2100: it just happens on my pi3 test image15:07
sil2100huh, let me dive into that15:08
sil2100mvo: awesome15:08
mvosil2100: thank you, I can make hte image available if that helps15:10
Chipacajdstrand: quesiton about a denial15:11
Chipacajdstrand: [  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:11
Chipacajdstrand: that's what I get when I try to run 'hostnamectl', in 18.04, from a snap that's got hostname-control15:12
Chipacajdstrand: but only if it's got to start the dbus wotsit15:13
Chipacaif it's already running, it works15:13
Chipacawhen I say 'in 18.04' I do _not_ mean core18, fwiw15:13
Chipacathe dbus wotsit is /lib/systemd/systemd-hostnamed fwiw15:15
Chipacacachio: ^ this is why your hostname-control PR is red15:15
cachioChipaca, ahhh15:16
cachionice15:16
Chipacacachio: good on you for catching this15:16
cachioChipaca, thanks15:17
ogramvo, sil2100, note that we set net.ifnames=0 in core images (and thats essential) perhaps netplan is unhappy about that one ?15:17
ogra(thogh i guess that wouldnt be device/board specific )15:18
sil2100mvo: interesting, console-conf for an amd64 doesn't spit out set-name: eth015:21
sil2100mvo: when you think about it, he shouldn't, I guess I'll take a look what causes that15:22
sil2100(anyway, looking at it!)15:22
jdstrandChipaca, cachio: I suspect something is falling back to sethostname()15:23
Chipacajdstrand: this is running  'hostnamectl' on its own, which shouldn't be setting anything (it just prints something afaik)15:24
Chipacajdstrand: https://github.com/snapcore/snapd/pull/5593 if you want to repro this yourself15:24
Chipacaanyhoo, i need to run15:24
Chipacattfn15:24
jdstrandcachio: 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:27
sil2100mvo: 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/image15:28
sil2100(with all the console-conf fixes and branding changes)15:29
cachiojdstrand, I'll check that15:29
mvosil2100: sounds good, we may need to tweak the build to pull from the ppa, iirc right now we only pull from the main archive15:30
sil2100Yeah, 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:32
mvosil2100: *nod*15:33
=== abeato is now known as abeato-away
kyrofaWhen I `sudo snap install --revision=<blah>` it always says "installing <revision> from stable"20:48
kyrofaThis is released to no channel20:48
=== ads20000_ is now known as ads20000
kyrofanoise][, I've been waiting 10 minutes for a review to even start. Things are starting to queue up20:57
kyrofaAre there issues, or just increased load?20:58
kyrofaAh, one finally happened. Must just be load20:58

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