[00:09] <mup> Bug #1633289 changed: network-observe plug is not working for dracnmap snap <Snappy:Fix Released> <https://launchpad.net/bugs/1633289>
[00:24] <mup> Bug #1636657 opened: spread not able to run the snapd test suite <Snappy:New> <https://launchpad.net/bugs/1636657>
[01:28] <liuxg> when I run a shell command like "sudo snap run --shell hello-xiaoguo.env", it gives me the error like "sudo: no tty present and no askpass program specified". Does anyone know why?
[06:45] <vigo> morning snappy
[06:52] <vigo> niemeyer, ping
[06:55] <dholbach> good morning
[07:35] <mwhudson> good morning
[07:41] <mup> PR snapd#2216 closed: snap: skip all ram disks when auto-importing assertions <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2216>
[08:28] <Chipaca> ogra_, o/
[09:00] <vigo> fgimenez, ubuntu-core-reboot failed again with core 279 on dragonboard
[09:02] <vigo> fgimenez, https://pastebin.canonical.com/168964/
[09:07] <fgimenez> vigo, when the suite has finished you can open a shell for inspection after the failing test with "spread -v -reuse -debug external:ubuntu-core-16-arm-64:tests/main/ubuntu-core-reboot"
[09:17] <akey> need advice, what snap should i choose - postgresql96 or postgresql-9-6
[09:18] <akey> first have "cmd" in field developer and second - "stub"
[09:19] <stub> akey: cmd are apparently command prompt, so I'd go with that if it works. I haven't had a chance to look at it yet
[09:19] <stub> akey: I'll be deprecating mine in favour of cmd if it works as intended, so I'd love to hear how you go.
[09:20] <akey> will try
[09:20] <akey> thanks
[09:28] <vigo> fgimenez, sure give me some minutes(meeting) ;)
[09:31] <ogra_> Chipaca, yo !
[09:31] <Chipaca> ogra_, oh hi
[09:32] <Chipaca> ogra_, since pinging you we decided to rewrite the thing i was struggling with in C
[09:32] <ogra_> Chipaca, console-conf ?
[09:32] <ogra_> :D
[09:32] <Chipaca> ogra_, sadly, no
[09:32] <Chipaca> ogra_, the shutdown script thingie
[09:32] <ogra_> ah
[09:33] <Chipaca> ogra_, basically the busybox in initrd isn't enough, and it's dynamically linked so it'd be a pain to set up
[09:33] <ogra_> we have a busybox-static package for this
[09:33] <Chipaca> ogra_, yes, which would add over a meg to the initrd
[09:34] <ogra_> 2M actually
[09:34] <ogra_> yeah, do it in C :)
[09:34] <Chipaca> $ ls -lh bin/busybox /bin/busybox
[09:34] <Chipaca> -rwxr-xr-x  1 root root 1.9M Aug 19  2015 /bin/busybox
[09:34] <Chipaca> -rwxr-xr-x 91 john john 325K Oct 25 22:50 bin/busybox
[09:34] <ogra_> yep
[09:34] <Chipaca> that's just over 1.5M
[09:34] <Chipaca> anyway! yeah
[09:35] <ogra_> Installed-Size: 2.058 kB
[09:35] <Chipaca> most of the hard work has already been done by zyga in snap-confine
[09:35] <ogra_> from apt show
[09:35] <Chipaca> hah, if you're looking at apt show i probably win
[09:35]  * Chipaca looks
[09:35] <Chipaca> Installed-Size: 376 kB
[09:35] <ogra_> well, apt show means i dont neeed to install it :) and it lists all package files
[09:36] <Chipaca> dammit
[09:36]  * Chipaca concedes
[09:36] <ogra_> s/lists/counts/
[09:36] <ogra_> anyway C sounds good
[09:36] <Chipaca> ogra_, anyway, every time i look at initrd i want to get my chainsaw out
[09:36] <Chipaca> ogra_, e.g. it ships two libcs
[09:37] <ogra_> that is currently being fixed
[09:37] <Chipaca> ogra_, https://www.youtube.com/watch?v=A52p9jc-gOo
[09:37] <ogra_> for zesty though ... but i guess we can backport some bits
[09:37] <vigo> fgimenez, running it I'll paste it here
[09:37] <hiseni> Hi, guys! I want to package an app, but it uses Maven Build System: https://github.com/mesonbuild/meson and I can't find any info about using this one w/ spapcraft
[09:38] <ogra_> heh
[09:38] <hiseni> Anyone can help me desidehow to do it better?
[10:01] <mup> Bug #1636762 opened: [snapd] Failures in the spread test suite <Snappy:New> <https://launchpad.net/bugs/1636762>
[10:07] <mup> Bug #1636764 opened: Snapd is not correctly initialized with UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 and model assertion is invalid <Snappy:New> <https://launchpad.net/bugs/1636764>
[10:10] <MikeB> Is this channel archived anywhere?  I looked on snapcraft.io but couldn't find a reference.
[10:12] <ogra_> MikeB, https://irclogs.ubuntu.com/2016/10/26/%23snappy.txt
[10:12] <ogra_> or https://irclogs.ubuntu.com/2016/10/26/%23snappy.html
[10:12] <ogra_> :)
[10:23] <MikeB> ogra_ Thanks!
[10:30] <chihchun> higgins: check out this project, which use maven. https://github.com/ubuntu/snappy-playpen/tree/master/wallpaperdownloader
[11:30] <ogra_> mwhudson, dragonboard seems all fine again, thanks a lot !
[11:37] <vigo> ogra_, this bug https://bugs.launchpad.net/snappy/+bug/1636762
[11:37] <mup> Bug #1636762: [snapd] Failures in the spread test suite <Snappy:New> <https://launchpad.net/bugs/1636762>
[11:37] <vigo> I tried to debug it but no way to do it it fails all the time
[11:38] <vigo> https://pastebin.canonical.com/168977/
[11:39] <vigo> fgimenez, have you any idea why it stucks when "Starting shell to debug"?
[11:40] <fgimenez> vigo, nope, haven't tried it myself, will let you know how it goes
[11:40] <ogra_> vigo, i havent much clue about spread ... but i can imagine the dragonboard kernel lacks fuse support which could cause the fuse interface issue in that list
[11:42] <vigo> ogra_, is there a bug for that already?
[11:43] <ogra_> a bug about my imagination ? not yet, no :)
[11:43] <ogra_> (i havent checked if thats true ... just a guess )
[11:45] <fgimenez> vigo, ogra_ updated info about bug #1636762, now trying to debug tests/main/ubuntu-core-reboot but doesn't seem worrying
[11:45] <mup> Bug #1636762: [snapd] Failures in the spread test suite <Snappy:New> <https://launchpad.net/bugs/1636762>
[11:45] <ogra_> fgimenez, isnt that what Chipaca currently works on (the reboot fixes) ?
[11:46] <vigo> ogra_, fgimenez thanks
[11:47] <fgimenez> ogra_, not sure, we have issues with this test before, it checks for a snap service to be up after a reboot and we weren't waiting long enough, now it works fine on other platforms and only fails on dragonboard
[12:05] <ogra_> fgimenez, ah ... weird though ...
[12:07] <mvo> ogra_: hey, I shared a gdoc with you, curious to  know if I understand the dtb problem correctly
[12:07] <ogra_> yeah, just got the mail
[12:07]  * ogra_ goes reading
[12:08] <mvo> ogra_: great, thank you! feel free to correct my assumptions in there if I got something wrong
[12:10] <ogra_> mvo, updated
[12:11] <mvo> ogra_: thanks
[12:11] <mvo> ogra_: iirc you also mentioned the binary bootloader added stuff to the dtb in memory, so we really need to use the version in memory, do I remember correctly?
[12:11] <ogra_> right
[12:11] <ogra_> board serial and MAC
[12:12] <ogra_> you need to serial in /proc/cpuinfo because if you purchase a codec for the board it uses this to validate the codecs
[12:12] <mvo> ogra_: great, added that as well
[12:12] <ogra_> and only the first stage loader can read it from ROM
[12:13] <mvo> ogra_: this really sounds like there is no way out of it, i.e. we can not revert to a previous kenrel without rewrting the dtb and reloading it. maybe via some scripting in uboot.env?
[12:15] <mvo> ogra_: anyway, thanks a bunch, I think the problem is much clearer now, the solution is still tricky, will discuss in todays standup
[12:17] <ogra_> mvo, well, there might be ways with a newer uboot ... the main issue here is the overlay handling ... i could cheat a lot from uboot (loading from disk and overwrite parts of the dtb in ram etc)  but uboot cant load the overlays
[12:17] <ogra_> there was work in newer uboot to start supporting overlays generically but i dont know where that stands
[12:18] <iliv> what is revision really? i just installed a package with the same name but different version number without removing a previous version. I noticed that revision number incresed, even though it's a newer version that is installed now. this kinda doesn't make any sense. if it's a new version, just installed, revision should be x1, not x2.
[12:18] <ogra_> just overwriting the basic dtb from disk and keeping the info from ROM still around is possible afaik
[12:20] <mvo> ogra_: oh, so we could always keep the one that was used on install and load a kernel specific one into memory and ship that as part of the kernel snap?
[12:21] <ogra_> mvo, well, you would need to merge them ... since you need what the binary loader artificially writes to the ram one when reading the rom
[12:21] <ogra_> i.e. serial and MAC
[12:22] <ogra_> mvo, but to use any addon board on the Pi you need an overlay DTB ... and for that only the binary loader works ... you could only get the overlay loaded for the original DTB, not for the current one
[12:23] <mvo> ogra_: I add to the gdoc: stuff gets even more complicated with overlay dtbs ;)
[12:23] <ogra_> heh, yeah, i also added a description at the top paragraph about that
[12:29] <fgimenez> vigo, ogra_ confirmed that for tests/main/ubuntu-core-reboot we need to wait a little bit more on dragonboard http://paste.ubuntu.com/23383345/
[12:30] <ogra_> hmm, i wonder why ... it isnt like the dragonboard boots particulary slower than a pi2 or 3
[12:32] <vigo> ogra_, with latest image I  noticed it takes more time than before
[12:33] <vigo> but at least, I can now use wifi :)
[12:34] <vigo> fgimenez, ack thank you
[13:02] <mup> Bug #1636847 opened: unexpectedly large memory usage of mounted snaps <Snappy:New> <https://launchpad.net/bugs/1636847>
[13:15] <niemeyer> vigo: Hi
[13:15] <niemeyer> morphis: On the standup call, but will be with you in a few mins
[13:24] <liuxg> kyrofa, good morning what was your finding yesterday regarding the configure hook?
[13:56] <mup> Bug #1636864 opened: ubuntu-image 0.10+real1 is broken <Snappy:New> <https://launchpad.net/bugs/1636864>
[14:38] <dobey> how can i boot the snappy core image without logging in to u1?
[14:43] <zyga> dobey: you can create a different brand (e.g. by forking the gadget and model assertion) and then using the system-user assertion to create an user on first boot
[14:43] <zyga> dobey: AFAIK
[14:44] <dobey> zyga: no idea how to do that. on first boot i get the initial setup thing and it's requiring me to log in, and i can't actually type the e-mail address in the field
[14:45] <zyga> dobey: what happens when you try?
[14:46] <dobey> zyga: "nothing" i guess. i can type an e-mail, but i can't type a + character for some reason, so i can't type the test e-mail to log in with
[14:46] <zyga> dobey: keyboard setup is not done beffore this is finished, I suspect you can type + if you use a US / international keyboard
[14:46] <ogra_> we switched to only support chinese keyboards and utf16 :P
[14:47] <dobey> zyga: i AM using a US keyboard
[14:47] <zyga> dobey: then I don't know
[14:47] <ogra_> (kidding indeed, it defaults to US only kbd though)
[14:48] <dobey> trying to boot the image in a kvm
[14:48]  * ogra_ does that ten times a week ... 
[14:48] <dobey> https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
[14:48] <ogra_> but i never had a + sign in my mail address
[14:49] <dobey> trying to follow the instructions there to get it booted; but can't type + and can't log in
[14:49] <dobey> err and can't skip the login
[14:49] <ogra_> well, no, there is no local way to log in anymore
[14:50] <ogra_> the user creation pulls your ssh key from your LP account and puts it in place
[14:50] <dobey> :-/
[14:50] <ogra_> you can then ssh in and use "sudo passwd $USER" in case you need a console login
[14:50] <ogra_> but by default the local logins are locked
[14:51] <ogra_> kvm -m 1500 -redir tcp:8022::22 amd.img
[14:51] <ogra_> thats what i use here to set it up ... keystrokes work fine
[14:52] <dobey> you can type a + char in the login field in the initial setup?
[14:53] <ogra_> well, i can type a + when i'm logged in on console
[14:53] <rharper> dobey: it's a bug
[14:53] <ogra_> which should be the same
[14:53] <rharper> it's not
[14:53] <rharper> there's an input box with a regex filter
[14:53] <rharper> dobey: I can reproduce
[14:53] <ogra_> oh, really ?
[14:54] <ogra_> ah
[14:54] <rharper> in console-conf
[14:54] <ogra_> right, input wise it shopuld be the same ... i wasnt aware there is a regex
[14:54] <ogra_> rharper, does mwhudson know already ?
[14:54] <zyga> dobey: can you please report this?
[14:54] <zyga> dobey: just in case
[14:54] <zyga> dobey: you an also try this
[14:54] <zyga> dobey: boot your VM with -display curses
[14:55] <zyga> dobey: log in this way
[14:55] <zyga> dobey: and then shut down and boot with SDL
[14:55] <ogra_> zyga, how does that help if the + is filtered out in the user creation input field
[14:55] <ogra_> it is console-conf itself filtering that
[14:55] <ogra_> no frontend switch will fix that
[14:56] <dobey> well there's no information in the setup stuff either, so i guess even if i can log in it doesn't help me much
[14:56] <zyga> ogra_: I don't know, maybe it helps, maybe it doesn't
[14:56] <zyga> ogra_: I see
[14:56] <ogra_> unlikely ... being an app bug
[14:58] <rharper> ogra_: probably not;
[14:59] <ogra_> well, it would help if someone filed a bug against subiquity :)
[14:59] <rharper> console-conf/ subiquity, whatever
[15:04] <dobey> so where?
[15:05] <ogra_> https://bugs.launchpad.net/ubuntu/+source/subiquity/+filebug
[15:05] <ogra_> and open a task against the snappy project too please
[15:06] <zyga> ogra_: is this it? https://github.com/CanonicalLtd/subiquity
[15:06] <ogra_> i guess so
[15:08] <dobey> https://bugs.launchpad.net/snappy/+bug/1636891
[15:08] <mup> Bug #1636891: Unable to log in using email with + character <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1636891>
[15:09] <mup> Bug #1636891 opened: Unable to log in using email with + character <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1636891>
[15:13] <rharper> dobey: thanks
[15:18] <mup> Bug #1636894 opened: [raspberry pi3]pi3 snap is removable  <Snappy:New> <https://launchpad.net/bugs/1636894>
[15:18] <mup> PR snapd#2217 opened: tests: increase wait time for service to be up <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2217>
[15:22] <mup> PR snapcraft#861 closed: python plugin: install from wheel for local setup.py <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/861>
[15:26] <kyrofa> liuxg, ping
[15:27] <mup> Bug #1634803 opened: snapcraft register-key doesn't use U1 SSO login credentials <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1634803>
[15:30] <ppisati> ogra_: the wifi card on your rpi3 board is broken, i tried several different combinations
[15:30] <ppisati> ogra_: but with none of them it shows up
[15:30] <ppisati> ogra_: i even tried raspbian, but nothing
[15:30] <ogra_> ppisati, it shows up after reboot
[15:30] <ppisati> ogra_: no no, i mean your board
[15:31] <ogra_> just on on first boot
[15:31] <ppisati> ogra_: do you remeber that we exchanged board at the sprint?
[15:31] <ogra_> oh, yeah!
[15:31] <ppisati> ogra_: i can't get the wifi to show up _at_all_
[15:31] <ogra_> thats what you mean
[15:31] <ogra_> wow
[15:31] <ogra_> that used to work
[15:31] <ppisati> ogra_: classic, snappy, raspbian, etc
[15:31] <ppisati> ogra_: i expensed a new rpi3 board
[15:31] <ogra_> creap
[15:32] <ogra_> i guess i owe you a beer then, i bet it was the "plug HDMI whiloe on power"
[15:32] <ppisati> ogra_: probably, the spi/i2c expansion bus is busted too, so...
[15:32] <kgunn> kyrofa: hey, if i have a branch i'm building in a snap, and i just wanna cheat & save time...a-la snap clean thing --step=build
[15:32] <ogra_> (i always forget that there is no proper grounding)
[15:32] <kgunn> where do i modify the source?.... in the part folder?
[15:33] <kyrofa> kgunn, you want to modify the pulled source?
[15:33] <kyrofa> kgunn, yeah, it's in parts/<partname>/src
[15:34] <ogra_> ppisati, i still cant imagine why it would be PM though ...
[15:34] <kyrofa> kgunn, though note that if the source is local, they're hard links. That might help a little
[15:34] <ogra_> ppisati, i.e. why does it only happen on the very first boot
[15:34] <ogra_> i would expect it to have similar issues after reboot
[15:34] <kgunn> kyrofa: right, just the pulled src
[15:35] <kgunn> yeah, it's not local...
[15:35] <kyrofa> Then yeah, that's what you want
[15:35] <kgunn> avoiding the separate change+push
[15:35] <kyrofa> Careful not to kill your changes by cleaning completely, though!
[15:35] <kgunn> will push later when i figure it out :)
[15:35] <kgunn> @complete clean...right!
[15:35] <nothal> kgunn: No such command!
[15:36] <ogra_> defiant bot ... doesnt want to clean
[15:46] <mhall119> sergiusens: do we have a method yet to copy a .desktop file produced by a part's build step into ./setup/gui/ ?
[16:03] <sergiusens> mhall119 that was only discussed last week during a session
[16:04]  * mhall119 wishes we had videos of those sessions
[16:17] <ogra_> mvo, bug 1636894 smells a bit critical
[16:17] <mup> Bug #1636894: [raspberry pi3]pi3 snap is removable  <Snappy:Confirmed> <https://launchpad.net/bugs/1636894>
[16:20] <kgunn> kyrofa: got a minute? wanna describe something and see if you've got an idea i can try...
[16:21] <kyrofa> kgunn, yeah, what's up?
[16:22] <kgunn> kyrofa: ok, so, i've got 2 snaps (it's a form of mir-server and mir-client, but not exactly)....
[16:22] <kgunn> i can build these in classic on the core, and it works without a flaw...
[16:22] <kgunn> however, when i run the exact same sceario on snaps...here's how it goes down
[16:23] <kgunn> the mir-server comes up fine, nothing strange in logs....but the minute i launch the client the server crashes immediately
[16:23] <kgunn> and again, nothing really showing up in logs
[16:23] <kgunn> so...wondering, can i include gdb inside my mir-server snap and run it ?
[16:23] <kgunn> or some trick like that you might recomment
[16:23] <kgunn> recommend even
[16:24] <ogra_> snap run --shell $command_inside_your_snap
[16:24] <ogra_> then use gdb from that shell
[16:24] <kyrofa> ogra_, that's still under the same confinement though, no?
[16:24] <kgunn> ogra_: well, i can run unconfined, the trouble occurs no matter waht
[16:24] <ogra_> also, the classic snap (that i demoed at the sprint) allows attaching to PIDs
[16:25] <ogra_> so just apt install gdb and debug away i guess
[16:25] <kyrofa> kgunn, as ogra_ mentions, could you run gdb as normal and attach to the PID of the app?
[16:25] <ogra_> kyrofa, yeah, inside the confinement ... but your gdb runs inside the same sandbox at least
[16:25] <kyrofa> kgunn, I've also included strace in my snaps before, I can't imagine why gdb wouldn't also work
[16:26] <kgunn> ogra_: kyrofa cool...i'll try that, thanks guys
[16:26] <kyrofa> ogra_, I mean it doesn't have access to gdb
[16:26]  * kgunn already has classic setup on the image
[16:26] <ogra_> not to one you dont ship indeed
[16:26] <kgunn> oh while i'm here... ogra_ flexiondotorg do either of you have a recommended power supply to use with pi3
[16:26] <ogra_> as many amps as you can get :P
[16:27] <ogra_> current is key .... beyond that ... not really
[16:27] <kgunn> i got one...but it came with w a charger that has a micro usb...and i don't think its strong enough to drive the display
[16:27] <ogra_> ah, attached usb display powered from the onboard usb hub ?
[16:27] <kgunn> ogra_: right
[16:28] <ogra_> s/usb/hdmi/
[16:28] <kgunn> ogra_: i guess i could try an externally powerd display first...
[16:28] <ogra_> i'd go with something like 4A
[16:28] <kgunn> cool
[16:28] <ogra_> that should be able to even drive a rotary usb disk
[16:28] <kgunn> :)
[16:31] <kgunn> uh, i guess i should also include dbg syms into my snap
[16:31] <ogra_> heh, yeah, that helps
[16:40] <mvo> ogra_: right, super important, not quite critical as you need to do manually disable it first, will work on a fix now
[16:41] <ogra_> heh, i didnt mean to cause work for you, i just wanted to set the severity :)
[16:46] <mvo> ogra_: thats fine, I think its also high++ priority :)
[16:46] <ogra_> true :)
[16:52] <mup> PR snapcraft#867 closed: Handle 'broken' validations that don't match refresh-control <Created by ralsina> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/867>
[16:55] <liuxg> kyrofa, ping
[16:55] <kyrofa> liuxg, pong
[17:00] <Croepha> So, if I wanted ubuntu core to have grub that had serial console enabled, I would have to make a new pc snap, ( i think thats the gadget snap) is that right?
[17:03] <ogra_> Croepha, we do have serial enabled by default i think
[17:03] <ogra_> (if not, we probably should)
[17:04] <Croepha> It looks like its enabled for the kernel, but not grub
[17:04] <Croepha> although, with pretty much everything snappy related, im pretty sure its not working right, because I probably did something to mess it up
[17:04] <mup> PR snapcraft#873 opened: Release changelog for 2.20 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/873>
[17:05] <ogra_> ah, yeah, not sure about serial support in grub itself
[17:05] <ogra_> we definitely have a console= arg for serial on all images
[17:05] <Croepha> nice
[17:08] <mup> PR snapd#2218 opened: snapstate: ensure gadget/core/kernel can not be disabled <Created by mvo5> <https://github.com/snapcore/snapd/pull/2218>
[17:17] <Croepha> btw, hypothetically, is core setup for PXE booting? seems like there is a lot of really cool potential to have the snaps mounted on a RO nfs mount and have writable portion be on a RW nfs mount or using aufs or something? is this an explored subject? or unexplored? or determined to be out of scope? just curious?
[17:31] <mup> Bug #1636931 opened: Configure hook not running <Snappy:New> <https://launchpad.net/bugs/1636931>
[17:36] <mup> PR snapd#2219 opened: asserts: limit to 1y only if len(models) == 0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2219>
[17:49] <pmcgowan> ogra_, two questions if you have a min
[17:49] <pmcgowan> $ snappy config core
[17:49] <pmcgowan> qemu-system-x86_64: could not set up host forwarding rule ':4200::4200'
[17:49] <pmcgowan> qemu-system-x86_64: Device 'user' could not be initialized
[17:49] <pmcgowan> oh thats an old command, bad docs
[17:50] <pmcgowan> er
[17:50] <flexiondotorg> kgunn, Pi3 power requires minimum of 2.4amp
[17:51] <kgunn> ack
[18:13] <kyrofa> mvo, I seem to remember discussions about more `snap run` options, like --gdb and --strace, is that right?
[18:13] <ogra_> pmcgowan, heh, happy i could be of help :)
[18:16] <pmcgowan> ogra_, but my real question
[18:16] <pmcgowan> my refresh service isnt running, seems it should be?
[18:16] <pmcgowan> how do I check the autoupdate config?
[18:17] <ogra_> uh, i dont know ... i know it is a timer
[18:17] <ogra_> systemctl | grep timer
[18:17] <ogra_> ?
[18:21] <pmcgowan> ogra_,  systemctl status -l snapd.refresh.service
[18:21] <pmcgowan> says its inactive
[18:22] <pmcgowan> and systemctl list-timers snapd.refresh.timer
[18:22] <ogra_> well, not sure the service contains the timer, i think that is what the timer calls actually
[18:22] <pmcgowan> says 0 timers
[18:22] <pmcgowan> no snap timers
[18:23] <pmcgowan> ogra_, there is a refresh timer on dragonbaord
[18:23] <ogra_> i think Chipaca is our specialist for that bit ... bt he doesnt seem to be around
[18:23] <pmcgowan> not on pc
[18:24] <ogra_> weird
[18:24] <ogra_> same image ?
[18:24] <pmcgowan> image?
[18:24] <ogra_> (i mean ... installed from the same image ... i.e. around the same time)
[18:24] <ogra_> yeah
[18:24] <pmcgowan> core versions are the sam
[18:24] <pmcgowan> e
[18:25] <ogra_> that doesnt matter, the timers are part of the firstboot setup
[18:25] <pmcgowan> this is on my laptop though
[18:25] <ogra_> and that might have improved between different image builds (or core versions if you want it like that)
[18:25] <ogra_> oh
[18:26] <ogra_> i thought you talk kvm vs dragonboard all-snap images
[18:26] <pmcgowan> no sorry
[18:26] <pmcgowan> apple orange
[18:26] <ogra_>   snapd.refresh.timer                                                                                loaded active waiting   Timer to automatically refresh installed snaps
[18:26] <ogra_> that is whyt i get on my laptop
[18:26] <ogra_> *what
[18:26] <pmcgowan> hmm
[18:27] <pmcgowan> thats what I see on db
[18:27] <ogra_> not sure why yours is disabled ... i think there was a bug once
[18:27] <pmcgowan> how do I enable it now
[18:27] <ogra_> bug 1588977
[18:27] <mup> Bug #1588977: [2.0.6] snapd.refresh.timer fails <regression-proposed> <verification-done> <xenial> <snapd (Ubuntu):Fix Released by carrol1> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1588977>
[18:29] <pmcgowan> ogra_, let me try t enable it
[18:29] <mup> PR snapd#2218 closed: snapstate: ensure gadget/core/kernel can not be disabled <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2218>
[18:29] <mup> PR snapd#2219 closed: asserts: limit to 1y only if len(models) == 0 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2219>
[18:30] <pmcgowan> ogra_, its working now and I got the update I expected
[18:30] <ogra_> yay
[19:01] <mup> Bug #1610001 changed: Regression: snap run no longer runs hooks <Snappy:Fix Released by kyrofa> <https://launchpad.net/bugs/1610001>
[19:05] <mup> PR snapd#2220 opened: overlord/snapstate: fix missing argument to Noticef <Created by zyga> <https://github.com/snapcore/snapd/pull/2220>
[19:16] <mvo> kyrofa: yes, we talked about this
[19:16] <kyrofa> mvo, still planned, then?
[19:17] <kyrofa> Just wanted to make kgunn aware, but wanted to make sure I remembered correctly first :)
[19:17] <mvo> kyrofa: yes but no dates or priority attached to it
[19:17] <kyrofa> Sure
[19:17] <kyrofa> Thanks mvo :)
[19:17] <mvo> yw
[19:17] <kgunn> ack
[19:18] <kyrofa> So kgunn as ogra_ mentioned we have `snap run --shell <app>`. That enables you to debug if you include strace/gdb/etc. in your snap, but eventually we'll have `snap run --gdb <app>` and `snap run --strace <app>` and the like
[19:18] <kgunn> cool
[19:19] <kgunn> fwiw, i just tried from classic snap...i attached to the pid ok, but then nothing...at least when i crashed the process...no output (altho could be user idiocy)
[19:19] <ogra_> check syslog
[19:20] <ogra_> if there is any seccomp blocking or anything
[19:27] <kgunn> when doing snap run --shell <app> ....is <app> really the service name ?
[19:28] <kgunn> e.g. is snap run going to launch my service?
[19:32] <kyrofa> kgunn, it won't run anything if you use --shell, but yeah, it can be a service
[19:32] <kyrofa> At least... I assume (not tried myself)
[19:52] <kyrofa> ogra_, are you still around?
[19:52] <ogra_> semi :)
[19:52] <kyrofa> ogra_, dumb question: if the kernel snap updates, does the device reboot?
[19:53] <ogra_> hmm, i would expect so ...
[19:53] <ogra_> but mvo knows the code ...
[19:53] <mvo> kyrofa: it does - after a delay of some minutes
[19:54] <ogra_> (i definitely had a reboot today after the new kernels landed)
[19:54] <kyrofa> mvo, ogra_ good deal, thanks. I figured that was the case, I just realized that hasn't happened to me yet on a core-based image, so wanted to double-check
[19:55] <ogra_> kyrofa, use dailies if you like reboots ;)
[19:55] <kyrofa> ogra_, :P
[19:55] <ogra_> edge gets a new core every day
[19:55] <kyrofa> ogra_, a core update doesn't cause a reboot, right?
[19:55] <ogra_> it does
[19:55] <kyrofa> Huh, I didn't know that
[19:56] <ogra_> you can intercept with shutdown -c
[19:56] <ogra_> (it warns you)
[19:56] <kyrofa> Why? Just because we figure running services are using libs from it?
[20:25] <mwhudson> rharper, dobey: oops (re email addresses)
[20:25] <mwhudson> rharper, dobey: are any other characters missing?
[20:25] <rharper> mwhudson: I went searching (briefly) for reasonable email regex and I couldn't find anything definitive
[20:25] <mwhudson> https://github.com/CanonicalLtd/subiquity/pull/178
[20:25] <mup> PR CanonicalLtd/subiquity#178: allow + in email addresses <Created by mwhudson> <https://github.com/CanonicalLtd/subiquity/pull/178>
[20:25] <mwhudson> rharper: i guess i could look at what lp itself allows...
[20:25] <rharper> yeah
[20:26] <rharper> or see if any of the security folks have a good best practices
[20:27] <dobey> mwhudson: almost definitely. + is what broke for me though. but i'm a boring USian
[20:27] <mwhudson> apparently = is allowed too
[20:32] <kyrofa> mwhudson, tons of things are allowed-- the common advice I find is "beyond checking for @, don't bother validating. Just email to confirm."
[20:38] <kyrofa> mwhudson, https://davidcel.is/posts/stop-validating-email-addresses-with-regex/
[20:39] <kyrofa> mwhudson, best quote: "Look at all these spaces!"@example.com is a valid email address
[20:39] <mwhudson> kyrofa: well you couldn't create an account on lp with such an address
[20:39] <mwhudson> and i assume sso is the same but i haven't checked there
[20:40] <kyrofa> mwhudson, yeah just trying to save you some googling for definitive regex, because there isn't one :)
[20:41] <mwhudson> i am aware of that :)
[20:47] <mwhudson> rharper, dobey, ogra_: is this worth doing a new release / upload for?
[20:48] <mwhudson> i guess so, it blocks some people and is low risk
[20:48] <ogra_> mwhudson, only if you want dobey as a uaer i guess :P
[20:48] <ogra_> **user
[20:48] <dobey> well i'm sure i'll find more bugs after i get past that ;)
[20:49] <ogra_> word
[21:21] <Croepha> is this the right way to use a ubuntu flavour in a snap kernel snapcraft.yaml: kdefconfig: kdefconfig: ['flavour=my_flavour', 'config']
[21:44] <mwhudson> hm i guess mvo is asleep
[21:58] <Snappin> Hi. Can anyone provide ANY info on backing up data created from a snappy app? Nextcloud for ex?
[22:00] <kyrofa> Snappin, there are a limited number of places snaps can write. Nextcloud for example will always dump its data into /var/snap/nextcloud/common (unless you change it in the config)
[22:01] <kyrofa> data = nextcloud raw data. The config, apps, etc. go elsewhere
[22:01] <kyrofa> (/var/snap/nextcloud/current to be exact)
[22:01] <Snappin> kyrofa: so let's say I dump that directory and want in case i have a server failure. So I rebuild my server, do the snap install nextcloud. So I just dump the backup there and call it a day?
[22:01]  * Snappin is baffled backup & restore isn't covered ANYWHERE in the docs....
[22:01] <kyrofa> Snappin, well, ignoring the snap, how does one backup a nextcloud install?
[22:01] <kyrofa> Snappin, it's because it's always going to be application-specific, not snap-specific
[22:02] <Snappin> it's a multi-step process and is documented.
[22:02] <Snappin> kyrofa: ok I understand that. so is it safe to assume there isn't or never will be a common procedure to backup/recover of snappy install critical data?
[22:03]  * Snappin is trying to decide if diving further into snappy tech is worth it...not trying to be rude or critical.
[22:03] <kyrofa> Snappin, you can always copy it off and paste it back, but the application may not pick it up like that
[22:03] <Snappin> ok. that's sounds too risky for me. I see the appeal of snaps but not if there is going to be an unpredictable outcome of data recovery.
[22:04] <Snappin> Do you know if future roadwork with snappy will involve my concerns regarding backup/recovery?
[22:04] <kyrofa> So in order to migrate a Nextcloud install, what do you do? You dump the database, copy the raw data and the config, and then apply in reverse order
[22:05] <Snappin> i only know how to backup/restore nextcloud by hand if i install it by hand.. this is well documented on the web.
[22:05] <Snappin> Thanks though, i think i've found my answers.
[22:41] <jdstrand> sergiusens: hey, would you mind approving https://myapps.developer.ubuntu.com/dev/click-apps/5063/rev/3/ ?
[22:42] <jdstrand> sergiusens: I made some changes to the review tools so that will pass, but that needs a store sync
[23:13] <hindle> I'm trying to package with snappy (confinement: strict) a application (not service) that opens unix sockets at say /tmp/socket1 - Currently I get access dennied errors. I see that for services I can use "caps:" property but I can't find any documentation on how it can be done for apps.
[23:17] <qengho> hindle: You don't get access to /tmp . You can get a personal, ephemeral tmpdir. If you're trying to do something that has some system-wide known name, you want a service.
[23:21] <hindle> qengho: thanks - I'm trying to do IPC via unix sockets - between different apps in the same snappy packge.
[23:23] <hindle> qengho: but I still can't seem to open a unix socket at a writtable path for the snappy application.
[23:23] <hindle> qengho: so I assumed I need to add some privilage to the app.
[23:24] <jdstrand> hindle: you can do that fine if you create it in one of the writable areas for the snap
[23:32] <jdstrand> (other than /tmp)
[23:45] <hindle> jdstrand: thanks