[08:00] <zyga-ubuntu> o/
[08:01]  * zyga-ubuntu feels useless today
[08:01] <zyga-ubuntu> 30C since early morning
[08:28] <sborovkov> ogra_: Hi. Still trying to get splash screen working. I managed to load it to the RAM. Can read it with bmp info as well. bmp display though does nothing :-( I put image with wrong color depth initially and bmp display actually displayed that in the error message. But after fixing the image it does not complain about anything but does not show anything on the screen as well. Any ideas?
[08:48] <ogra_> sborovkov, not really, no
[08:51] <sborovkov> ogra_: oh well I will try using $splashscreen variable as well instead of bmp display. I am not sure how .env.in works - can I write this splashimage=fastload .... ; 0x100000; Or should I be adding loading the bmp into the memory to the bootcmd?
[08:52] <ogra> i think you just want the var set (afaik u-boot actually checks for it)
[09:00] <sborovkov> ogra: yeah but I need the code to load image into the memory somewhere
[09:02] <ogra> sure, add some code that checks if "bmp info $splashimage" returns something ... if not, run a script to fatload ...
[09:03] <sborovkov> ogra: what code is actually ran when it's starting? I was adding load to the bootcmd. Not sure if that might be too late?
[09:04] <ogra> i'd add it to loadfiles
[09:12] <sborovkov> splashimage=0x02000000 ... loadsplashimage=fatload ${devtype} ${devnum}:${bootpart} $splashimage /screenly.bmp && bmp info $splashimage; Meh. This code executes. Show info about image. But splash image is never displayed.
[09:13] <ogra> ty adding $filesize to the fatload catt
[09:13] <ogra> *try
[09:19] <sborovkov> no, that gives absolutely same result. Displays that the same amount of bytes was read.
[09:24] <ogra> where do you call bmp disaply btw ?
[09:25] <ogra> *display
[09:28] <sborovkov> ogra: I tried adding it to the bootcmd, and then to loadfiles. At the end of that command
[09:29] <sborovkov> also I actually have that splashimage and splashsize variables defined...
[09:34] <pedronis> zyga-ubuntu: Chipaca: hi, I merged the use of numeric http statutes last night
[09:39] <morphis> fgimenez: ping
[09:39] <zyga-ubuntu> pedronis: thank you
[09:39]  * zyga-ubuntu is exhausted by the heat
[09:40] <fgimenez> hey morphis
[09:40] <morphis> fgimenez: if you want you can give https://github.com/morphis/snapd/tree/f/raspbian-as-external a try now
[09:41] <fgimenez> morphis: sure! will let you know how it goes
[09:41] <morphis> SPREAD_TRUST_TEST_KEYS=false SPREAD_SRU_VALIDATION=1 spread -v -resend -reuse external:raspbian-8-arm-32:tests/main/ still gives a few test failures when using that branch but most are because the branch is based on lastest master and we're testing 2.26.4
[09:41] <morphis> rebasing on release/2.26 isn't that easy as it misses all the pkgdb changes
[09:46] <mup> Bug #1632388 changed: console-conf wifi only setup on pi3 Ubuntu Core image not possible <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1632388>
[09:50] <fgimenez> morphis: ok thanks, SPREAD_SRU_VALIDATION is for forcing snapd to be installed from "-proposed"? if that's the case maybe we could rename it
[09:50] <morphis> fgimenez: yeah, I abusing it a bit here
[09:51] <fgimenez> morphis: np :)
[09:51] <morphis> fgimenez: https://github.com/snapcore/snapd/compare/master...morphis:f/raspbian-as-external#diff-6eea9b76e2bf27f60519f7b5c98333c9R222
[09:53] <morphis> fgimenez: but yeah, renaming might be good
[09:54] <fgimenez> morphis: aha IMO makes sense if we rename SRU_VALIDATION to SNAPD_FROM_{ARCHIVE,PROPOSED,..} or something, if not the SRU implies ubuntu
[09:54] <fgimenez> morphis: yep
[09:54] <morphis> +1
[11:00]  * zyga-ubuntu -> coffee
[11:15] <zyga-ubuntu> re
[11:58]  * Chipaca ~> lunch
[12:14] <fgimenez> morphis: btw i'm looking into the errors of the suite running against staging on opensuse it turns out that this error http://paste.ubuntu.com/24872100/ is because of wrong quoting, go's version is fine
[12:14] <morphis> ah!
[12:14] <morphis> sounds like a double quote
[12:14] <fgimenez> morphis: yes, quoting all the string and evaluating it works, now i'm getting http://paste.ubuntu.com/24872106/ maybe the binary wasn't built with the testing keys, will dig further
[12:16] <morphis> fgimenez: that smells like you miss https://github.com/snapcore/snapd/pull/3450
[12:16] <mup> PR snapd#3450: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <https://github.com/snapcore/snapd/pull/3450>
[12:16] <morphis> need to fix these PRs later today
[12:17] <fgimenez> morphis: yes! exactly that :) thx
[12:23] <mup> PR snapd#3487 opened: tests: reenable help test on ubuntu and debian systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3487>
[12:35] <mup> PR snapd#3488 opened: tests: prevent quoting error on opensuse <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3488>
[12:44] <fgimenez> morphis: about the execution on raspbian it looks like external:raspbian-8-arm-32:tests/main/classic-ubuntu-core-transition makes the whole thing fail, it reinstalls the snapd package https://github.com/morphis/snapd/blob/f/raspbian-as-external/tests/main/classic-ubuntu-core-transition/task.yaml#L33 and seems to fail because of a missing "--force-yes"  http://paste.ubuntu.com/24872205/
[12:45] <fgimenez> morphis: other than that, and considering what you mentioned about release/2.26 and master, things look good http://paste.ubuntu.com/24872209/
[12:47] <fgimenez> sorry the link to where snapd is installed without --force-yes is https://github.com/morphis/snapd/blob/f/raspbian-as-external/tests/main/classic-ubuntu-core-transition/task.yaml#L34
[13:03] <Chipaca> fgimenez: standup?
[13:03] <fgimenez> Chipaca: sure omw!
[13:05] <morphis> fgimenez: yeah have similar results
[13:05] <morphis> fgimenez: hm, force-yes doesn't exist on raspbian?
[13:05] <fgimenez> morphis: yes, i needed it to install snapd before executing the suite
[13:05] <morphis> yes
[13:06] <morphis> did the same, is that how SRU_VALIDATION is supposed to work?
[13:06] <morphis> maybe we can tweak the code a bit more to install snapd if missed from either propose (for ubuntu) or just the archive
[13:14] <morphis> fgimenez: hm, apt-get on raspbian has support for -f -y
[13:20] <fgimenez> morphis: mm from the log http://paste.ubuntu.com/24872205/ we are sending just "apt install -y snapd" in distro_install_build_snapd, probably from https://github.com/morphis/snapd/blob/f/raspbian-as-external/tests/lib/pkgdb.sh#L220, probably adding -f there should fix it
[13:22] <morphis> ah
[13:22] <morphis> let me add that
[13:56] <Vamsi> Hi. I just installed snappy core on raspberry pi 3 and followed all the steps to install the demo snaps like "hello". However, after installation I assumed that just typing in the name of the snap is the command to invoke the snap. However, I get the following error:  -bash: hello: command not found
[13:56] <Vamsi> Have I missed out on something while setting up the environment?
[14:07] <ogra> take a look in /snap/bin
[14:07] <ogra> is there a "hello" ?
[14:09] <ogra> snaps can ship multiple binaries ... even daemons, so "typing in the name of the snap is the command to invoke the snap" is often enough not true
[14:14] <ppisati> guys, is there an ETA for snapcraft 2.30/2.31 to land in xenial?
[14:14] <ogra> kyrofa, ^^^
[14:31] <Vamsi> ogra: I get an error saying that such a directory does not exit :|
[14:31] <Vamsi> exist*
[14:32] <ogra> are you sure you are on ubuntu core ?
[14:32] <ogra> :)
[14:33] <kalikiana_> Question: http:/v2/system-info gives me snap-mount-dir (ie. "/snap"). Is there an API that returns "/var/lib/snapd/snaps"? Or is it safe to assume that folder always exists?
[14:37] <Vamsi> ogra: I logged into the pi that running on core from my notebook and installed the snap. So I believe I am on the core?
[14:38] <ogra> Vamsi, which core image did you install =
[14:38] <ogra> ?
[14:38] <Vamsi> http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz
[14:38] <Vamsi> this one
[14:39] <ogra> well,  that definitely has /snap
[14:39] <ogra> (and should also have /snap/bin)
[14:40] <Vamsi> ogra: What happens when I am in the devmode?
[14:40] <ogra> you mean if you installed a snap with --devmode ?
[14:40] <Vamsi> yup
[14:41] <ogra> then the security oprions for the binaries get turned off
[14:41] <ogra> *options
[14:41] <Vamsi> What I was doing was that I was following the "get-started" instructions as given in the link: https://developer.ubuntu.com/core/get-started/developer-setup
[14:42] <ogra> ogra@sabrelite:~$ snap install hello
[14:42] <ogra> hello 2.10 from 'canonical' installed
[14:42] <ogra> ogra@sabrelite:~$ ls /snap/bin/hello
[14:42] <ogra> /snap/bin/hello
[14:43] <ogra> that should be identical on all ubuntu core installs ...
[14:44] <kalikiana_> ogra: Are both /snap and /var/lib/snapd/ guaranteed on all systems with snapd?
[14:45] <Vamsi> So here it was mentioned that i could have a development environment right on the pi itself and thus proceeded to install the classic environment... After which my host changed from vamsi3012@localhost to (classic)vamsi3012@localhost.
[14:45] <ogra> kalikiana_, not sure on classic systems ... (especially on non-ubuntu ones) ... thats a question for the cross-distro guys i guess
[14:45] <ogra> Vamsi, AH!
[14:45] <ogra> Vamsi, ok, then you are in the classic environment
[14:45] <Vamsi> ogra: there is no bin folder :|
[14:45] <kalikiana_> ogra: Any suggestion whom to ask?
[14:45] <ogra> Vamsi, i dont think you can see any snap stuff in there
[14:45] <Vamsi> yes. the classic environment
[14:46] <ogra> kalikiana_, try morphis or zyga-ubuntu
[14:46] <kalikiana_> Thanks!
[14:46] <ogra> Vamsi, right, that pretends to be a classic ubuntu installation (like ubuntu-server) and has no direct access to /snap ... you need to exit ... then you can execute snaps
[14:47] <Vamsi> oh okay. And... um... where can I find a reference to these commands? I'd like to build my knowledge base on that.
[14:47] <ogra> Vamsi, this classic env is really only for building ... to install and run a snap you have built in there you should exit (ctrl-d) and do all snap stuff from the outside
[14:47] <Vamsi> oh okay. Thanks :)
[14:48] <ogra> (also typing "exit" and hitting enter works)
[14:48]  * Chipaca walks in on ogra talking dirty again
[14:48] <ogra> haha
[14:49]  * ogra throws little orangepi-zero's at Chipaca 
[14:49] <Vamsi> So just for to clarify my understanding: Classic environment to develop snaps on the host itself. And exiting this then enbles you to install the snap you just developed?
[14:49] <ogra> yeah
[14:49]  * Chipaca uses a SoundBlaster 16 ISA card as a tennis racket to return it
[14:50] <ogra> with the --dangerous option
[14:50] <ogra> (to tell the system it is not from the store (i.e. sideloaded))
[14:50] <Vamsi> oh okay.
[14:52] <Vamsi> ogra: I am so used to developing on an IDE that I feel an idiot on the command line. Is there an IDE for developing snaps :| :|
[14:53] <ogra> i dont think so ...
[14:53] <ogra> i mean ... snaps are just a package format ... use your normal IDE and then copy the tree to the board and call snapcraft there ... or some such
[14:56] <kyrofa> ppisati, it's in proposed, testing looks good as far as I'm aware (though elopio will know more). I think it'll land soon
[14:57] <elopio> ppisati: the SRU is ready, but they don't land things on Friday. So Monday.
[14:57] <kyrofa> kalikiana_, I don't think /snap is guaranteed at least... I don't think fedora uses it
[14:57] <ogra> they could just wrok through the weekend ... then they could land things on friday too :P
[14:58] <kyrofa> But I think that's less of a concern for us right now, since snapcraft won't run there as a snap anyway
[14:58] <jdstrand> ogra: hey, I grabbed https://code.launchpad.net/~ogra/+junk/linux-generic-bbb and am trying to build a local kernel in a classic chroot on bbb. is that expected to work?
[14:58] <ogra> jdstrand, no idea, never tried :)
[14:59] <kyrofa> (thanks for pinging me ogra, I would have missed that)
[14:59] <ogra> jdstrand, it creates a chroot (or even two stacked ones)
[14:59] <ogra> that might not work inside classic
[14:59] <jdstrand> ogra: basically, I'm trying to simply go from linux-generic deb that I've got from somewhere else and making a snap
[15:00] <ogra> jdstrand, hah, funny coincidence ... i'm just trying the same with a patched deb to add allwinner support
[15:00] <jdstrand> ogra: the chroot operation and the bind mounts work, but I don't know everything that is needed
[15:00] <ogra> though i kept the kernel side for the WE ... i'm just done with the gadget
[15:00] <jdstrand> (as in, I don't know that the classic chroot has everything in it that the makefile is expecting in the chroot it uses
[15:01] <ogra> jdstrand, well, http://bazaar.launchpad.net/~snappy-dev/kernel-snap-makefile/trunk/view/head:/Makefile is what it runs
[15:02] <ogra> the "all:" target just deboostraps a chroot and installs the debs in there
[15:02] <ppisati> elopio: cool, ta
[15:02] <ppisati> kyrofa: ^
[15:02] <jdstrand> ogra: yeah, quite familiar with the script at this point (been playing with it since yesterday :)
[15:03] <jdstrand> but the one you linked to is slightly different than your junk bzr branch I mentioned, so perhaps I should try that
[15:03] <ogra> well, if chroot and the mounting of /proc and /sys work i dont see why classic would get in your way
[15:03] <ogra> jdstrand, oh, right ... we split the Makefile at some point and only kept the snapcraft.yaml
[15:04] <ogra> but there shouldnt be huge differences ...
[15:05] <kyrofa> jdstrand, you're building a kernel on a bbb? Multi-day waitfest?
[15:05] <jdstrand> kyrofa: building as in extracting a deb and snapping that
[15:05] <kyrofa> Oh, well :
[15:05] <kyrofa> Nevermind :P
[15:06] <kyrofa> I was impressed with your resolve
[15:06] <ogra> jdstrand, oh ... note that all these Makefiles assume the image PPA to be enabled on the host
[15:07] <ogra> jdstrand, you want to add that to your classic env
[15:07] <jdstrand> ogra: curious if you would expect this makefile with snapcraft run on classic snap rpi2 to produce a snap for bbb
[15:07] <ogra> else you dont get the initrd scripts
[15:07] <jdstrand> ogra: oohhh!!!
[15:07] <jdstrand> that's probably it
[15:07] <ogra> the snap LP builds have that set by default. i totally forgot about that
[15:07] <jdstrand> I could boot a kernel but it would drop into the initramfs
[15:07] <ogra> yeah
[15:07] <ogra> missing the core initrd scripts
[15:08] <ogra> (or using a very old version at least)
[15:08] <jdstrand> ogra: so classic or the chroot that the makefile generates needs it?
[15:08] <ogra> cp /etc/apt/sources.list chroot/etc/apt/sources.list
[15:08] <ogra> ;)
[15:09] <ogra> the outer env needs it in the sources.list
[15:09] <ogra> the Makefile calls the above cp
[15:09] <jdstrand> right, but I made some modifications to the makefile to add to the chrrot's sources.list
[15:10] <jdstrand> just wondering if that is enough
[15:10] <ogra> (i should perhaps adjust the makefile to call add-apt-repository instead
[15:10] <ogra> )
[15:10] <ogra> (instead of blindly assuming it is set in sources.list)
[15:10] <jdstrand> ogra: ok, this ppa: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
[15:11] <ogra> yep
[15:11] <jdstrand> ok. I'm cautiously optimistic now :)
[15:11] <jdstrand> ogra: thanks!
[15:11] <ogra> good luck ... :)
[15:11] <ogra> (i'm around for any additional questions ...)
[15:12] <jdstrand> ogra: I thought you were off yesterday and today. I saw you chatting here so thought I'd ask. sorry if you are off and just lurking
[15:12] <ogra> i was off yesterday, yeah
[15:12] <ogra> not today though
[15:13] <jdstrand> ok, good. glad I didn't bother you :)
[15:13] <ogra> :)
[15:16] <ogra> GRR ... so the allwinner u-boot binaries can only be built with gcc-6 ... and indeed we dont have a gcc-6-cross backport in xenial
[15:16] <ogra> this will result in awful snapcraft.yaml hackery to create an artful chroot to do the build in :(
[15:17] <ogra> (and indeded all boards i want are also only supported in 4.11+ ... more hackery :/ )
[15:18] <ogra> (on the kernel side that is)
[15:48] <bdx> kyrofa, elopio: would you mind shedding some light on what the next steps for the ruby plugin might be? I've thought of some things to test and wanted to run those by you guys also.
[15:50] <elopio>  bdx: well, next step from my point of view is to fill those integration tests :) That will give us a clear idea of what works.
[15:50] <bdx> I want to test for the existence of the compiled binary files: erb, gem, irb, rake, rdoc, ri, and ruby
[15:50] <elopio> I'll give it a try today with my travis test subject.
[15:51] <bdx> following the build step, I feel like the thing I want to test is "do the things I built exist?", right?
[15:51] <bdx> ok
[15:51] <elopio> right.
[15:52] <elopio> also, that only those and nothing else is left in the install directory.
[15:53] <bdx> ok
[16:24] <mup> PR snapd#3489 opened: tests: add bluetooth-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3489>
[18:13] <jdstrand> ogra: hey, well, I don't have a kernel yet with the new Makefile, but I think I'm close.
[18:13] <jdstrand> ogra: this is what I see in the classic chroot: http://paste.ubuntu.com/24874108/
[18:14] <jdstrand> ogra: before I added to ENV := ... FLASH_KERNEL_SKIP=yes
[18:14] <jdstrand> ogra: so I am trying that again. hopefully with that I'll get a snap and with the ppa initramfs tool I'll get a bootable system
[18:15] <jdstrand> ogra: is FLASH_KERNEL_SKIP=yes safe? it seemed to have the same end result (though not the same mechanism) as what I saw in the buildd logs for your linux-generic-bbb
[18:16] <jdstrand> I'm guessing it is. we don't want to flash anything, and I did have a booting kernel before (it was the initramfs that was the problem)
[18:17] <jdstrand> ogra: if you are interested for Makefile improvements, I did:
[18:17] <jdstrand> ENV := DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANG=C FLASH_KERNEL_SKIP=yes
[18:17] <jdstrand> and in 'all:
[18:17] <jdstrand> echo "deb http://ppa.launchpad.net/snappy-dev/image/ubuntu xenial main" >>chroot/etc/apt/sources.list
[18:17] <jdstrand> $(ENV) chroot chroot apt-key adv --recv-key --keyserver keyserver.ubuntu.com 78E1918602959B9C59103100F1831DDAFC42E99D
[20:40] <jdstrand> ogra: btw, that FLASH_KERNEL_SKIP=yes with the initramfs from the image ppa did the trick. thanks for your help
[21:51] <ryebot> Hey guys, anyone else getting failures trying to install the core snap? http://bit.ly/2syZ2Rp
[23:03] <mup> PR snapcraft#1367 opened: catkin plugin: add support for ROS Lunar <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1367>