[00:09] Bug #1633289 changed: network-observe plug is not working for dracnmap snap [00:24] Bug #1636657 opened: spread not able to run the snapd test suite [01:28] 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? === chihchun_afk is now known as chihchun === hikiko is now known as hikiko|off [06:45] morning snappy [06:52] niemeyer, ping [06:55] good morning [07:35] good morning [07:41] PR snapd#2216 closed: snap: skip all ram disks when auto-importing assertions [08:28] ogra_, o/ [09:00] fgimenez, ubuntu-core-reboot failed again with core 279 on dragonboard [09:02] fgimenez, https://pastebin.canonical.com/168964/ [09:07] 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] need advice, what snap should i choose - postgresql96 or postgresql-9-6 [09:18] first have "cmd" in field developer and second - "stub" [09:19] 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] 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] will try [09:20] thanks === chihchun is now known as chihchun_afk [09:28] fgimenez, sure give me some minutes(meeting) ;) [09:31] Chipaca, yo ! [09:31] ogra_, oh hi [09:32] ogra_, since pinging you we decided to rewrite the thing i was struggling with in C [09:32] Chipaca, console-conf ? [09:32] :D [09:32] ogra_, sadly, no [09:32] ogra_, the shutdown script thingie [09:32] ah [09:33] 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] we have a busybox-static package for this [09:33] ogra_, yes, which would add over a meg to the initrd [09:34] 2M actually [09:34] yeah, do it in C :) [09:34] $ ls -lh bin/busybox /bin/busybox [09:34] -rwxr-xr-x 1 root root 1.9M Aug 19 2015 /bin/busybox [09:34] -rwxr-xr-x 91 john john 325K Oct 25 22:50 bin/busybox [09:34] yep [09:34] that's just over 1.5M [09:34] anyway! yeah [09:35] Installed-Size: 2.058 kB [09:35] most of the hard work has already been done by zyga in snap-confine [09:35] from apt show [09:35] hah, if you're looking at apt show i probably win [09:35] * Chipaca looks [09:35] Installed-Size: 376 kB [09:35] well, apt show means i dont neeed to install it :) and it lists all package files [09:36] dammit [09:36] * Chipaca concedes [09:36] s/lists/counts/ [09:36] anyway C sounds good [09:36] ogra_, anyway, every time i look at initrd i want to get my chainsaw out [09:36] ogra_, e.g. it ships two libcs [09:37] that is currently being fixed [09:37] ogra_, https://www.youtube.com/watch?v=A52p9jc-gOo [09:37] for zesty though ... but i guess we can backport some bits [09:37] fgimenez, running it I'll paste it here [09:37] 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] heh [09:38] Anyone can help me desidehow to do it better? [10:01] Bug #1636762 opened: [snapd] Failures in the spread test suite [10:07] Bug #1636764 opened: Snapd is not correctly initialized with UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 and model assertion is invalid [10:10] Is this channel archived anywhere? I looked on snapcraft.io but couldn't find a reference. [10:12] MikeB, https://irclogs.ubuntu.com/2016/10/26/%23snappy.txt [10:12] or https://irclogs.ubuntu.com/2016/10/26/%23snappy.html [10:12] :) [10:23] ogra_ Thanks! === chihchun_afk is now known as chihchun [10:30] higgins: check out this project, which use maven. https://github.com/ubuntu/snappy-playpen/tree/master/wallpaperdownloader === Guest59736 is now known as ahasenack === ahasenack is now known as Guest33774 [11:30] mwhudson, dragonboard seems all fine again, thanks a lot ! [11:37] ogra_, this bug https://bugs.launchpad.net/snappy/+bug/1636762 [11:37] Bug #1636762: [snapd] Failures in the spread test suite [11:37] I tried to debug it but no way to do it it fails all the time [11:38] https://pastebin.canonical.com/168977/ [11:39] fgimenez, have you any idea why it stucks when "Starting shell to debug"? [11:40] vigo, nope, haven't tried it myself, will let you know how it goes [11:40] 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] ogra_, is there a bug for that already? [11:43] a bug about my imagination ? not yet, no :) [11:43] (i havent checked if thats true ... just a guess ) [11:45] vigo, ogra_ updated info about bug #1636762, now trying to debug tests/main/ubuntu-core-reboot but doesn't seem worrying [11:45] Bug #1636762: [snapd] Failures in the spread test suite [11:45] fgimenez, isnt that what Chipaca currently works on (the reboot fixes) ? [11:46] ogra_, fgimenez thanks [11:47] 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 === petevg is now known as petevg_afk [12:05] fgimenez, ah ... weird though ... [12:07] ogra_: hey, I shared a gdoc with you, curious to know if I understand the dtb problem correctly [12:07] yeah, just got the mail [12:07] * ogra_ goes reading [12:08] ogra_: great, thank you! feel free to correct my assumptions in there if I got something wrong [12:10] mvo, updated [12:11] ogra_: thanks [12:11] 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] right [12:11] board serial and MAC [12:12] 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] ogra_: great, added that as well [12:12] and only the first stage loader can read it from ROM [12:13] 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] 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] 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] there was work in newer uboot to start supporting overlays generically but i dont know where that stands [12:18] 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. === Guest33774 is now known as ahasenack [12:18] just overwriting the basic dtb from disk and keeping the info from ROM still around is possible afaik === ahasenack is now known as Guest66764 [12:20] 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] 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] i.e. serial and MAC [12:22] 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] ogra_: I add to the gdoc: stuff gets even more complicated with overlay dtbs ;) [12:23] heh, yeah, i also added a description at the top paragraph about that [12:29] 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] hmm, i wonder why ... it isnt like the dragonboard boots particulary slower than a pi2 or 3 [12:32] ogra_, with latest image I noticed it takes more time than before [12:33] but at least, I can now use wifi :) [12:34] fgimenez, ack thank you [13:02] Bug #1636847 opened: unexpectedly large memory usage of mounted snaps [13:15] vigo: Hi [13:15] morphis: On the standup call, but will be with you in a few mins [13:24] kyrofa, good morning what was your finding yesterday regarding the configure hook? [13:56] Bug #1636864 opened: ubuntu-image 0.10+real1 is broken [14:38] how can i boot the snappy core image without logging in to u1? [14:43] 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] dobey: AFAIK [14:44] 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] dobey: what happens when you try? [14:46] 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] dobey: keyboard setup is not done beffore this is finished, I suspect you can type + if you use a US / international keyboard [14:46] we switched to only support chinese keyboards and utf16 :P [14:47] zyga: i AM using a US keyboard [14:47] dobey: then I don't know [14:47] (kidding indeed, it defaults to US only kbd though) [14:48] trying to boot the image in a kvm [14:48] * ogra_ does that ten times a week ... [14:48] https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ [14:48] but i never had a + sign in my mail address [14:49] trying to follow the instructions there to get it booted; but can't type + and can't log in [14:49] err and can't skip the login [14:49] well, no, there is no local way to log in anymore [14:50] the user creation pulls your ssh key from your LP account and puts it in place [14:50] :-/ [14:50] you can then ssh in and use "sudo passwd $USER" in case you need a console login [14:50] but by default the local logins are locked [14:51] kvm -m 1500 -redir tcp:8022::22 amd.img [14:51] thats what i use here to set it up ... keystrokes work fine [14:52] you can type a + char in the login field in the initial setup? [14:53] well, i can type a + when i'm logged in on console [14:53] dobey: it's a bug [14:53] which should be the same [14:53] it's not [14:53] there's an input box with a regex filter [14:53] dobey: I can reproduce [14:53] oh, really ? [14:54] ah [14:54] in console-conf [14:54] right, input wise it shopuld be the same ... i wasnt aware there is a regex [14:54] rharper, does mwhudson know already ? [14:54] dobey: can you please report this? [14:54] dobey: just in case [14:54] dobey: you an also try this [14:54] dobey: boot your VM with -display curses [14:55] dobey: log in this way [14:55] dobey: and then shut down and boot with SDL [14:55] zyga, how does that help if the + is filtered out in the user creation input field [14:55] it is console-conf itself filtering that [14:55] no frontend switch will fix that [14:56] 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] ogra_: I don't know, maybe it helps, maybe it doesn't [14:56] ogra_: I see [14:56] unlikely ... being an app bug [14:58] ogra_: probably not; [14:59] well, it would help if someone filed a bug against subiquity :) [14:59] console-conf/ subiquity, whatever [15:04] so where? [15:05] https://bugs.launchpad.net/ubuntu/+source/subiquity/+filebug [15:05] and open a task against the snappy project too please [15:06] ogra_: is this it? https://github.com/CanonicalLtd/subiquity [15:06] i guess so [15:08] https://bugs.launchpad.net/snappy/+bug/1636891 [15:08] Bug #1636891: Unable to log in using email with + character [15:09] Bug #1636891 opened: Unable to log in using email with + character [15:13] dobey: thanks [15:18] Bug #1636894 opened: [raspberry pi3]pi3 snap is removable [15:18] PR snapd#2217 opened: tests: increase wait time for service to be up [15:22] PR snapcraft#861 closed: python plugin: install from wheel for local setup.py [15:26] liuxg, ping [15:27] Bug #1634803 opened: snapcraft register-key doesn't use U1 SSO login credentials [15:30] ogra_: the wifi card on your rpi3 board is broken, i tried several different combinations [15:30] ogra_: but with none of them it shows up [15:30] ogra_: i even tried raspbian, but nothing [15:30] ppisati, it shows up after reboot [15:30] ogra_: no no, i mean your board [15:31] just on on first boot [15:31] ogra_: do you remeber that we exchanged board at the sprint? [15:31] oh, yeah! [15:31] ogra_: i can't get the wifi to show up _at_all_ [15:31] thats what you mean [15:31] wow [15:31] that used to work [15:31] ogra_: classic, snappy, raspbian, etc [15:31] ogra_: i expensed a new rpi3 board [15:31] creap [15:32] i guess i owe you a beer then, i bet it was the "plug HDMI whiloe on power" [15:32] ogra_: probably, the spi/i2c expansion bus is busted too, so... [15:32] 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] (i always forget that there is no proper grounding) [15:32] where do i modify the source?.... in the part folder? [15:33] kgunn, you want to modify the pulled source? [15:33] kgunn, yeah, it's in parts//src [15:34] ppisati, i still cant imagine why it would be PM though ... [15:34] kgunn, though note that if the source is local, they're hard links. That might help a little [15:34] ppisati, i.e. why does it only happen on the very first boot [15:34] i would expect it to have similar issues after reboot [15:34] kyrofa: right, just the pulled src [15:35] yeah, it's not local... [15:35] Then yeah, that's what you want [15:35] avoiding the separate change+push [15:35] Careful not to kill your changes by cleaning completely, though! [15:35] will push later when i figure it out :) [15:35] @complete clean...right! [15:35] kgunn: No such command! [15:36] defiant bot ... doesnt want to clean [15:46] sergiusens: do we have a method yet to copy a .desktop file produced by a part's build step into ./setup/gui/ ? === chihchun is now known as chihchun_afk [16:03] mhall119 that was only discussed last week during a session [16:04] * mhall119 wishes we had videos of those sessions [16:17] mvo, bug 1636894 smells a bit critical [16:17] Bug #1636894: [raspberry pi3]pi3 snap is removable [16:20] kyrofa: got a minute? wanna describe something and see if you've got an idea i can try... [16:21] kgunn, yeah, what's up? [16:22] kyrofa: ok, so, i've got 2 snaps (it's a form of mir-server and mir-client, but not exactly).... [16:22] i can build these in classic on the core, and it works without a flaw... [16:22] however, when i run the exact same sceario on snaps...here's how it goes down [16:23] the mir-server comes up fine, nothing strange in logs....but the minute i launch the client the server crashes immediately [16:23] and again, nothing really showing up in logs [16:23] so...wondering, can i include gdb inside my mir-server snap and run it ? [16:23] or some trick like that you might recomment [16:23] recommend even [16:24] snap run --shell $command_inside_your_snap [16:24] then use gdb from that shell [16:24] ogra_, that's still under the same confinement though, no? [16:24] ogra_: well, i can run unconfined, the trouble occurs no matter waht [16:24] also, the classic snap (that i demoed at the sprint) allows attaching to PIDs [16:25] so just apt install gdb and debug away i guess [16:25] kgunn, as ogra_ mentions, could you run gdb as normal and attach to the PID of the app? [16:25] kyrofa, yeah, inside the confinement ... but your gdb runs inside the same sandbox at least [16:25] kgunn, I've also included strace in my snaps before, I can't imagine why gdb wouldn't also work [16:26] ogra_: kyrofa cool...i'll try that, thanks guys [16:26] ogra_, I mean it doesn't have access to gdb [16:26] * kgunn already has classic setup on the image [16:26] not to one you dont ship indeed [16:26] oh while i'm here... ogra_ flexiondotorg do either of you have a recommended power supply to use with pi3 [16:26] as many amps as you can get :P [16:27] current is key .... beyond that ... not really [16:27] 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] ah, attached usb display powered from the onboard usb hub ? [16:27] ogra_: right [16:28] s/usb/hdmi/ [16:28] ogra_: i guess i could try an externally powerd display first... [16:28] i'd go with something like 4A [16:28] cool [16:28] that should be able to even drive a rotary usb disk [16:28] :) [16:31] uh, i guess i should also include dbg syms into my snap [16:31] heh, yeah, that helps [16:40] ogra_: right, super important, not quite critical as you need to do manually disable it first, will work on a fix now [16:41] heh, i didnt mean to cause work for you, i just wanted to set the severity :) [16:46] ogra_: thats fine, I think its also high++ priority :) [16:46] true :) [16:52] PR snapcraft#867 closed: Handle 'broken' validations that don't match refresh-control [16:55] kyrofa, ping [16:55] liuxg, pong [17:00] 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] Croepha, we do have serial enabled by default i think [17:03] (if not, we probably should) [17:04] It looks like its enabled for the kernel, but not grub [17:04] 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] PR snapcraft#873 opened: Release changelog for 2.20 [17:05] ah, yeah, not sure about serial support in grub itself [17:05] we definitely have a console= arg for serial on all images [17:05] nice [17:08] PR snapd#2218 opened: snapstate: ensure gadget/core/kernel can not be disabled [17:17] 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] Bug #1636931 opened: Configure hook not running === Guest66764 is now known as ahasenack [17:36] PR snapd#2219 opened: asserts: limit to 1y only if len(models) == 0 === ahasenack is now known as Guest21645 [17:49] ogra_, two questions if you have a min [17:49] $ snappy config core [17:49] qemu-system-x86_64: could not set up host forwarding rule ':4200::4200' [17:49] qemu-system-x86_64: Device 'user' could not be initialized [17:49] oh thats an old command, bad docs [17:50] er [17:50] kgunn, Pi3 power requires minimum of 2.4amp [17:51] ack [18:13] mvo, I seem to remember discussions about more `snap run` options, like --gdb and --strace, is that right? [18:13] pmcgowan, heh, happy i could be of help :) [18:16] ogra_, but my real question [18:16] my refresh service isnt running, seems it should be? [18:16] how do I check the autoupdate config? [18:17] uh, i dont know ... i know it is a timer [18:17] systemctl | grep timer [18:17] ? [18:21] ogra_, systemctl status -l snapd.refresh.service [18:21] says its inactive [18:22] and systemctl list-timers snapd.refresh.timer [18:22] well, not sure the service contains the timer, i think that is what the timer calls actually [18:22] says 0 timers [18:22] no snap timers [18:23] ogra_, there is a refresh timer on dragonbaord [18:23] i think Chipaca is our specialist for that bit ... bt he doesnt seem to be around [18:23] not on pc [18:24] weird [18:24] same image ? [18:24] image? [18:24] (i mean ... installed from the same image ... i.e. around the same time) [18:24] yeah [18:24] core versions are the sam [18:24] e [18:25] that doesnt matter, the timers are part of the firstboot setup [18:25] this is on my laptop though [18:25] and that might have improved between different image builds (or core versions if you want it like that) [18:25] oh [18:26] i thought you talk kvm vs dragonboard all-snap images [18:26] no sorry [18:26] apple orange [18:26] snapd.refresh.timer loaded active waiting Timer to automatically refresh installed snaps [18:26] that is whyt i get on my laptop [18:26] *what [18:26] hmm [18:27] thats what I see on db [18:27] not sure why yours is disabled ... i think there was a bug once [18:27] how do I enable it now [18:27] bug 1588977 [18:27] Bug #1588977: [2.0.6] snapd.refresh.timer fails

[18:29] ogra_, let me try t enable it [18:29] PR snapd#2218 closed: snapstate: ensure gadget/core/kernel can not be disabled [18:29] PR snapd#2219 closed: asserts: limit to 1y only if len(models) == 0 [18:30] ogra_, its working now and I got the update I expected [18:30] yay [19:01] Bug #1610001 changed: Regression: snap run no longer runs hooks [19:05] PR snapd#2220 opened: overlord/snapstate: fix missing argument to Noticef [19:16] kyrofa: yes, we talked about this [19:16] mvo, still planned, then? [19:17] Just wanted to make kgunn aware, but wanted to make sure I remembered correctly first :) [19:17] kyrofa: yes but no dates or priority attached to it [19:17] Sure [19:17] Thanks mvo :) [19:17]