[01:41] sergiusens, hi! I can not migrate, but you can just register the name for the series 16 do a new upload (you can use an existing binary) === chihchun_afk is now known as chihchun [04:39] morning, guys! === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:51] ogra_: I updated everything for new images, but my rip2 image does not boot, I wonder if there is some kernel issue maybe? not output after Starting kernel ... [06:51] ogra_: image created with the latest u-d-f from people.c.c:~/mvo/all-snaps [06:53] Morning o/ [07:01] I'm getting "error: can't remove "foo": snap "foo" has changes in progress" for any refresh/remove action. What's going on under the hood? Is there a way to check the status of these "changes"? [07:01] davidcalle: morning! [07:02] davidcalle: try "snap changes" [07:02] davidcalle: and good morning to you as well! [07:02] mvo: hah, thanks, I missed this one in the help :) [07:03] morning [07:03] mvo, snapd 2.0.2 should have fixed the "snaps vanish on reboot" on desktop? [07:06] jibel: yes, only for new installs though, snaps installed with pre 2.0.2 are still affected, it does not "repair" those [07:06] ogra_: I also pushed http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz now would be nice if you could verify it (my dragonboard appears to be broken :/ [07:06] (or anyone else with a dragonboard) [07:10] mvo, all right. I'll reinstall and try again. thanks [07:13] How come this snap https://uappexplorer.com/app/nethack-amd64.ogra cannot be found via "snap find nethack" on Xenial and "sudo snap install nethack-amd64.ogra_0.1.0_amd64.snap" says "error: change finished in status "Hold" with no error message"? The error doesn't tell me what's wrong. [07:14] jibel: thanks [07:21] mvo: another quick question, can't install webdm, can't remove it: http://paste.ubuntu.com/15942446/ (bonus question: when installed, how do you start it? I used to do snappy service) [07:22] davidcalle: that sounds like webdm got installed with snappy <2.0.2 :/ [07:22] davidcalle: sudo systemctl start snap- hopefully gives you the mount unit [07:23] davidcalle: once you started the mount unit manually you can remove and reinstall it (make sure you have snapd 2.0.2 installed when you do that) [07:23] davidcalle: the should give you a list of completions hopefulyl and one of them should be webdm [07:25] mvo: it worked, thanks. I also see a few snappy-* services, leftover cruft? (autopilot.timer, autopilot.service, webdm.snappyd.service, workaround-apparmor.service) [07:33] kalikiana, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175 [07:33] Launchpad bug 1572175 in snapd (Ubuntu) "change finished in status "Hold" with no error message" [Undecided,New] [07:34] davidcalle: it sounds like it, yes [07:35] mvo: alright, thanks [07:37] dholbach: Thanks [07:53] good morning [07:54] dholbach, I cannot find the ubuntu-{clock,calculator} in the store. anything changed? [07:54] they were here yesterday [07:58] jibel, that has to do with version 16 [07:58] jibel: yes, the store was moved, there's a new series (16) and snaps need to be uploaded there (remember to register the name first) [07:58] series, sorry [07:58] I sent dpm a mail about it [07:58] jibel, if you want to test locally, maybe build it from lp:snappy-desktop-examples for now (just run snapcraft) [07:59] zyga, dholbach thanks. I'lll build a snap or 2 and wait until they're uploaded [08:12] is there a release schedule for next version of snappy ubuntu core? .. what is the target for 16.04? [08:13] pjoe: we will do SRUs regularly to fix issues and add new relevant features [08:13] pjoe: (especially new interfaces :-) [08:18] ok, but there will be a 'stable' 16.04 sometime soon? [08:18] * pjoe is still quite new to snappy, so have tons of questions :) [08:19] I've been testing with 15.04 .. but found that bridge-utils are missing so I can't properly setup the network configuration with bridges into lxd containers [08:19] however on rolling 16.04 the lxd snap is missing :( [08:25] also how would I go about to getting a kernel module patch in to my snappy install [08:29] could that be done in an oem-gadget? [08:34] willcooke, when I click on a snap in nautilus should it open gnome-software? [08:35] jibel, it should but it doesn't. Known bug [08:35] k [08:35] willcooke, bug # please? [08:36] willcooke, is there another way to install a local snap with gnome-sfotware? [08:36] jibel, nope [08:37] jibel, https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1570182 [08:37] Launchpad bug 1570182 in gnome-software (Ubuntu) "Support sideloading snap packages" [Medium,Triaged] [08:38] thanks [08:38] nw [08:40] * pjoe reading trhough the porting guide [08:44] morning mvo! Quick question: I noticed you uploaded ubuntu-clock-app-mvo to the store - was that for testing purposes or do I need to change anything in ubuntu-clock-app? [08:45] dpm, the former [08:45] thanks dholbach :) [08:45] dpm, see my mail from this morning on how to do a new upload [08:45] dpm, it'll be required to get clock/calc working on series 16 [08:45] dholbach, yeah, I saw it. I'm packaging calendar now to see the process from the start and see what needs to be changed in the documentation [08:45] cool [08:45] dholbach, thanks for testing it and the summary! [08:46] anytime [08:48] * pjoe scratches head ... ahs partition layout changed? ... the 16.04 i tried only has system-boot and writable .. no system-a/b [08:50] pjoe: yes [08:50] is the new layout documented somewhere? [08:50] pjoe: everything is different, we now mount snaps directly from squashfs [08:50] pjoe: maybe :) [08:50] :) [08:51] * pjoe still trying to get my head wrapped around all this [08:51] any pointers for how I would get a patched kernel module into my install? [08:51] we have this hw watchdog that isn't supported out of the box in the kernel driver [08:52] only a few lines of change in driver code ... but need to figure out how to get it in [08:53] mvo, try the rpi on a monitor ... the serial being broken with the shared uboot is known ... [08:54] ogra_: oh, are there any news concerning rpi2? [08:54] ogra_: is the os-image working again? [08:54] again ? [08:55] did it not work ? [08:55] ogra_: it boots, but I cannot use any snap I installed [08:55] ogra_: wait I'll get the link of my mail to the mailing list [08:56] https://lists.ubuntu.com/archives/snappy-devel/2016-April/001746.html [08:58] pmp, ah, that might be fixed with the img mvo mentioned above (or if you simply build your own from todays snap packages in the store) [09:00] ogra_: thanks for sharing my article! [09:01] thanks for writing it ! [09:03] ogra_: thanks, that's the information I was looking for to hear [09:04] dpm: just testing, ubuntu-clock-app-mvo can go, I will unpublish/remove [09:05] ogra_: aha, if rpi2 is otherwise ok I will upload it as well [09:05] thanks mvo, no worries. I was just wondering if you were uploading a hotfix to the existing clock or something [09:08] ogra_: once you (or someone else) verifies that the dragon works I will send a mail to the mailinglist about the new images [09:08] how can I see what is inside a snap file? [09:08] do I have to mount with squashfs .. or is there some other way [09:09] pjoe: unsquashfs -ls (or -ll) snapfile [09:10] pjoe: or unsquashfs snapfile to unpack it [09:10] thanks .. for now manage to mount it [09:11] hi guys, I just booted the new amd64-all-snap.img. there's stil an issue with eth interface. "ip addr" lists enp2s0 as interface, but in /etc/network/interfaces.d/ it's still called eth0 .. renaming eth0 to enp2s0 (and all stuff inside file) works meanwhile for me .. [09:15] Marco___, file a bug please (we should hanlde it the same as on all other images where we enforce old names) [09:18] btw. I'm testing on a pc with 2 NICs .. trying to unplug cable from one and insert into the other seemed to work pretty badly :( [09:18] like the address of eth0 was never released and routes would still default to the dhcp IP eth0 had gotten [09:19] ok, I'll do so. [09:19] so even though eth1 was up no traffic would work .. at is was still trying to route everything through eth0 [09:19] what is the mechanism for handling dhcp and link states? [09:19] pjoe: that looks like ifupdown, I don't think it handles that at all, you need network manager [09:20] pjoe: the good thing is, it will be snapped soon, with a supporting interface [09:20] heh ... oh don't get me started on nm [09:20] mvo, ah, I missed it, do we have new rp2 images? [09:20] pjoe: well, you're out of options then [09:20] but suppose I can live with it [09:20] so nm will only be a snappy install away? [09:21] * pjoe has been fighting with various nm bugs in the past .. so know some of the code (all too well) [09:22] jamiebennett: yes, since this morning [09:22] jamiebennett: I prepared an annoucement mail but I wait for someone to confirm that the dragonboard image actually works, my dragonboard is unfortunately broken [09:22] is there a readme or something for how to build image with the new alyout? [09:22] mvo, I have one here [09:23] jamiebennett: nice! [09:28] lunchtime .. bbl === pjoe is now known as pjoe_afk [09:34] mvo: I can check [09:34] mvo: mine is operational [09:36] mvo: what is the gadget snap for dragonboard? [09:36] mvo: canonical-dragon is not in the store [09:36] zyga: the image is on people.c.c [09:36] zyga: http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz [09:36] mvo: I tried building it [09:37] mvo: (ubuntu-image) [09:37] mvo: latest udf but it prints this error instead: [09:37] zyga: it should work, you need to build it from the 16 series now, one sec I paste my cmdline [09:37] Determining gadget configuration [09:37] expected a gadget snaps: snap not found [09:37] ahhh [09:37] thanks! [09:37] zyga: http://paste.ubuntu.com/15943880/ [09:38] yes, updated ubuntu-image, thansk [09:38] zyga: :) [09:49] mvo, waiting for dd ... do we have any working smaple package ? [09:52] ogra_: hello-world, xkcd-webserver, go-example-webserver should all work [09:52] ogra_: hm, maybe not go-example-webserver [09:53] ogra_: links :) [09:53] ogra_: I thnk dholbach uploaded moon buggy too and links from zyga [09:53] zyga: :) [09:53] ogra_: though no armhf build [09:53] ogra_: I can make one in ~30 minutes if you need one [09:53] hello-world is enough :) [09:55] so we got a shiny store update but i'm still offered the canonical-pi2 gadget in snap find on arm64 ... tsk [09:55] (and -i386 and -pc) [09:55] ogra_: they are all arch indep [09:55] ogra_: we really need to filter gaget from default searches [09:55] yes, thats what i mean ;) [09:56] or have a --filter option for package types :) [09:56] ogra_: lets put it on the pile 223434 items we want to polish ;) [09:58] mvo, thumbs up for the dragon ... serial, monitor and ssh logins work, i can install, find, list and remove snaps [09:58] ogra_: \o/ [09:58] why is it not upgradeable btw ? [09:58] (you say that in etherpad [09:58] ) [09:58] ogra_: it is upgradable, it will just not do it by itself [09:59] ogra_: the auto update timer job is broken because we have only snap refresh [09:59] oh, right, my bad [09:59] i.e. no "refresh all" [09:59] you wrote auto-update [09:59] ogra_: feel free to correct in the pad so that its clearer [09:59] i thihnk we should mention the dropped config interface ... beyond that i think it is fine === pjoe_afk is now known as pjoe [10:00] ogra_: good idea, let me add this [10:02] ogra_: I actually think I should get these images on cdimage instead and remove the current (outdated) ones, will clarify with the release team [10:02] mvo, oh, see Marco___ above ... no auto config of network interfaces on amd64 [10:02] ogra_: really? that works for me in kvm, I have eth0 with a valid IP [10:02] (we need net.ifnames=0 on the commandline) [10:03] mvo, not on real HW where the interface wont be called eth0 [10:03] * pjoe is on amd64 device .. so at least don't need xcompile :) [10:03] its a simple addition to the kernel commandline to enforce the ethX names [10:04] is this the place to find newest image: http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ ... or is it better to build image myself? [10:04] pjoe, if you want to help testing http://people.canonical.com/~mvo/all-snaps/ is the place ;) [10:05] ok, will give it a try [10:05] we'll release these als 16.04 alpha soon [10:05] nice [10:06] ogra_: meh, I thought we had code that detects the interface name in firstboot. oh well, I release note it, thank you [10:07] * ogra_ wonders if there isnt a way to enforce a werid name in kvm ... would make sense to have that in the tests [10:08] * pjoe reads more about how to make snaps ... wouldn't mind trying to get lxd up on latest img [10:14] wow [10:14] so booting kvm with: -net nic,model=e1000,name=foobar0 ... makes it hang on boot [10:15] (firstboot and sys-subsystem-net-devices-eth0 give an unlimited systemd counter in the shell) [10:16] ah, the eth0 job timed out now ... [10:17] doesnt look like firstboot will ... [10:18] mvo, "boot will hang" in the etherpad should probably get added "forever" (doesnt seem like it will move on here with the mangled nic setup in kvm) [10:18] ogra_: added, thanks [10:18] bah [10:18] and as i saw you writing it it moved on [10:19] * ogra_ deletes again [10:19] added a correct time estimage instead :) [10:21] mvo, heh, webdm ? [10:21] (currently broken ) [10:21] i'm surprised you installed it [10:27] hmm that amd64-all img doesn't boot for me :( sad panda [10:27] how do you try to run it ? [10:27] ogra_: well, *maybe* we will update to something that works later ;) [10:27] mvo, yeah, but i see it only on amd64 :) [10:28] dd to usb and boot on device .. looks like it kind find or load the snaps [10:28] how does the boot hang ? [10:28] getting no such file or dir for the ubuntu-core and canonical-pc-linux [10:28] damn [10:29] could this be the missing squashfs boot param? [10:29] ogra_: indeed, silly me, fixing my build scripts [10:29] mvo, i guess i need to re-enable MODULES=most for the initrd :/ [10:29] ogra_: :/ [10:29] pjoe, no, most likely a missing module for your disk controller [10:29] Marco___: re bug #1572466 when the machine boots snappy, does ifconfig show anything at all beside the "lo" interface? [10:29] bug 1572466 in Snappy "eth interface naming" [Undecided,New] https://launchpad.net/bugs/1572466 [10:30] (or USB in your case ... i added usb-storage to the initrd but i fear there are lower level bits missing) [10:30] ok ... will try to look for more info ... unfotrunately this device doesn't have serial tty .. so I'm limittede to what hasn't already scrolled off the screen :( [10:30] yeah, i know what you mean :) [10:33] hmmm wondering if it's because I also have an ssd disk on the device ... with old snappy 15.04 installed [10:33] maybe it's trying to mount from there [10:33] oh ! [10:33] time to get the screwdriver out :D [10:34] well, you could boot from some other mediaq and just remove thje "writable" label from the partition on the SSD [10:34] that is all we look for [10:34] will try simple disconnected ssd first ... should be fastest way to test for me [10:35] heh, ok [10:35] let us know how it goes [10:36] will do [10:37] fwiw I didn't have that issue with the image from: http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ [10:37] the image design changed quite a lot [10:38] (single partition, everything is a snap) [10:38] okbut that one still has only writable part ... no sys-a/b [10:38] and it also said 16.04 when it booted (even though the download is from 15.04) :D [10:39] * pjoe got the device open now [10:40] that cant really be ... [10:40] ogra@nusakan:~$ ls -l /srv/cdimage.ubuntu.com/www/full/ubuntu-snappy/15.04/edge/* [10:40] -rw-r--r-- 1 cdimage cdimage 144411420 Jul 7 2015 /srv/cdimage.ubuntu.com/www/full/ubuntu-snappy/15.04/edge/ubuntu-15.04-snappy-amd64-generic.img.xz [10:40] i dont think we had teh single partition layout on Jul 7th [10:41] weird ... pretty sure that was where I found it [10:42] ok booting now without the ssd ... looks more promising :) [10:42] phew [10:42] it even got ip addr :D [10:43] and ssh works .. so far so good :) [10:44] but there is no snappy .. only snap command [10:44] ok, then the initrd isnt faulty ... phew [10:44] that 15.04 edge I tried before had both ... guess it might have been mid transition :D [10:45] heh, yeah, it was mid transition for the last 4 months or so :) [10:46] but still no lxd snap :S ... will need to dig into how to get that done for 16.04 [10:46] yeah, now that the setup is final all the snaps need to be adjusted for it [10:46] huh .. but nic interface name is back to eth0 ... before was en1sp0 [10:46] oh well [10:47] ah, thats actually good [10:47] * pjoe testing if the other interface then is eth1 [10:48] hmmm [10:48] maybe needs a reboot [10:49] ahhh can see on console other nic is en2sp0 ... always good to mix things up [10:49] dholbach: dpm got qtox working! 😃 [10:50] * pjoe really misses vim on snappy ... will have to manage with just vi [10:50] dholbach: dpm we finally have a GUI example http://bazaar.launchpad.net/~snappers/snappy-playpen/trunk/files/head:/qtox/ :) [10:51] popey, nice, good work! [10:52] btw. any tricks for optimizing boot time? .... coming from coreos it seems to boot quite a bit slower [10:54] huh .. after reboot no network ifs came up [10:54] think I saw in console eth0 had become en1sp0 [10:54] yeah, nics have new names in recent kernels [10:55] well first time it booted it was eth0 and got an IP [10:56] hmm [10:57] mvo: bug #1572466: on first boot ifconfig shows up eth0. all following boots it only shows lo. ip addr shows enp2s0 additionally to lo [10:57] bug 1572466 in Snappy "eth interface naming" [Undecided,New] https://launchpad.net/bugs/1572466 [10:59] sounds like what I'm seeing [11:02] heh had a typo ens1p0 instead of enp1s0 ... think things are coming up now [11:02] pjoe, echo "set nocompatible" >.vimrc [11:02] ;) [11:02] that gives you normal vim behaviour in vi [11:03] ahh so it is the full vim binary ... sweet [11:03] its stripped down ... but at least it behaves like normal vim [11:03] (you can use cursor keys in insert mode etc) [11:03] * pjoe is still trying to learn vim ... guess that will always be an ongoing process :D [11:03] sergiusens, hi! If I'm creating a local snapcraft plugin, is there any way to specify the launch command, other than me having to ship a separate app.launch script? [11:05] I can see both nics now :D ... as enp1/2s0 [11:06] * ogra_ curses ... why is LP timing out for me [11:07] snap find '*' is a pretty short list now though :S [11:08] * pjoe tries if my network bridging setup at least now wroks and persists [11:09] * ogra_ updates info on bug 1572466 [11:09] bug 1572466 in Snappy "net.ifnames=0 missing on kernel commandline in amd64 images" [Undecided,Confirmed] https://launchpad.net/bugs/1572466 [11:09] heh doing 'mount' show a pretty long list [11:10] yeah, thats the "bind mount farm" ... that gives you some writable files [11:11] btw. how does path work? ... does all snaps get inserted in path or do they put things in liek /usr/bin [11:13] oh btw. when connecting through mikrotik routers I get weird errors like this: - Download snap "nmap" from channel "stable" (Get https://068ed04f23.site.internapcdn.net/download-snap/McFtwWmHVzBWwYSVtXzCdJ6Rt4STQPtl_17.snap?t=2016-04-21T11:12:20Z&h=0078afbef70454c19e106b106682012950b32e9c: dial tcp: lookup 068ed04f23.site.internapcdn.net on 192.168.88.1:53: cannot unmarshal DNS message) [11:13] never seen that kind of thing before [11:17] is snap implemented in go? ... it sounds a bit like this: https://github.com/golang/go/issues/11070 [11:18] I'm guessing the router has some kind of dns proxy doing some funny biz [11:18] pjoe, yes [11:18] kool [11:19] * pjoe has been very fond of go so far [11:19] wow, nmap works really nicely [11:19] * ogra_ guesses he should get nethack ported to the new world ... [11:21] * pjoe using beego framework for some backend stuff [11:23] mvo, no pi3 image btw ? [11:23] i also dont see pi3 in snap find :/ [11:23] doing 'snap install nmap' when using openwrt router works just fine ... again must be the other router doing funny dns proxy stuff [11:24] yeah [11:24] mvo might be able to tell you if/how you can set up a proxy [11:24] * ogra_ imagines you can use http_proxy like on other ubuntus [11:26] no worries ... stil just trying to understand what works and what doesn't ... and how things work [11:26] e.g. how do snaps get their binaries into path ... can see from nmap that it ends up in /snap/bin [11:26] but it isn't bind mounted there .. is it just linked? [11:28] pjoe: those executables are wrappers generated by snappy [11:28] pjoe: they are not the real executable [11:28] ahh, I see [11:28] does anyone know whats going on with ubuntu snappy desktop ? i remember reading about plans to eventually make snappy the default package management system on desktop and was quite excited about it but i havent come across any news on this ever since [11:29] hdtvee, where did you read that (not true) [11:29] hold on [11:29] hdtvee: it has been added to 16.04 as as a default install, you can use the new snaps alongside the good old debs [11:29] hdtvee: 16.04 is not snap-based though [11:29] hdtvee, deb will stay the default, but snaps are supported by default as well [11:30] the system is (and will stay) deb based [11:30] Will it be possible in 2.0 to run a config script at install time to set things up? Things like creating folders and files for the various services installed with the snap [11:30] by 16.10 there might be snappy based desktop images too ... but they wont replace the existing desktop [11:30] https://www.maketecheasier.com/ubuntu-snappy-what-you-need-to-know/ [11:31] oparoz_, you can do that today in your snap startup scripts (you wont be able to create dirs in the system, and why would you though) [11:32] oparoz_: no [11:32] oparoz_: you can do that when your service starts [11:32] hdtvee, thats nonsense ... the existing desktop installs wont go away [11:32] oparoz_: but you cannot run any scripts at install time [11:32] Thanks zyga. The problem is that scripts are started at random, so each and every daemon needs to include the setup script [11:32] hdtvee, as i said, tzhere might be additional snappy based desktop images at some point, but we would be insane to stop providing the existing stuff :) [11:33] ogra_: that article talks about frameworks :-( [11:33] too many people use it and depend on it [11:33] oparoz_: you should patch your daemon to use the snappy dirs [11:33] zyga, they do already [11:33] oparoz_: each snap has a snap-wide data and per-user data (which daemons don't really use since they run as the root user) [11:33] zyga, yeah, some research might have helped :) [11:33] zyga, but we have to re-create everything on the writable partition in order to organise things [11:33] ogra_: internet journalism ;) [11:33] yep [11:33] oparoz_: ? [11:34] as long as it pays off :P [11:34] zyga, create var/log, var/tmp var/run [11:34] zyga, create folders for apps to put their files in [11:34] zyga, typically something you only do once [11:35] oparoz_: snaps cannot do that, you cannot write to /var/log or /var/tmp or /var/run, you have to patch the daemon code to use s$SNAP_DATA [11:35] oparoz_: those directories *are* set up for you by snappy [11:35] zyga, yes, but those folders would be $SNAP_DATA/var/tmp, etc. [11:36] zyga, so we know where all logs files, sockets, etc. are [11:36] oparoz_: well, you can just organize that space in some way, note that /var/tmp won't be removed on reboot, the socket can be just directly in $SNAP_DATA/foo.socket, etc [11:36] oparoz_: if you reorganize the code around snappy concepts it should be easier [11:36] * zyga -> lunch [11:37] oparoz_, just add a startup wrapper that creates them if they dont exist [11:37] underneath your snap dir [11:37] and make sure all bits you need are in that snap and know that they should write there [11:37] thats the proper way to do it in snappy [11:38] ogra_, that's what I'm doing today. I call a filesytem_setup script, but I thought it would be more efficient to be able to call it once at install time, because that's when changes will happen [11:38] I don't like the idea of polluting $SNAP_DATA with log files, sockets, pids, app folders, etc. [11:39] oparoz_, just check for SNAP_VERSION ... and comparie it to a stamp file [11:39] then you can call it only on upgrade [11:39] ogra_, good idea :) [11:40] though dont forget that people can roll back :) [11:40] your check needs to cover that [11:40] true [11:41] ogra_, but with snap version, the script will be run every time a service is started when the snap is first installed [11:41] hdtvee: I am making a video that explains Snappy, that might be of interest to you :) [11:41] overall it's not a big deal, but that means adding something to the documentation of a snap, telling people that every daemon as to include a call to that script [11:42] *has [11:42] oparoz_, well, it can be a two liner ... wont really be noticeable [11:42] ogra_, Indeed [11:42] MichaelTunnell, alright link it when it's ready [11:52] * pjoe got persistent network bridge working :) [11:53] also looks like it would be possible to have custom kernel modules in a oem-gadget-snap [11:53] at least canonical-pc-linux looks to have kernel moduls :) [11:53] not really, you want them in a custom kernel snap instead [11:54] ahh you can do that [11:54] gadget (formerly oem) = bootloader and specifications [11:54] things slowly starting to fall into place for me [11:54] kernel = all the other HW bits [11:54] note that both are in the process being re-defined though [11:55] (but i guess the basics above wont change) [11:55] so you can have a custom kernel snap .. with patched kernel modules and what not ... and you can update that at your own pace independently of ubuntu-core snap [11:55] if you would ship a graphics driver it would be in the kernel snap ... together with the libs it needs [11:55] Good morning [11:56] I 'just' need to patch a whatchdog drive module to support specific chipset [11:56] driver [11:56] ogra_: proxy is a tiny bit tricky, needs a systemd environment setup, I can post details if someone needs them [11:57] mvo, pjoe might [11:57] ogra_: pi3 - how do we make those? whats the gadget/kernel? happy to build some [11:57] so canonical-pc-linux is the default kernel snap [11:57] mvo, same as pi2 but with the canonical-pi3 gadget (note it is identical to pi2 currently, but i'll change that soon [11:57] ) [11:57] pjoe, right [11:57] ogra_: would be nice to clarify with e.g. jamiebennett if we should host pi3 images under the .canonical namespace or if those should be a different namespace (more community oriented) [11:58] ogra_: aha, ok [11:58] i wanted a generic pi image ... but neither ppisati nor I got serial to worjk on the pi2 with the pi3 uboot [11:58] mvo, ogra_, I'd like to move out the community builds to their own space, just to improve the clarity [11:59] that means we need two separate gadgets ... beyond that the image is identical [11:59] ogra_: didn't pi3 change serial lines around so that it can talk to bluetooth? [11:59] ogra_: debug serial moved to then next one [11:59] jamiebennett, the querstion is weather pi3 should be a community build :) [11:59] ogra_, something to discuss at the sprint ;) [11:59] zyga, right ... and sadly it does that inside uboot [11:59] ogra_: ahhh [12:00] jamiebennett, we support the pi as default arch ... and i suspect the pi2 deliveries go down over time ... so i'd definitely keep it supported [12:00] (and rather drop pi2 after a while) [12:01] ogra_, agree (although keep pi2) but whether is it officially blessed or part of the community is up for discussion [12:01] I suspect it is more the former though [12:01] especially since the pi3 is better suited for IoT with wlan and BT by default [12:03] * pjoe goes reading about how to build snaps ... to try and figure out how much it would take to get lxd up [12:03] you want to read about snapcraft [12:03] it also has examples [12:04] looking here: https://developer.ubuntu.com/en/snappy/build-apps/get-started/ [12:04] (note that you need a xenial systeom or at least a xenial chroot with snapcraft 2.x) [12:04] heh is planning to update my laptop tomorrow [12:04] but guessing maybe docker 16.04 could do for today [12:04] or even lxd 16.04 :D [12:08] yeah [12:13] dpm: do you have any snaps which use an icon and .desktop file, I'd like to take a look and see how you did it [12:15] popey, both the clock and calculator apps do. You just need to 1) drop the icon and .desktop file in a setup/gui directory 2) make the icon field in the desktop file be: Icon=${SNAP}/meta/gui/$YOURICON.png [12:16] popey, http://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/files/head:/setup/gui/ [12:17] it's a bit of duplication, as it's a manually crafted .desktop file as opposed to the already built one, but as far as I could tell, there wasn't a way to use the built one [12:17] magic, thanks dpm [12:21] np [12:28] dpm we will grow plugin meshing with apps once we have a clear design for this; sorry its not there yet; but we also really want it for other use cases; it is just that they are too disparate as they are [12:29] sergiusens, it's fine, for now it helps me to know there is no other way. [12:31] sergiusens, also, I find myself copying and pasting the same wrapper over and over for the core apps. I've now started using a custom plugin based on the old qml plugin. If I get it in shape and submit it to snapcraft, would it make sense to get it back upstream? Or was there any particular issue for which it was dropped, other than being unmaintaned? [12:34] kyrofa elopio hey, today its all hands on deck on vila's PR :-) [12:35] sergiusens, you got it [12:35] * vila runs twice as fast [12:36] sergiusens: happy to discuss anything really, things are still moving server-side but I catch up quickly [12:37] sergiusens, kyrofa, elopio: mainly because store_tests can be run against staging so I can validate before prod is available [12:37]