[01:41] <nessita> 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)
[04:39] <netpheak> morning, guys!
[06:51] <mvo> 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] <mvo> ogra_: image created with the latest u-d-f from people.c.c:~/mvo/all-snaps
[06:53] <davidcalle> Morning o/
[07:01] <davidcalle> 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] <nhaines> davidcalle: morning!
[07:02] <mvo> davidcalle: try "snap changes"
[07:02] <mvo> davidcalle: and good morning to you as well!
[07:02] <davidcalle> mvo: hah, thanks, I missed this one in the help :)
[07:03] <jibel> morning
[07:03] <jibel> mvo, snapd 2.0.2 should have fixed the "snaps vanish on reboot" on desktop?
[07:06] <mvo> jibel: yes, only for new installs though, snaps installed with pre 2.0.2 are still affected, it does not "repair" those
[07:06] <mvo> 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] <mvo> (or anyone else with a dragonboard)
[07:10] <jibel> mvo, all right. I'll reinstall and try again. thanks
[07:13] <kalikiana> 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] <mvo> jibel: thanks
[07:21] <davidcalle> 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] <mvo> davidcalle: that sounds like webdm got installed with snappy <2.0.2 :/
[07:22] <mvo> davidcalle: sudo systemctl start snap-<tab> hopefully gives you the mount unit
[07:23] <mvo> 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] <mvo> davidcalle: the <tab> should give you a list of completions hopefulyl and one of them should be webdm
[07:25] <davidcalle> 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] <dholbach> kalikiana, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175
[07:34] <mvo> davidcalle: it sounds like it, yes
[07:35] <davidcalle> mvo: alright, thanks
[07:37] <kalikiana> dholbach: Thanks
[07:53] <zyga> good morning
[07:54] <jibel> dholbach, I cannot find the ubuntu-{clock,calculator} in the store. anything changed?
[07:54] <jibel> they were here yesterday
[07:58] <dholbach> jibel, that has to do with version 16
[07:58] <zyga> 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] <dholbach> series, sorry
[07:58] <dholbach> I sent dpm a mail about it
[07:58] <dholbach> jibel, if you want to test locally, maybe build it from lp:snappy-desktop-examples for now (just run snapcraft)
[07:59] <jibel> zyga, dholbach thanks. I'lll build a snap or 2 and wait until they're uploaded
[08:12] <pjoe> is there a release schedule for next version of snappy ubuntu core? .. what is the target for 16.04?
[08:13] <zyga> pjoe: we will do SRUs regularly to fix issues and add new relevant features
[08:13] <zyga> pjoe: (especially new interfaces :-)
[08:18] <pjoe> 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] <pjoe> 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] <pjoe> however on rolling 16.04 the lxd snap is missing :(
[08:25] <pjoe> also how would I go about to getting a kernel module patch in to my snappy install
[08:29] <pjoe> could that be done in an oem-gadget?
[08:34] <jibel> willcooke, when I click on a snap in nautilus should it open gnome-software?
[08:35] <willcooke> jibel, it should but it doesn't.  Known bug
[08:35] <jibel> k
[08:35] <jibel> willcooke, bug # please?
[08:36] <jibel> willcooke, is there another way to install a local snap with gnome-sfotware?
[08:36] <willcooke> jibel, nope
[08:37] <willcooke> jibel, https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1570182
[08:38] <jibel> thanks
[08:38] <willcooke> nw
[08:40]  * pjoe reading trhough the porting guide
[08:44] <dpm> 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] <dholbach> dpm, the former
[08:45] <dpm> thanks dholbach :)
[08:45] <dholbach> dpm, see my mail from this morning on how to do a new upload
[08:45] <dholbach> dpm, it'll be required to get clock/calc working on series 16
[08:45] <dpm> 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] <dholbach> cool
[08:45] <dpm> dholbach, thanks for testing it and the summary!
[08:46] <dholbach> 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] <zyga> pjoe: yes
[08:50] <pjoe> is the new layout documented somewhere?
[08:50] <zyga> pjoe: everything is different, we now mount snaps directly from squashfs
[08:50] <zyga> pjoe: maybe :)
[08:50] <pjoe> :)
[08:51]  * pjoe still trying to get my head wrapped around all this
[08:51] <pjoe> any pointers for how I would get a patched kernel module into my install?
[08:51] <pjoe> we have this hw watchdog that isn't supported out of the box in the kernel driver
[08:52] <pjoe> only a few lines of change in driver code ... but need to figure out how to get it in
[08:53] <ogra_> mvo, try the rpi on a monitor ... the serial being broken with the shared uboot is known ...
[08:54] <pmp> ogra_: oh, are there any news concerning rpi2?
[08:54] <pmp> ogra_: is the os-image working again?
[08:54] <ogra_> again ?
[08:55] <ogra_> did it not work ?
[08:55] <pmp> ogra_: it boots, but I cannot use any snap I installed
[08:55] <pmp> ogra_: wait I'll get the link of my mail to the mailing list
[08:56] <pmp> https://lists.ubuntu.com/archives/snappy-devel/2016-April/001746.html
[08:58] <ogra_> 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] <zyga> ogra_: thanks for sharing my article!
[09:01] <ogra_> thanks for writing it !
[09:03] <pmp> ogra_: thanks, that's the information I was looking for to hear
[09:04] <mvo> dpm: just testing, ubuntu-clock-app-mvo can go, I will unpublish/remove
[09:05] <mvo> ogra_: aha, if rpi2 is otherwise ok I will upload it as well
[09:05] <dpm> thanks mvo, no worries. I was just wondering if you were uploading a hotfix to the existing clock or something
[09:08] <mvo> 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] <pjoe> how can I see what is inside a snap file?
[09:08] <pjoe> do I have to mount with squashfs .. or is there some other way
[09:09] <mvo> pjoe: unsquashfs -ls (or -ll) snapfile
[09:10] <mvo> pjoe: or unsquashfs snapfile to unpack it
[09:10] <pjoe> thanks .. for now manage to mount it
[09:11] <Marco___> 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] <ogra_> Marco___, file a bug please (we should hanlde it the same as on all other images where we enforce old names)
[09:18] <pjoe> 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] <pjoe> like the address of eth0 was never released and routes would still default to the dhcp IP eth0 had gotten
[09:19] <Marco___> ok, I'll do so.
[09:19] <pjoe> so even though eth1 was up no traffic would work .. at is was still trying to route everything through eth0
[09:19] <pjoe> what is the mechanism for handling dhcp and link states?
[09:19] <zyga> pjoe: that looks like ifupdown, I don't think it handles that at all, you need network manager
[09:20] <zyga> pjoe: the good thing is, it will be snapped soon, with a supporting interface
[09:20] <pjoe> heh ... oh don't get me started on nm
[09:20] <jamiebennett> mvo, ah, I missed it, do we have new rp2 images?
[09:20] <zyga> pjoe: well, you're out of options then
[09:20] <pjoe> but suppose I can live with it
[09:20] <pjoe> 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] <mvo> jamiebennett: yes, since this morning
[09:22] <mvo> 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] <pjoe> is there a readme or something for how to build image with the new alyout?
[09:22] <jamiebennett> mvo, I have one here
[09:23] <mvo> jamiebennett: nice!
[09:28] <pjoe> lunchtime .. bbl
[09:34] <zyga> mvo: I can check
[09:34] <zyga> mvo: mine is operational
[09:36] <zyga> mvo: what is the gadget snap for dragonboard?
[09:36] <zyga> mvo: canonical-dragon is not in the store
[09:36] <mvo> zyga: the image is on people.c.c
[09:36] <mvo> zyga: http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz
[09:36] <zyga> mvo: I tried building it
[09:37] <zyga> mvo: (ubuntu-image)
[09:37] <zyga> mvo: latest udf but it prints this error instead:
[09:37] <mvo> zyga: it should work, you need to build it from the 16 series now, one sec I paste my cmdline
[09:37] <zyga> Determining gadget configuration
[09:37] <zyga> expected a gadget snaps: snap not found
[09:37] <zyga> ahhh
[09:37] <zyga> thanks!
[09:37] <mvo> zyga: http://paste.ubuntu.com/15943880/
[09:38] <zyga> yes, updated ubuntu-image, thansk
[09:38] <mvo> zyga: :)
[09:49] <ogra_> mvo, waiting for dd ... do we have any working smaple package ?
[09:52] <mvo> ogra_: hello-world, xkcd-webserver, go-example-webserver should all work
[09:52] <mvo> ogra_: hm, maybe not go-example-webserver
[09:53] <zyga> ogra_: links :)
[09:53] <mvo> ogra_: I thnk dholbach uploaded moon buggy too and links from zyga
[09:53] <mvo> zyga:  :)
[09:53] <zyga> ogra_: though no armhf build
[09:53] <zyga> ogra_: I can make one in ~30 minutes if you need one
[09:53] <ogra_> hello-world is enough :)
[09:55] <ogra_> so we got a shiny store update but i'm still offered the canonical-pi2 gadget in snap find on arm64 ... tsk
[09:55] <ogra_> (and -i386 and -pc)
[09:55] <mvo> ogra_: they are all arch indep
[09:55] <mvo> ogra_: we really need to filter gaget from default searches
[09:55] <ogra_> yes, thats what i mean ;)
[09:56] <ogra_> or have a --filter option for package types :)
[09:56] <mvo> ogra_: lets put it on the pile 223434 items we want to polish ;)
[09:58] <ogra_> mvo, thumbs up for the dragon ... serial, monitor and ssh logins work, i can install, find, list and remove snaps
[09:58] <mvo> ogra_: \o/
[09:58] <ogra_> why is it not upgradeable btw ?
[09:58] <ogra_> (you say that in etherpad
[09:58] <ogra_> )
[09:58] <mvo> ogra_: it is upgradable, it will just not do it by itself
[09:59] <mvo> ogra_: the auto update timer job is broken because we have only snap refresh <snap>
[09:59] <ogra_> oh, right, my bad
[09:59] <mvo> i.e. no "refresh all"
[09:59] <ogra_> you wrote auto-update
[09:59] <mvo> ogra_: feel free to correct in the pad so that its clearer
[09:59] <ogra_> i thihnk we should mention the dropped config interface ... beyond that i think it is fine
[10:00] <mvo> ogra_: good idea, let me add this
[10:02] <mvo> 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] <ogra_> mvo, oh, see Marco___ above ... no auto config of network interfaces on amd64
[10:02] <mvo> ogra_: really? that works for me in kvm, I have eth0 with a valid IP
[10:02] <ogra_> (we need net.ifnames=0 on the commandline)
[10:03] <ogra_> 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] <ogra_> its a simple addition to the kernel commandline to enforce the ethX names
[10:04] <pjoe> 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] <ogra_> pjoe, if you want to help testing http://people.canonical.com/~mvo/all-snaps/ is the place ;)
[10:05] <pjoe> ok, will give it a try
[10:05] <ogra_> we'll release these als 16.04 alpha soon
[10:05] <pjoe> nice
[10:06] <mvo> 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] <ogra_> wow
[10:14] <ogra_> so booting kvm with: -net nic,model=e1000,name=foobar0 ... makes it hang on boot
[10:15] <ogra_> (firstboot and sys-subsystem-net-devices-eth0 give an unlimited systemd counter in the shell)
[10:16] <ogra_> ah, the eth0 job timed out now ...
[10:17] <ogra_> doesnt look like firstboot will ...
[10:18] <ogra_> 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] <mvo> ogra_: added, thanks
[10:18] <ogra_> bah
[10:18] <ogra_> and as i saw you writing it it moved on
[10:19]  * ogra_ deletes again
[10:19] <ogra_> added a correct time estimage instead :)
[10:21] <ogra_> mvo, heh, webdm ?
[10:21] <ogra_> (currently broken )
[10:21] <ogra_> i'm surprised you installed it
[10:27] <pjoe> hmm that amd64-all img doesn't boot for me :( sad panda
[10:27] <ogra_> how do you try to run it ?
[10:27] <mvo> ogra_: well, *maybe* we will update to something that works later ;)
[10:27] <ogra_> mvo, yeah, but i see it only on amd64 :)
[10:28] <pjoe> dd to usb and boot on device .. looks like it kind find or load the snaps
[10:28] <ogra_> how does the boot hang ?
[10:28] <pjoe> getting no such file or dir for the ubuntu-core and canonical-pc-linux
[10:28] <ogra_> damn
[10:29] <pjoe> could this be the missing squashfs boot param?
[10:29] <mvo> ogra_: indeed, silly me, fixing my build scripts
[10:29] <ogra_> mvo, i guess i need to re-enable MODULES=most for the initrd :/
[10:29] <mvo> ogra_: :/
[10:29] <ogra_> pjoe, no, most likely a missing module for your disk controller
[10:29] <mvo> Marco___: re bug #1572466 when the machine boots snappy, does ifconfig show anything at all beside the "lo" interface?
[10:30] <ogra_> (or USB in your case ... i added usb-storage to the initrd but i fear there are lower level bits missing)
[10:30] <pjoe> 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] <ogra_> yeah, i know what you mean :)
[10:33] <pjoe> hmmm wondering if it's because I also have an ssd disk on the device ... with old snappy 15.04 installed
[10:33] <pjoe> maybe it's trying to mount from there
[10:33] <ogra_> oh !
[10:33] <pjoe> time to get the screwdriver out :D
[10:34] <ogra_> well, you could boot from some other mediaq and just remove thje "writable" label from the partition on the SSD
[10:34] <ogra_> that is all we look for
[10:34] <pjoe> will try simple disconnected ssd first ... should be fastest way to test for me
[10:35] <ogra_> heh, ok
[10:35] <ogra_> let us know how it goes
[10:36] <pjoe> will do
[10:37] <pjoe> fwiw I didn't have that issue with the image from: http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/
[10:37] <ogra_> the image design changed quite a lot
[10:38] <ogra_> (single partition, everything is a snap)
[10:38] <pjoe> okbut that one still has only writable part ... no sys-a/b
[10:38] <pjoe> 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] <ogra_> that cant really be ...
[10:40] <ogra_> ogra@nusakan:~$ ls -l /srv/cdimage.ubuntu.com/www/full/ubuntu-snappy/15.04/edge/*
[10:40] <ogra_> -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] <ogra_> i dont think we had teh single partition layout on Jul 7th
[10:41] <pjoe> weird ... pretty sure that was where I found it
[10:42] <pjoe> ok booting now without the ssd ... looks more promising :)
[10:42] <ogra_> phew
[10:42] <pjoe> it even got ip addr :D
[10:43] <pjoe> and ssh works .. so far so good :)
[10:44] <pjoe> but there is no snappy .. only snap command
[10:44] <ogra_> ok, then the initrd isnt faulty ... phew
[10:44] <pjoe> that 15.04 edge I tried before had both ... guess it might have been mid transition :D
[10:45] <ogra_> heh, yeah, it was mid transition for the last 4 months or so :)
[10:46] <pjoe> but still no lxd snap :S ... will need to dig into how to get that done for 16.04
[10:46] <ogra_> yeah, now that the setup is final all the snaps need to be adjusted for it
[10:46] <pjoe> huh .. but nic interface name is back to eth0 ... before was en1sp0
[10:46] <pjoe> oh well
[10:47] <ogra_> ah, thats actually good
[10:47]  * pjoe testing if the other interface then is eth1
[10:48] <pjoe> hmmm
[10:48] <pjoe> maybe needs a reboot
[10:49] <pjoe> ahhh can see on console other nic is en2sp0 ... always good to mix things up
[10:49] <popey> dholbach: dpm got qtox working!  😃
[10:50]  * pjoe really misses vim on snappy ... will have to manage with just vi
[10:50] <popey> dholbach: dpm we finally have a GUI example http://bazaar.launchpad.net/~snappers/snappy-playpen/trunk/files/head:/qtox/ :)
[10:51] <dpm> popey, nice, good work!
[10:52] <pjoe> btw. any tricks for optimizing boot time? .... coming from coreos it seems to boot quite a bit slower
[10:54] <pjoe> huh .. after reboot no network ifs came up
[10:54] <pjoe> think I saw in console eth0 had become en1sp0
[10:54] <popey> yeah, nics have new names in recent kernels
[10:55] <pjoe> well first time it booted it was eth0 and got an IP
[10:56] <pjoe> hmm
[10:57] <Marco___> 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:59] <pjoe> sounds like what I'm seeing
[11:02] <pjoe> heh had a typo ens1p0 instead of enp1s0 ... think things are coming up now
[11:02] <ogra_> pjoe, echo "set nocompatible" >.vimrc
[11:02] <ogra_> ;)
[11:02] <ogra_> that gives you normal vim behaviour in vi
[11:03] <pjoe> ahh so it is the full vim binary ... sweet
[11:03] <ogra_> its stripped down ... but at least it behaves like normal vim
[11:03] <ogra_> (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] <dpm> 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] <pjoe> I can see both nics now :D ... as enp1/2s0
[11:06]  * ogra_ curses ... why is LP timing out for me
[11:07] <pjoe> 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] <pjoe> heh doing 'mount' show a pretty long list
[11:10] <ogra_> yeah, thats the "bind mount farm" ... that gives you some writable files
[11:11] <pjoe> btw. how does path work? ... does all snaps get inserted in path or do they put things in liek /usr/bin
[11:13] <pjoe> 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 <IP_ADDRESS>:53: cannot unmarshal DNS message)
[11:13] <pjoe> never seen that kind of thing before
[11:17] <pjoe> is snap implemented in go? ... it sounds a bit like this: https://github.com/golang/go/issues/11070
[11:18] <pjoe> I'm guessing the router has some kind of dns proxy doing some funny biz
[11:18] <ogra_> pjoe, yes
[11:18] <pjoe> kool
[11:19]  * pjoe has been very fond of go so far
[11:19] <ogra_> 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] <ogra_> mvo, no pi3 image btw ?
[11:23] <ogra_> i also dont see pi3 in snap find :/
[11:23] <pjoe> doing 'snap install nmap' when using openwrt router works just fine ... again must be the other router doing funny dns proxy stuff
[11:24] <ogra_> yeah
[11:24] <ogra_> 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] <pjoe> no worries ... stil just trying to understand what works and what doesn't ... and how things work
[11:26] <pjoe> e.g. how do snaps get their binaries into path ... can see from nmap that it ends up in /snap/bin
[11:26] <pjoe> but it isn't bind mounted there .. is it just linked?
[11:28] <zyga> pjoe: those executables are wrappers generated by snappy
[11:28] <zyga> pjoe: they are not the real executable
[11:28] <pjoe> ahh, I see
[11:28] <hdtvee> 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] <ogra_> hdtvee, where did you read that (not true)
[11:29] <hdtvee> hold on
[11:29] <zyga> 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] <zyga> hdtvee: 16.04 is not snap-based though
[11:29] <ogra_> hdtvee, deb will stay the default, but snaps are supported by default as well
[11:30] <ogra_> the system is (and will stay) deb based
[11:30] <oparoz_> 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] <ogra_> by 16.10 there might be snappy based desktop images too ... but they wont replace the existing desktop
[11:30] <hdtvee> https://www.maketecheasier.com/ubuntu-snappy-what-you-need-to-know/
[11:31] <ogra_> 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] <zyga> oparoz_: no
[11:32] <zyga> oparoz_: you can do that when your service starts
[11:32] <ogra_> hdtvee, thats nonsense ... the existing desktop installs wont go away
[11:32] <zyga> oparoz_: but you cannot run any scripts at install time
[11:32] <oparoz_> Thanks zyga. The problem is that scripts are started at random, so each and every daemon needs to include the setup script
[11:32] <ogra_> 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] <zyga> ogra_: that article talks about frameworks :-(
[11:33] <ogra_> too many people use it and depend on it
[11:33] <zyga> oparoz_: you should patch your daemon to use the snappy dirs
[11:33] <oparoz_> zyga, they do already
[11:33] <zyga> 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] <ogra_> zyga, yeah, some research might have helped :)
[11:33] <oparoz_> zyga, but we have to re-create everything on the writable partition in order to organise things
[11:33] <zyga> ogra_: internet journalism ;)
[11:33] <ogra_> yep
[11:33] <zyga> oparoz_: ?
[11:34] <ogra_> as long as it pays off :P
[11:34] <oparoz_> zyga, create var/log, var/tmp var/run
[11:34] <oparoz_> zyga, create folders for apps to put their files in
[11:34] <oparoz_> zyga, typically something you only do once
[11:35] <zyga> 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] <zyga> oparoz_: those directories *are* set up for you by snappy
[11:35] <oparoz_> zyga, yes, but those folders would be $SNAP_DATA/var/tmp, etc.
[11:36] <oparoz_> zyga, so we know where all logs files, sockets, etc. are
[11:36] <zyga> 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] <zyga> oparoz_: if you reorganize the code around snappy concepts it should be easier
[11:36]  * zyga -> lunch
[11:37] <ogra_> oparoz_, just add a startup wrapper that creates them if they dont exist
[11:37] <ogra_> underneath your snap dir
[11:37] <ogra_> and make sure all bits you need are in that snap and know that they should write there
[11:37] <ogra_> thats the proper way to do it in snappy
[11:38] <oparoz_> 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] <oparoz_> I don't like the idea of polluting $SNAP_DATA with log files, sockets, pids, app folders, etc.
[11:39] <ogra_> oparoz_, just check for SNAP_VERSION ... and comparie it to a stamp file
[11:39] <ogra_> then you can call it only on upgrade
[11:39] <oparoz_> ogra_, good idea :)
[11:40] <ogra_> though dont forget that people can roll back :)
[11:40] <ogra_> your check needs to cover that
[11:40] <oparoz_> true
[11:41] <oparoz_> ogra_, but with snap version, the script will be run every time a service is started when the snap is first installed
[11:41] <MichaelTunnell> hdtvee: I am making a video that explains Snappy, that might be of interest to you :)
[11:41] <oparoz_> 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] <oparoz_> *has
[11:42] <ogra_> oparoz_, well, it can be a two liner ... wont really be noticeable
[11:42] <oparoz_> ogra_, Indeed
[11:42] <hdtvee> MichaelTunnell, alright link it when it's ready
[11:52]  * pjoe got persistent network bridge working :)
[11:53] <pjoe> also looks like it would be possible to have custom kernel modules in a oem-gadget-snap
[11:53] <pjoe> at least canonical-pc-linux looks to have kernel moduls :)
[11:53] <ogra_> not really, you want them in a custom kernel snap instead
[11:54] <pjoe> ahh you can do that
[11:54] <ogra_> gadget (formerly oem) = bootloader and specifications
[11:54] <pjoe> things slowly starting to fall into place for me
[11:54] <ogra_> kernel = all the other HW bits
[11:54] <ogra_> note that both are in the process being re-defined though
[11:55] <ogra_> (but i guess the basics above wont change)
[11:55] <pjoe> 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] <ogra_> if you would ship a graphics driver it would be in the kernel snap ... together with the libs it needs
[11:55] <kyrofa> Good morning
[11:56] <pjoe> I 'just' need to patch a whatchdog drive module to support specific chipset
[11:56] <pjoe> driver
[11:56] <mvo> ogra_: proxy is a tiny bit tricky, needs a systemd environment setup, I can post details if someone needs them
[11:57] <ogra_> mvo, pjoe might
[11:57] <mvo> ogra_: pi3 - how do we make those? whats the gadget/kernel? happy to build some
[11:57] <pjoe> so canonical-pc-linux is the default kernel snap
[11:57] <ogra_> 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] <ogra_> )
[11:57] <ogra_> pjoe, right
[11:57] <mvo> 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] <mvo> ogra_: aha, ok
[11:58] <ogra_> i wanted a generic pi image ... but neither ppisati nor I got serial to worjk on the pi2 with the pi3 uboot
[11:58] <jamiebennett> mvo, ogra_, I'd like to move out the community builds to their own space, just to improve the clarity
[11:59] <ogra_> that means we need two separate gadgets ... beyond that the image is identical
[11:59] <zyga> ogra_: didn't pi3 change serial lines around so that it can talk to bluetooth?
[11:59] <zyga> ogra_: debug serial moved to then next one
[11:59] <ogra_> jamiebennett, the querstion is weather pi3 should be a community build :)
[11:59] <jamiebennett> ogra_, something to discuss at the sprint ;)
[11:59] <ogra_> zyga, right ... and sadly it does that inside uboot
[11:59] <zyga> ogra_: ahhh
[12:00] <ogra_> 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] <ogra_> (and rather drop pi2 after a while)
[12:01] <jamiebennett> ogra_, agree (although keep pi2) but whether is it officially blessed or part of the community is up for discussion
[12:01] <jamiebennett> I suspect it is more the former though
[12:01] <ogra_> 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] <ogra_> you want to read about snapcraft
[12:03] <ogra_> it also has examples
[12:04] <pjoe> looking here: https://developer.ubuntu.com/en/snappy/build-apps/get-started/
[12:04] <ogra_> (note that you need a xenial systeom or at least a xenial chroot with snapcraft 2.x)
[12:04] <pjoe> heh is planning to update my laptop tomorrow
[12:04] <pjoe> but guessing maybe docker 16.04 could do for today
[12:04] <pjoe> or even lxd 16.04 :D
[12:08] <ogra_> yeah
[12:13] <popey> 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] <dpm> 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] <dpm> popey, http://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/files/head:/setup/gui/
[12:17] <dpm> 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] <popey> magic, thanks dpm
[12:21] <dpm> np
[12:28] <sergiusens> 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] <dpm> sergiusens, it's fine, for now it helps me to know there is no other way.
[12:31] <dpm> 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] <sergiusens> kyrofa elopio hey, today its all hands on deck on vila's PR :-)
[12:35] <kyrofa> sergiusens, you got it
[12:35]  * vila runs twice as fast
[12:36] <vila> sergiusens: happy to discuss anything really, things are still moving server-side but I catch up quickly
[12:37] <vila> sergiusens, kyrofa, elopio: mainly because store_tests can be run against staging so I can validate before prod is available
[12:37] <popey> dpm: where does your package end up putting the .desktop file? I see nothing in /usr/share/applications
[12:38] <ogra_> yay, my tablet arrived
[12:41] <sergiusens> dpm yes, I mostly killed the qml plugin because it made to many assumptions that were not JUST about qml
[12:42] <sergiusens> dpm I would be happy to accept something that works for a common base
[12:42] <zyga> popey: /var/lib/snapd/desktop
[12:42] <zyga> popey: snappy rewrites desktop files on install
[12:42] <sergiusens> vila when you say things are moving, are you saying that the stuff landed in this PR might break us in the future?
[12:43] <sergiusens> I am not super keen on emergency PRs
[12:43] <sergiusens> vila also, haven't looked at the PR in detail, but can we check if we own the name before uploading a huge snap?
[12:43] <vila> sergiusens: I can predict that ;-) What I meant is that I'm still waiting for some bits server side to finish macaroon'ed upload and implement publish
[12:43] <popey> zyga: my unity7 dash doesn't see the desktop file
[12:43] <popey> zyga: it's in that location, but i can't start my app from the dash
[12:43] <dpm> popey, in the final snap, it puts it under meta/gui.
[12:44] <vila> *I /can't/ predict what will break
[12:44] <dpm> sergiusens, ok, cool. I'll submit it and we can discuss it in the review
[12:44] <popey> dpm: but once installed, do you get an icon for clock app in your dash?
[12:44] <popey> because I don't
[12:44] <dpm> popey, yes, I do
[12:44] <popey> hm
[12:44] <davmor2> popey: I don't
[12:44] <dpm> tested both clock and calculator yesterday
[12:44] <popey> you sure you're seeing the real desktop file for your snap?
[12:45] <vila> sergiusens: well, I'm not keen at all with emergency PRs myself...
[12:45] <dpm> popey, I'm quite certain I am, as in my tests first it was missing the icon, then I fixed it and I could see the icon in the dash and launcher
[12:45] <popey> hm
[12:45] <davmor2> popey: but then I still get davmor2@davmor2-XPS-13-9343:~⟫ ubuntu-clock-app.clock
[12:45] <davmor2> can not find a snappy os
[12:45] <popey> davmor2: snap install ubuntu-core
[12:46] <vila> sergiusens: I'm trying to provide macaroon support for snapcraft as soon as it's available in the store. I understand snapcraft will need it sonner rather than later but I'm all for validating as much as we can
[12:46] <dpm> popey, but... I haven't upgraded my system since yesterday.
[12:46] <dpm> davmor2, hm.... I was told ubuntu-core installs automatically for you the first time you install a snap
[12:46] <popey> it does now
[12:46] <popey> it might not have done in the past
[12:46] <dpm> ok, phew
[12:46] <dpm> yeah, it's quite recent afaik
[12:46] <popey> i tested that by nuking my entire snap install and installing clock
[12:47] <popey> ubuntu-core installed first, so that certainly works
[12:47] <xtihc> 我敢说哪里都有说中文的
[12:47] <popey> just confused by this desktop file missing
[12:47] <popey> !cn
[12:48] <davmor2> davmor2@davmor2-XPS-13-9343:~⟫ ubuntu-clock-app.clock
[12:48] <davmor2> QXcbConnection: Could not connect to display :0
[12:48] <davmor2> Aborted (core dumped)
[12:48] <dpm> davmor2, are your snaps installed under /snap or /snaps?
[12:48] <xtihc> ..
[12:48] <popey> davmor2: i think you need to nuke and pave
[12:49] <davmor2> dpm, popey: they are both under /snap/
[12:49] <dpm> davmor2, ok, at least that's the right location
[12:50] <davmor2> popey: how did you nuke just rm -rf /snap/ or run a command?
[12:50] <dpm> davmor2, you might need to wipe your /snap directory and mounts, we've all gone through this in the last couple of days, welcome to the club :)
[12:50] <popey> davmor2: one mo, let me pastebin
[12:50] <davmor2> ta
[12:52] <popey> http://paste.ubuntu.com/15947367/ that kinda thing
[12:52] <popey> dpm: what version of snapd you on?
[12:53] <dpm> popey, 2.0.1, I've not updated yet this morning to 2.0.2
[12:53] <popey> I'm on 2.0.2
[12:53] <popey> be interested to know if the .desktop thing broke from 2.0.1 to 2.0.2
[12:53] <dpm> popey, dholbach might be able to help with testing on 2.0.2
[12:54] <popey> ok
[12:54] <popey> :)
[12:56] <sergiusens> vila kyrofa seems the PR needs some work still; can we implement `register-name` independently or take guidance from dholbach's summary to add a link? ref: https://bugs.launchpad.net/snapcraft/+bug/1572399
[12:57] <davmor2> popey, dpm: Now I seem to be struck by the fact that ubuntu-clock-app isn't listed at all
[12:57] <popey> davmor2: snap find | grep clock
[12:57] <popey> davmor2: maybe snap login ?
[12:57] <dpm> davmor2, or snap find ubuntu, either should work
[12:57] <davmor2> http://paste.ubuntu.com/15947484/
[12:58] <popey> davmor2: i386 or amd64?
[12:58] <davmor2> popey: amd64
[12:58] <kyrofa> sergiusens, think it's worth investing the effort if it's all switching to macaroons soon?
[12:58] <popey> davmor2: version of snapd?
[12:58] <kyrofa> sergiusens, easy to add the link though
[12:58] <popey> $ snap find ubuntu-clock-app
[12:58] <popey> error: no snaps found for "ubuntu-clock-app"
[12:58] <popey> :(
[12:58] <popey> the whole "snap find" thing is broken
[12:59] <davmor2> ii  snapd                                                2.0.2                                               amd64        Tool to interact with Ubuntu Core Snappy.
[12:59] <popey> hmm, I can't see any of dpm's apps either
[12:59] <dpm> sudo snap install ubuntu-clock-app should do too
[12:59] <dpm> tyhicks, jdstrand, is there an interface to grant access to dbus? I'm having an issue with the weather app snap whereby it tries to access the network and it's blocked -> http://pastebin.ubuntu.com/15947469
[12:59] <sergiusens> kyrofa right, I just don't want to do anything in a hurry that would break snapcraft completely; you can at least upload today if the name is registered
[12:59] <zyga> dpm: each interface can grant access to dbus
[12:59] <davmor2> dpm: look at the output in my paste you will see it failed
[12:59] <popey> davmor2: confirmed, snap find shows same here as you see
[12:59] <dpm> davmor2, popey, argh, I know why. Since this morning apps need to be registered for the 16 release. I've not done that yet for clock and calc :/
[12:59] <kyrofa> sergiusens, agreed 100%
[12:59] <popey> ahhhhh
[13:00] <vila> sergiusens: "can we check if we own the name before uploading a huge snap" not in the MP, known issue but no solution either in the short term :-/
[13:00] <zyga> dpm: the upcoming network-manager interface should fix part of that bug
[13:00] <popey> dpm: tickbox in the store?
[13:00] <kyrofa> sergiusens, I assume that error is store-side. I wonder if they could add a link there?
[13:00] <sergiusens> dpm you shouldn't have network-bind there now, should you?
[13:00] <zyga> popey: you have to upload again
[13:00] <davmor2> jibel: ^ there is the cause of your disappearing apps
[13:00] <popey> ah, okay
[13:00] <popey> thanks zyga
[13:00] <dpm> popey, no, I need to register the name as well, will do all in a minute
[13:00]  * zyga stops working and goes outside
[13:00] <popey> ok
[13:00] <popey> sorry dpm :)
[13:00] <sergiusens> nessita is it possible? To add a link to the error message from the store here https://bugs.launchpad.net/snapcraft/+bug/1572399
[13:01] <dpm> sergiusens, probably not, I was just testing.
[13:01] <zyga> popey, dpm: I will talk about interfaces more later today, by the end of next week interfaces will have very solid and in-depth documentation
[13:01] <dpm> sergiusens, zyga, does that mean that until there is the 'network-manager' interface I can't get the weather snap working?
[13:01] <dpm> popey, np, good catch
[13:02] <sergiusens> dpm I think the network manager interface ALLOWS you TO BE network manager, not talk to it
[13:02] <zyga> sergiusens: no
[13:02] <sergiusens> I THINK so at least
[13:02] <popey> zyga: i appreciate your help
[13:02] <zyga> sergiusens: it allows both
[13:02] <vila> sergiusens: oauth will no longer be valid for snappy I tried to preserve it but this is becoming increasingly hard and slows me down
[13:02] <nessita> sergiusens, you would like the error returned in the API for upload contains the link?
[13:02] <zyga> sergiusens: depending on plug vs slot side
[13:02] <sergiusens> zyga isn't that a bit too broad?
[13:02]  * zyga really stops working
[13:02] <sergiusens> zyga a k
[13:02] <popey> wise
[13:02] <zyga> sergiusens: no, you think in terms of old caps :)
[13:02] <josepht> zyga: when you get back inside and have a chance; devtools is still not working for me.  https://pastebin.canonical.com/154809/ I'm at commit 9e6802e2d338d432cc265bc469cbf39e6dec3766
[13:02] <sergiusens> zyga yes I do ;)
[13:02] <zyga> sergiusens: interface has two sides and those do different things :)
[13:03] <zyga> josepht: pull
[13:03] <zyga> josepht: I fixed that earlier today
[13:03] <vila> sergiusens: fwiw, integration_tests.test_upload.UploadTestCase.test_upload_with_login started failing last night
[13:03] <zyga> hmm
[13:03] <zyga> 9e6802e2d338d432cc265bc469cbf39e6dec3766
[13:03] <zyga> I build all the images with this revision
[13:04] <sergiusens> vila hmm, I released 2.8.3 last night; master should still work
[13:04]  * sergiusens tests
[13:04] <zyga> s/build/built/
[13:04] <vila> sergiusens: I did use snapcraft register-name with macaroons to register it for<EMAIL_ADDRESS>so it should pass again, but other integration tests (on master) should still fail
[13:04] <zyga> anyway, really off
[13:04] <vila> sergiusens: yes, it does and should continue to work as long as people register and publish from the web site
[13:05] <kyrofa> nessita, yeah. Maybe something like "You must register X name for 16 before uploading, please register it and try again (see https://myapps.developer.ubuntu.com/dev/click-apps/register-name/ for more information)." ?
[13:05] <zyga> josepht: that might be a bug in the snap itself, maybe mvo will know
[13:05] <vila> nessita: will OAuth uploads keep working for the 16 series ?
[13:05] <zyga> kyrofa: have snapcraft send X-Did-Register-Name and have the server drop the connection early if that's not the case
[13:06] <nessita> kyrofa, ok, but then notice that name-registration can happen via API, so from my POV is a bit uneven that upload can be done via API, but you then redirect the user to a browser for name registration
[13:06] <sergiusens> nessita yes, something like what kyrofa says :-)
[13:06] <nessita> kyrofa, sergiusens I think snapcraft should offer name registration via API to the developer
[13:06] <sergiusens> nessita so vila is adding support for `snapcraft register-name` now and we will ultimately switch to that, but I don't think it will make it before release
[13:06] <kyrofa> nessita, indeed, we agree. But we're all oauth right now
[13:07] <nessita> kyrofa, sergiusens that upload endpoint does not handle snap-ids, so I'm not sure you should be using it
[13:08] <nessita> vila, the old upload endpoint was conceived to be used with clicks and old snaps, not new snaps
[13:08] <vila> nessita: yeah, I'm worried about fallouts indeed
[13:08] <nessita> if it works is by chance, and from the store side we can not guarantee backwards compatibility for new snaps
[13:10] <nessita> vila, sergiusens, kyrofa I keep having this feeling that snapcraft should store internally a mapping of names -> snap-ids so we can:
[13:10] <sergiusens> nessita we inherited the original upload implementation from pindonga; I have no clue about the endpoints
[13:10] <vila> sergiusens, kyrofa: best guestimate for macaroon uploads in today or tomorrow. I have uncommitted code to test the new endpoint as soon as it's available on staging... That's the best I can do ;)
[13:10] <nessita> 1- know if a name was registered or not
[13:10] <nessita> 2- have the snap-id to push to API that requires it
[13:10] <vila> nessita: renames ?
[13:11] <nessita> vila, not exactly sure what you are asking
[13:11] <vila> nessita: we agreed on using name, series from the client, sca doing the translation to snap_id (in https://docs.google.com/document/d/1pOAazzykOjBzkFHc9OyV_ORz8CByvWTeZlKgwEJ9YX4/edit)
[13:11] <vila> nessita: a local mapping will break on renames
[13:11] <sergiusens> nessita we can't do any drastic changes today, so we will need to coordinate this post release
[13:12] <sergiusens> nessita please don't break us after release, you don't endure the pain of an SRU as we do
[13:12] <nessita> vila, we can talk about this in u1-internal, I see your point
[13:12] <popey> upgrading to snapd 2.0.2 now means I can't lanuch my app at all...
[13:12] <vila> nessita: ack
[13:13] <popey> $ mame
[13:13] <popey> /bin/sh: 0: Can't open /snap/mame/100003/command-mame.wrapper
[13:13] <popey> seems launching broke
[13:13] <nessita> sergiusens, I understand the need of coordination; I also think OAuth should not exist anywhere in snappy or snapcraft
[13:13] <nessita> sergiusens, anyways, will not break anything today, will raise this issues with the proper people
[13:15] <sborovkov> Hi. I am on RPI with image yesterday's latest images used. After I installed snappy-debug snap and rebooted it does not mount. I can't removeit as well - error: can't remove "snappy-debug": cannot find mounted snap "snappy-debug" at revision 13. Any ideas what's going on?
[13:17] <Marco___> apparmor rights for snap package: I am calling "systemctl xx" from inside my application and always get apparmor denied. does anyone know how to give my snap application sufficient rights for that call?
[13:17] <zyga> popey: uninstall all versions, reinstall, this is bug https://github.com/ubuntu-core/snappy/pull/1049
[13:18] <zyga> popey: (of mame)
[13:22] <ogra_> uuuh !
[13:22] <ogra_> nessita, why do i find snaps on my tablet since today ?
[13:22]  * ogra_ just got offered his upnp-server snap when searching for the filemanager
[13:23] <popey> zyga: i just filed bug 1572568 - is that bug fixed with that?
[13:24] <popey> zyga: can't remove... - Remove snap "mame" from the system (remove /snap/mame/100002/bin/launcher: read-only file system)
[13:25] <zyga> popey: that's a different bug!
[13:25] <zyga> popey: please report it, I also saw it once but I was unable to reproduce it
[13:25] <zyga> mvo, pedronis: ^^^
[13:25] <zyga> popey: I think there are two bugs at play, the one I referneced was just about incorrect security after snap upgrade
[13:26] <mvo> popey: is that running? mame? I suspect the removal one is https://bugs.launchpad.net/snappy/+bug/1571721
[13:27] <mvo> zyga: https://bugs.launchpad.net/snappy/+bug/1572568 is  dupe,  let me find the other one
[13:28] <mvo> popey: ups, --^ for you
[13:30] <sergiusens> nessita heh, this was the reason I wanted pindonga to originally provide his own package with store bindings; so then you could change this all you want without so much coordination; something to consider again after release
[13:30] <popey> mvo: no, the app isn't running
[13:30] <popey> mvo: it happens when i try and remove side loaded things I installed on 2.0.1
[13:31] <mvo> popey: anything that still is open and keeps an fd on the dir? I suspect it failed to unmount the dir because the mount point is busy
[13:31] <mvo> popey: don't get me wrong, definitely a bug, just trying to understand it :)
[13:31] <ChrisTownsend> ogra_: Hey, tedg said you might be able to help me.  I have a squashfs based snap and need to debug an app inside it.  Do you have a trick on how I can modify files inside the snap and still preserve the same environment that is normally used?
[13:32] <kyrofa> ChrisTownsend, overlayfs?
[13:32] <ogra_> ChrisTownsend, no, and with the classic shell gone currently i suspect the workaround that jdstrand had wont work either (he had a way to add an overlayfs)
[13:32] <kyrofa> ogra_, I use that without the classic shell
[13:32] <popey> mvo: D'oh! I had a shell open in those directories! But now I don't, and they still won't remove :(
[13:33] <ChrisTownsend> kyrofa: Care to elaborate?
[13:33] <mvo> popey: same error?
[13:33] <popey> yes
[13:33] <mvo> popey: hm, I'm in a meeting right now, but something like lsof |grep /snap/mame would be nice
[13:33] <ChrisTownsend> ogra_: Hmm, not being able to debug "inline" is not very handy:-(
[13:34] <kyrofa> ChrisTownsend, https://paste.ubuntu.com/15496227/
[13:34] <popey> mvo: http://paste.ubuntu.com/15948319/ is sudo lsof | grep mame | pastebinit
[13:34] <ChrisTownsend> kyrofa: Cool, thanks.  I'll give it a shot.
[13:34] <ogra_> ChrisTownsend, well, it will all get better within the next months ... (some kind of classic mode will come back etc)
[13:34] <ChrisTownsend> ogra_: Ok, good to know it's being thought about and worked on.
[13:35] <kyrofa> jdstrand, you should consider shipping that script in snappy-debug
[13:35] <kyrofa> (it would have to be unconfined I suppose)
[13:36] <sborovkov> ogra_: Hello. Any ideas what's going on? sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi2 -o test.img -> This gives me error expected a gadget snaps: snap not found
[13:36] <ogra_> ChrisTownsend, we're pretty much back at zero currently ... basics are done, features not
[13:37] <ChrisTownsend> ogra_: Wow, ok.
[13:37] <ogra_> sborovkov, do you use the very latest ubuntu-device-flash from http://people.canonical.com/~mvo/all-snaps/ ?
[13:37] <zyga> sborovkov: use 16 instead of rolling
[13:37] <zyga> sborovkov: or use my script github.com/zyga/devtools
[13:38] <josepht> zyga: I'm getting that with devtools now as well
[13:38] <ogra_> oh, another change :P
[13:39] <zyga> josepht: then more broken :)
[13:39] <zyga> josepht: does your copy say "16" or "rolling"?
[13:39] <josepht> zyga: 16
[13:40] <ChrisTownsend> kyrofa: Seems that works on my snap.  One other quick question.  To get it back in the ro state, just unmount the overlayfs, right?
[13:40] <zyga> josepht: then more broken stuff, I'm sorry
[13:40] <kyrofa> ChrisTownsend, you got it
[13:40] <ChrisTownsend> kyrofa: Cool, thanks again!
[13:40] <kyrofa> ChrisTownsend, obviously that'll undo your changes
[13:40] <ChrisTownsend> kyrofa: Right
[13:40] <sborovkov> zyga, ogra_: works with 16 instead of rolling (I am using latest ubuntu-device-flash)
[13:40] <kyrofa> ChrisTownsend, sure thing :)
[13:41] <josepht> zyga: no worries
[13:41] <ogra_> sborovkov, good
[13:41] <kyrofa> ChrisTownsend, note that you can use more permanent directories if you want the ability to remount an overlay you were working on
[13:42] <sborovkov> Does new permission system with plugs/interfaces work now? can I use it to give my snap to /dev/vchiq now?
[13:42]  * zyga wonders if udf has is out-of-date again?
[13:42] <josepht> zyga: seems to be only for pc, pi2 works for me
[13:42] <zyga> sborovkov: yes, yes but you need to patch snappy
[13:42] <ChrisTownsend> kyrofa: Ok, makes sense, but I think I have enough for now.
[13:43] <zyga> sborovkov: I'm writing articles about snappy interfaces, I will get to that point in a few more days
[13:43] <zyga> sborovkov: the first one was posted to planet ubuntu last night
[13:43] <zyga> sborovkov: I'm writing the second one right now
[13:43] <zyga> sborovkov: my articles will allow anyone to understand interfaces and create a new interface for a particular purpose
[13:44] <sborovkov> Ok, got it. Thanks.
[13:44] <dholbach> popey, wow... I overlooked the message earlier - that's awesome, let me try it
[13:45] <pmp> I'm still learning: what's the difference between snappy 2.0 and Ubuntu Core 16 / 16-series?
[13:45] <popey> dholbach: don't worry, it broke in the meantime :)
[13:46] <zyga> pmp: ubuntu core 16 contains snappy 2.0
[13:47] <dholbach> popey, right... it's been what... 3 hours? :)
[13:47] <ogra_> you guys are to slow
[13:47] <popey> heh
[13:48] <ogra_> dholbach, FYI ... we had to remove the images that slangasek released on cdimage on your request (they were completely broken)
[13:48] <ogra_> new images will show up there soon though ... (in some "alpha" subdir or so i suppose)
[13:50] <dholbach> ogra_, it wasn't so much MY request - it was more like we wanted to point people to images which were not hosted in somebody's home directory
[13:50] <ogra_> yeah
[13:50] <dholbach> and that was requested by sabdfl and others in the mailing list thread too
[13:50] <ogra_> sure, but we cant release un-upgradeable images that you cant install anything on
[13:51] <ppisati> FWIW, i still get the "/tmpmnt_writable/..." error when trying a custom kernel
[13:51] <ppisati> kernel just rebuilt
[13:51] <ppisati> while i used latest mvo's amd64 image in people...
[13:51] <ogra_> does the initrd somehow get cached locally or some such ?
[13:51] <ppisati> ogra_: cached?
[13:52] <ogra_> by the snapcraft kernel plugin
[13:52] <ppisati> ogra_: i can do a
[13:52] <ppisati> git clean -fdx
[13:52] <ogra_> or do you not use that for your custom klernel
[13:52] <ppisati> in the snapcraft dir
[13:52] <ppisati> and rebuild
[13:52] <ogra_> yeah, seems like you are stuck on an old initrd to me
[13:53] <ogra_> or that you need some controller module you are missing
[13:54] <dpm> davmor2, popey, ubuntu-calculator-app and ubuntu-clock-app are again available. If you installed them before yesterday, you might need to remove and reinstall –at least that's what I did
[13:57] <popey> ok
[13:57] <popey> hah, 120MB clock :)
[13:58] <jibel> attente, in which version of gnome-software is the re-prompt issue fixed?
[13:58] <popey> this better be a pretty damn amazing clock!
[13:58] <popey> dpm: that worked
[13:58] <jibel> attente, i get it again and it prompted me at least 3 times when I was installing a snap
[13:58] <jibel> attente, do I need to clear everything again?
[13:58] <ogra_> popey, be careful what you wish for .... it might unfold big ben in your office if you start it ...
[13:59] <popey> :)
[13:59] <attente> jibel: it's in the archive version, not the private ppa
[13:59] <ogra_> oops ...
[13:59] <attente> jibel: i'm updating the private ppa right now though
[13:59]  * ogra_ notes he forgot the MIR for initrmafs-tools-ubuntu-core
[13:59] <ogra_> wishful thinking :P
[13:59] <attente> jibel: it should be fixed since it takes the fixes we've made to the archive version
[14:02] <jibel> attente, okay, I'll replace the version by the archive version
[14:02] <attente> jibel: actually... it hasn't been released yet :(
[14:02] <jibel> attente, I don't need anything anymore from the ppa right?
[14:02] <attente> jibel: it's the version 3.20.1+git20160420.1.ca63436.ubuntu-xenial-0ubuntu1
[14:03] <attente> jibel: the public ppa has that version, the private ppa has the snappy plugin enabled
[14:03] <attente> jibel: you still need the ppa until that gets into xenial
[14:04] <attente> jibel: and if you want the snappy plugin, you need the private ppa
[14:04] <seb128> attente, we have a version with the current fixes from distro + snap plugin enabled?
[14:05] <seb128> or asked differently is the private ppa keeping up or behind?
[14:05] <attente> seb128: i just did an update to the private ppa
[14:06] <attente> seb128: all it is is the version Laney uploaded with the snappy plugin enabled
[14:06] <seb128> attente, good
[14:14] <joe_____> hi, i'm trying out snappy on a device i have. i'm using docker for running a few services, and now i want to set up monitoring of the device host. what are good options? is it still the traditional tools like munin, nagios that are the way to go?
[14:14] <jdstrand> dpm (fyi tyhicks): re interface to access dbus> that question is very open ended. I think you mean, is there an interface to grant the weather app access to network-manager. the answer is 'no', not at this time. however, a network-manager interface is in the works. It won't autoconnect because the network-manager interface is dangerous
[14:15] <dpm> thanks jdstrand
[14:15] <jdstrand> niemeyer_: note, this is an interesting thing we'll want to discuss at some point. on Touch we were in a position to say 'sorry, you can never talk to network-manager' but with interfacecs, users may be faced with questions like 'should this app be able to talk to network-manager' at which point, they'll be like "I don't know, I guess"
[14:15] <jdstrand> niemeyer_: and therefore users are being put in a position to make policy decisions that they should not
[14:19] <dholbach> davidcalle, dpm, popey: I'm pushing another non-working example to snappy-playpen :)
[14:19] <popey> heh
[14:19] <dpm> dholbach, "well done"! :-)
[14:20] <dholbach> I'll use it to track another interesting bug I'm running in :)
[14:21] <dpm> dholbach, davmor2, are you able to launch clock from the dash?
[14:21] <dholbach> let me see
[14:23] <sergiusens> kyrofa ogra_ https://github.com/ubuntu-core/snapcraft/pull/476
[14:23] <dholbach> dpm, yep, WFM
[14:24] <dpm> ah, phew
[14:24] <dpm> thanks for confirming
[14:24] <dpm> seems some people are not seeing it from the dash
[14:24] <ogra_> sergiusens, looks sane
[14:24] <davmor2> dpm: I am now yes
[14:25] <dpm> thanks davmor2 for confirming
[14:25] <popey> wtf, why am I not
[14:25] <popey> ubuntu-clock-app  3.6+snap3             ubuntucoredev
[14:25] <dpm> popey, did you remove and reinstall?
[14:25] <popey> yes
[14:25] <popey> nuked entire snap setup
[14:25] <nessita> ogra_, we are investigating, we think we have the issue narrowed down, building a fix
[14:25] <dpm> popey, oh, so you nuked the whole setup again today?
[14:25] <popey> just now
[14:25] <popey> recently
[14:26] <ogra_> nessita, awesome
[14:26] <popey> so i have a pretty clean setup
[14:26] <dpm> popey, maybe snappy is rebelling against being destroyed so often
[14:26] <popey> s/snappy/skynet/
[14:26] <zyga> popey: we didn't announce that rename yet!
[14:27] <popey> hah
[14:29] <sergiusens> nessita is X-Ubuntu-Release 16 or 16-core?
[14:30] <sergiusens> 16 i alone it seems :-)
[14:32] <nessita> sergiusens, 16
[14:37] <jdstrand> popey: re fontconfig> something (it might be a library the app ships) is broken. it is trying to write to /var/cache/fontconfig. /var/cache/fontconfig is not in the ubuntu-core os snap, not mounted from the classic system and even if either were true, the non-root user would not have write access to it anyway (even if apparmor granted it)
[14:38] <jdstrand> popey: someone from the desktop team needs to take a look-- perhaps there is a variable that needs to be set
[14:38] <popey> okay
[14:39] <jdstrand> popey: note, the apparmor rules you and zyga discussed were about 'r'ead rules, not w'rite rules. the denial was for a 'w'rite rule
[14:39] <popey> yeah. I have no idea why it wants to write there
[14:40] <popey> it also needs to read a bunch of udev stuff for input device enumeration
[14:40] <zyga> jdstrand: hey, welcome back! :-)
[14:43] <jdstrand> kyrofa: we could ship that script in snappy-debug. note, snappy debug is totally broken right now due to like 10 different changes in the system
[14:43]  * jdstrand will be working on developer mode soonish
[14:43] <kyrofa> jdstrand, whoa, only 10? That's pretty good
[14:46] <jdstrand> zyga: hi! thanks :)
[14:46] <shuduo> mvo: i heard of new u-d-f appear then downloaded it. now it can't find gadget snap. may i know if gadget naming changed again?
[14:46] <sergiusens> nessita thanks
[14:47] <jdstrand> popey: re udev and device stuff, that is very much going to be a new interface. snappy will need to expose the devices and then have a way to grant them to the snap
[14:47] <jdstrand> kyrofa: hehe :)
[14:48] <jdstrand> zyga: were you able to locate the patch I sent for bluez?
[14:48] <jdstrand> zyga: I didn't send it, I put in in irc
[14:48] <shuduo> zyga's ubuntu-image does not work with latest u-d-f too
[14:48] <jdstrand> zyga: here it is: http://paste.ubuntu.com/15837884/
[14:53] <jdstrand> popey, dpm: re clock app and network manager-- same thing the question I answered a few minutes ago. really, these apps should be using connectivity-api from Touch instead of network-manager
[14:53] <sborovkov> Hello. getting this error when trying to install snappy-debug -> - Download snap "snappy-debug" from channel "stable" (snap not found)
[14:53] <sborovkov> What can I do to fix this?
[14:54] <jdstrand> sborovkov: is this on 16.04?
[14:54] <zyga> jdstrand: still on my TODO list
[14:54] <zyga> jdstrand: I'm off today
[14:54] <jdstrand> ie, 16.04 image or 15.04 image?
[14:54] <jdstrand> zyga: that's fine (enjoy your day off and go away!! :)
[14:54] <zyga> jdstrand: aaalmost ;)
[14:54] <jdstrand> zyga: I just wanted to make sure you had the info
[14:55] <dpm> jdstrand, hm, they do use the connectivity API
[14:55] <sborovkov> jdstrand: yes
[14:55] <dpm> as far as I understand it
[14:56] <joe_____> how would you monitor a device host that's running snappy? is it still traditional tools like munin, nagios etc. that are the way to go?
[14:56] <sborovkov> jdstrand: rpi.
[14:57] <dpm> jdstrand, ah wait. So you mean instead of using QNetWorkManagerInterface something else should be used? -> http://pastebin.ubuntu.com/15947469/
[14:58] <dpm> jdstrand, this, it seems? https://developer.ubuntu.com/api/apps/qml/sdk-15.04.1/Ubuntu.Connectivity.index/ I'm not familiar with it, so I don't know if it can do what the Weather app needs
[14:59] <dpm> jdstrand, it seems to be used only to check network status, not to get data over the network?
[14:59] <mvo> shuduo: you need to use the "16" series now instead of "rolling" - could that be the issue?
[15:01] <jdstrand> sborovkov: snappy-debug isn't in stable yet for 16.04 because it doesn't work yet
[15:01] <sborovkov> oh, alright. The command snap install snappy-debug worked like day before yesterday, so I was surprised when it did not
[15:02] <shuduo> mvo: yes, 16 series working now. does that mean rolling be dropped?
[15:03] <jdstrand> dpm: you'll want to talk to mzanetti I think. the point is, you can't give a subset of the nm api to answer the question 'am I online' cause the nm api isn't written with untrusted apps connecting to it in mind. therefore the phonedations team created the connectivity-api to answer that question for apps and it has a very clean, safe api
[15:03] <jdstrand> dpm: connectivity api isn't on 16.04 by default though afaik, that might be a seb128 question
[15:04] <mvo> shuduo: yes
[15:04] <mvo> shuduo: its dropped for now until we open a new rolling again
[15:04] <jdstrand> sborovkov: well, if you did install it, it wouldn't work properly anyway. this is something I will be looking at after release
[15:04] <seb128> jdstrand, dpm, no it's not, nothing on the iso uses it it seems
[15:04] <_morphis> zyga, jdstrand: you had time to look at our PRs for the bluez and network-manager interfaces?
[15:04] <mvo> ogra_: what is the status of bug #1563296 ? I see fix released but an open snappy task, anything we need to do in snappy land?
[15:05] <shuduo> mvo: interesting. good to know. let me update my training slides with this change. thanks.
[15:05] <ogra_> mvo, it is fix-released in livecd-rootfs already ... can be closed
[15:05] <jdstrand> _morphis: I responded to nm late monday and I saw zyga did yesterday (I think). I was off yesterday and still catching up. if there are things for me to respond to, I will today
[15:06] <_morphis> jdstrand: thanks!
[15:07] <sborovkov> jdstrand: right it did not... after I rebooted it did not even mount itself. And I could not remove it since it was giving me error that it's nto mounted
[15:10] <mvo> shuduo: cheers
[15:11] <mvo> ogra_: same question for bug #1562784 - I assume the snappy task can be closed as well here?
[15:12] <ogra_> mvo, yeah
[15:12] <mvo> ta
[15:14] <ogra_> mvo, can you take a look at mterry's questions in bug 1572544
[15:14] <ogra_> i assume we can drop /snaps
[15:14] <mvo> ogra_: yes we can
[15:15] <ogra_> obama !
[15:15] <mterry> :)
[15:18] <shuduo> mvo: seems canonical-pc gadget snap does not exist in  16 series and edge channel?
[15:19] <ogra_> mvo, can you make snappy-dev the default bug team for ubuntu-core-config, initramfs-tools-ubuntu-core and ubuntu-core-libs ? (i cant, needs a team admin)
[15:20] <ogra_> iirc the last one is ubuntu-core-meta though
[15:22] <jibel> dpm, I cannot install the calculator or the clock it tells me it's already installed
[15:22] <mvo> shuduo: hm, it should I have a look, there was a store issue some minutes ago that hide some snaps
[15:23] <jibel> dpm, probably because I had pre-2.0.2 installation
[15:23] <jibel> dpm, what do I do to install the new snaps?
[15:23] <shuduo> mvo: dragon snap and pi2 snap can be found. pc snap can't. pls check.
[15:26] <davmor2> jibel: http://paste.ubuntu.com/15947367/ is apparently how popey got my install working, but then I had to manually install ubuntu-core
[15:27] <jibel> davmor2, yeah that's what I did yesterday already
[15:28] <jibel> davmor2, it's pretty annoying and impracticable to do that after each upgrade of snapd
[15:30] <sborovkov> Hello. Do I understand correctly that old-security is not working anymore? is there some simple way I can use new syntax to get old 'unconfined' behavior?
[15:32] <zyga> sborovkov: no, just install your snap in development mode (snap install --devmode)
[15:32] <zyga> sborovkov: and work on a new interface (docs on that will be availalbe in the next few days)
[15:34] <sborovkov> zyga: alright. but as you said before - to allow snap acess /dev/vchiq snappy needs to be patched - how long till that's not needed?
[15:35] <zyga> sborovkov: till you patch it?
[15:35] <zyga> sborovkov: or someone else does
[15:36] <zyga> sborovkov: wait a few more days, I it will all be clear (er) when I describe how that works
[15:36] <kyrofa> dholbach, perhaps you know the answer to this: https://askubuntu.com/questions/759557/how-to-run-a-command-in-a-snap-package ?
[15:36] <zyga> sborovkov: btw, what is /dev/vchiq?
[15:36] <dholbach> kyrofa, dpm knows - he did it in ubuntu-clock-app
[15:37] <dholbach> dpm, ^ did you update lp:snappy-desktop-examples with the newest?
[15:38] <kyrofa> Thanks dholbach :)
[15:38] <sborovkov> zyga: rpi gpu interface
[15:38] <zyga> sborovkov: I plan to work on pi2 support in the next few weeks
[15:39] <zyga> sborovkov: I plan to get various perhiperials supported (gpio, spi, i2c, camera)
[15:39] <jamiebennett> Anyone had problems removing and reinstalling snaps today?
[15:39] <zyga> sborovkov: just stay in touch, you can help me out soon
[15:39] <zyga> kyrofa: I replied to that question
[15:40] <marco___> zyga: I am also very interessted in getting infos for the new sec. concept :-)
[15:40] <zyga> kyrofa: many people just upgrade and still have just /snaps/bin (note /snaps, not /snap) in their path
[15:40] <jamiebennett> http://pastebin.ubuntu.com/15951144/
[15:40] <zyga> marco___: great, follow my blog posts. I sent the first one yesterday. The next one will be published in around two hours, I'm just collecting feedback from proofreaders
[15:40] <sborovkov> zyga: Ok
[15:40] <kyrofa> jamiebennett, I seem to remember seeing a bug about needing to remove twice
[15:40] <kyrofa> jamiebennett, was the clock running when you tried to remove it, perhaps?
[15:41] <zyga> jamiebennett, kyrofa: each installs creates a new revision, you need to remove *each* revision
[15:41] <zyga> so you have to remove it till it's gone
[15:41] <kyrofa> Ah, or that
[15:41]  * jamiebennett tries to remove again
[15:41] <zyga> heh :)
[15:41] <kyrofa> zyga, thanks for answering that question :)
[15:43] <jamiebennett> If I try to install twice it wont do it
[15:43] <jamiebennett> How did I get two copies of the clock app?
[15:44] <zyga> jamiebennett: side loading creates new revisions
[15:44] <kyrofa> jamiebennett, perhaps you got an update after you initially installed?
[15:44] <jamiebennett> zyga, no sideloading
[15:44] <jibel> jamiebennett, I had the same issue and had to reset everything
[15:45] <jibel> jamiebennett, http://paste.ubuntu.com/15947367/
[15:45] <jibel> systemctl stop snapd instead of service
[15:45] <zyga> wait
[15:45] <jibel> zyga, no sideloading here either
[15:45] <zyga> jibel, jamiebennett: use this instead: https://github.com/zyga/devtools/blob/master/reset-state
[15:45] <zyga> this is correct-er
[15:45] <jamiebennett> :)
[15:46] <jamiebennett> Looking back through my console log it looks related to refresh so kyrofa may be correct
[15:46] <jamiebennett> damn autocomplete
[15:52] <tedg> sergiusens: Is snapcraft doing an ldd and pulling libraries into the snap?
[15:53] <tedg> Got a bunch of libraries in ./snap that I can't figure out how they got there.
[15:55] <kyrofa> tedg, yes
[15:55] <tedg> Okay, thanks kyrofa!
[15:56] <tedg> Is modern snapcraft if the vivid-overlay PPA for the phone? Or just xenial?
[15:56] <tedg> I guess not in, but built against.
[15:56] <jamiebennett> zyga, this is the sequence of steps: http://pastebin.ubuntu.com/15951538/
[15:56] <ogra_> tedg, only xenial
[15:57] <ogra_> no backports
[15:58] <slangasek> ogra_: thanks for the MIR work today.  I see there's still no MIR for ubuntu-fan, which is also on the seed?
[15:59] <ogra_> slangasek, i was kind of expecting the owner (kernel team) or the cloud teams to MIR it, given it is default in all cloud images
[16:00] <ogra_> we are only participants here ...
[16:00] <tedg> kyrofa: Is there any filtering on that list? I was surprised for instance that libGL.so got added when that should be in the kernel snap.
[16:00] <kyrofa> tedg, indeed, but the list is pulled from stable right now
[16:02] <kyrofa> tedg, specifically, anything included in the stable os snap is not automatically copied
[16:03] <kyrofa> tedg, but I think opengl in the os snap is new
[16:03] <kyrofa> tedg, probably not in stable
[16:03] <tedg> kyrofa: Well it's not the OS snap, but the kernel snap. It is an enablement thing really.
[16:03] <slangasek> ogra_: oh, checking
[16:03] <slangasek> ogra_: c-m fingered snappy, but I believe that may be wrong
[16:04] <ogra_> slangasek, if needed i can indeed take over ... but i kind of think fan needs to be solved in a broader scope
[16:04] <slangasek> ogra_: system-image is the only seed that contains ubuntu-fan
[16:05] <ogra_> oh ? i thought it was a requirement for all container cloud work
[16:05] <ogra_> hmpf ... k
[16:05] <slangasek> ogra_: regardless, the MIR process should be owned by whoever is introducing the dependency
[16:05] <ogra_> i'll file a MIR bug then ... (its a sabdfl request to have it )
[16:05] <kyrofa> tedg, ah, interesting. Yeah that may need to be updated
[16:06] <ogra_> i dont think we have even ever made any use of it
[16:06] <kyrofa> Things will settle once the desktop work flows back into ubuntu core
[16:08] <sergiusens> kyrofa tedg mvo told me not to filter out gl; it is safer to include it for now.
[16:08] <kyrofa> sergiusens, ah, good to know
[16:08] <kyrofa> And agreed, since not everything has it
[16:08] <ogra_> slangasek, bug 1572650
[16:08] <tedg> Ah, interesting. Will change as graphics drivers do.
[16:09] <slangasek> ogra_: ok, so you know that's not a complete MIR bug yet, right :)
[16:10] <ogra_> kirkland, any idea why snappy seems to be the only consumer of ubuntu-fan (it is in universe atm)... i thought it was supposed to be some kind of default for all container related installs
[16:10] <qengho> Why do snaps in the store show up sometimes and not sometimes, on new instances, with "snap find"?
[16:12] <qengho> Are snaps in the store still valid?
[16:13] <dpm> jibel, sorry, I was on a call. Did you manage to get the apps installed in the meantime, or do you need help?
[16:32] <dpm> sergiusens, if I want to build a qmake app, which essentially needs 'qmake' to be run, and then 'make' over the generated Makefile, what's the best way to do this with snapcraft? Creating a qmake plugin that inherits the make plugin?
[16:33] <qengho> dpm: I have done that sort of thing a few times. You might want to just copy the make plugin and change it, too. Your choice.
[16:34] <dpm> qengho, thanks! I'd rather do something I can reuse, so perhaps creating a qmake plugin might be the way to go. Do you have any examples of how you've done it before?
[16:34] <jibel> dpm, yes, I reset everything again
[16:35] <ram_> hi, i'm trying to boot in "try" mode. It is told in the guide that "/lib/systemd/system/ubuntu-core-snappy.service" will undo the action. But I find no such service file within lib/systemd/system directory. any help??
[16:35] <jibel> until next upgrade :)
[16:37] <ogra_> stop that upgrade madness ...
[16:37] <ogra_> just stay with what works :P
[16:37] <dpm> jibel, ok, glad it worked :)
[16:38] <qengho> dpm: let me push something up...
[16:38] <dpm> awesome, thanks!
[16:38] <dpm> popey, jcastro, do you happen to know how we can get notifications for new Ask Ubuntu questions tagged with 'snapcraft' or 'ubuntu-core' on this channel?
[16:38] <popey> there was an au bot
[16:38] <jcastro> there's a bot
[16:39] <popey> dunno who ran it
[16:39] <qengho> dpm: http://bazaar.launchpad.net/~cmiller/+junk/kodi-snap/view/head:/parts/plugins/x-fake_autotools.py
[16:39] <jcastro> I can find out
[16:40] <ram_> hi oliver, can you help me?
[16:40] <ram_> i'm trying to boot in "try" mode. It is told in the guide that "/lib/systemd/system/ubuntu-core-snappy.service" will undo the action. But I find no such service file within lib/systemd/system directory. any help??
[16:41] <qengho> ram_: Which guide?
[16:41] <ram_> this one https://developer.ubuntu.com/en/snappy/guides/system-updates/
[16:42] <ram_> then who will remove the file /boot/uboot/snappy-stamp.txt ?
[16:44] <ogra_> ram_, that hasnt bee used in ages
[16:44] <ogra_> uboot is completely managed inside the uboot.env file
[16:45] <ogra_> writing text files to fat turned out to be pretty unreliable and made us end up with corrupt fat every now and then
[16:45] <ogra_> so everything was moved into the uboot.env file which has a fixed size, is binary and not prone to filesystem corruption
[16:48] <ram_> thanks ogra_. so how to implement the logic? is there no need for system-stamp.txt file? i have u-boot based board
[16:49] <jcastro> I am trying to snap a node app: http://paste.ubuntu.com/15953115/
[16:49] <jcastro> but I get this error when doing a `snapcraft snap`: Issues while validating snapcraft.yaml: The 'command' property does not match the required schema: './bin/google-music-electron' is not of type 'object'
[16:49] <ogra_> ram_, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files ... have a look at the other gagdet snaps
[16:51] <qengho> jcastro: Sounds like you have a string and it expects (for some reason) a dictionary.
[16:51]  * ogra_ tickles mvo again about that bug team subscription for the packages ...
[16:52] <ram_> @ogra_ thanks for that; i'll try. can you guys please please update the guide!
[16:52] <nothal> ram_: No such command!
[16:52] <qengho> jcastro: pastebin your snapcraft yaml?
[16:52] <ogra_> ram_, we will once the gadgets format is final ... it will be re-worked the next weeks
[16:53] <jcastro> qengho: http://paste.ubuntu.com/15953115/
[16:53] <jcastro> I'm mostly just trying to hello world a node.js electron app
[16:53] <ram_> @nothal sorry what?
[16:53] <nothal> ram_: No such command!
[16:53] <ogra_> ram_, its a bot :)
[16:54] <ogra_> (unlike all other bots in ubuntu channels iit reacts to @ instead of ! )
[16:54] <qengho> jcastro: Your "command:" should be a child of "google-music-electron", not a sibling.
[16:54] <ram_> ha ha
[16:54] <qengho> jcastro: Indent "command" a bit more.
[16:55] <ogra_> jcastro, learn the genealogy of a snap package :)
[16:55] <jcastro> yargh, so simple, thanks.
[16:55] <ogra_> for complex snaps you need to ship an ancestry tree alongside ... describing gandma and gandpa :P
[16:56] <qengho> niblings. pets. planetary system....
[16:56] <ogra_> :)
[16:56] <dpm> awesome, thanks qengho!
[16:58] <davmor2> ogra_: thank god it's nothal I could live happy knowing I don't need to kill it
[16:58] <ogra_> it might still kill you though
[17:07] <sergiusens> dpm yes, inherit make, look at the cmake plugin for inspiration
[17:08] <dpm> thanks sergiusens
[17:09] <sergiusens> jcastro indentation of your yaml is wrong; line 6 and 7
[17:33] <jcastro> sergiusens: in the docs the node example pulls from npm, is there a way to do a local npm build instead?
[17:35] <sergiusens> jcastro look at the webchat example
[17:35] <jamiebennett> dpm, going back to your comments about .desktop files, should the clock and cal show an icon in the app switcher on SDoC?
[17:35] <sergiusens> jcastro https://github.com/ubuntu-core/snapcraft/tree/master/examples/webchat
[17:36] <dpm> jamiebennett, yes, they should. We've tracked the fact that some users are not seeing the icons in the dash as they need to log out and log back in after the snapd 2.0.2 installation
[17:36] <jcastro> sergiusens: perfect, thanks!
[17:36] <jamiebennett> dpm, OK, will test that
[17:36] <dpm> jamiebennett, https://askubuntu.com/q/759557
[17:37] <sergiusens> jcastro you can laugh at that js code; I don't do js, that was my example after 1 hour into it
[17:43] <ogra_> jcastro, once you are done laughing, snap up something useful ... like the unifi controller ;)
[17:43]  * ogra_ would be your first user
[17:45] <jcastro> sergiusens: I'm just trying to do a google music app thing, I'm almost there, just need to find what to put in the app: section
[17:45] <jcastro> ogra_: I have a unifi so yeah, that interests me. :)
[17:45] <ogra_> jcastro, me too, i'm just to lazy to snap it up ... but this is the *perfect* thing for a snap package :)
[17:46] <jcastro> sergiusens: all the node examples are webapps with services though, I can't really find a desktopy example
[17:46] <ogra_> i'll probably do it one day though
[17:54] <qengho> Okay, I have a rpi3 freshly-flashed with m'vo's new image. Why does "snap find tor-middle-relay.chadmiller" not find my package?
[17:54] <ogra_> are you sure you are chadmiller ?
[17:54] <ogra_> :P
[17:55] <qengho> It's been a long release, but I'm like 90% sure.
[17:55] <ogra_> ( i think you dont need the uploader suffix anymore)
[17:55] <ogra_> (for searching that is)
[17:56] <ogra_> ubuntu@localhost:~$ snap find tor-middle-relay
[17:56] <ogra_> Name             Version   Summary
[17:56] <ogra_> tor-middle-relay <IP_ADDRESS>-3 Essential infrastructure node for Tor network
[17:56] <ogra_> works fine here
[17:56] <qengho> $ snap find tor-middle-relay
[17:56] <qengho> error: no snaps found for "tor-middle-relay"
[17:57] <ogra_> oh, i'm two days outdated on that image ... ignore me
[17:57] <ogra_> did you release it for 16 yet ?
[17:58] <qengho> ogra_: I don't know what that means, and that might be the problem.
[17:59] <ogra_> in the store ui you need to release it for the 16 release
[17:59] <ogra_> i think
[18:01] <qengho> "Supported releases
[18:01] <qengho> rolling-core"
[18:04] <jamiebennett> dpm, have you seen this before? http://paste.ubuntu.com/15954428/
[18:05] <dpm> jamiebennett, I've seen it happening on another app I was working in, but not in clock
[18:05]  * dpm tries to launch clock again
[18:06] <dpm> jamiebennett, hm, still seems to work for me. It might be worth looking at entries related to launching clock on /var/log/kern.log and point the security guys to them
[18:07] <qengho> ogra_: I think that means re-uploading the same files. Store doesn't seem to have a UI for mutating the release series.
[18:07] <ogra_> i actually dont know ..
[18:07] <ogra_> but there was a lot of discussion in the backlog about this topic
[18:11] <dasjoe> So, let's talk about ZFS. Is anybody working on making Ubuntu Snappy Core ZFS-based? Or is this blocked by ZoL not supporting x86 and just barely supporting ARM for now? :)
[18:11] <ogra_> or any other non x86 arch :P
[18:11] <dasjoe> Well, there's not many left, are there?
[18:12] <ogra_> i assume you would irather see f2fs support than zfs
[18:12] <ogra_> given the focus is on IoT ... you dont really want a memory greedy thing like zfs
[18:13] <dasjoe> I remember playing around with Snappy back at version 40 or so, upgrading meant downloading the whole tarball that was some gigantic 40+ MB. I put it on ZFS and did the upgrade by "zfs send"ing the incremental between 40 and 41 into a file, the upgrade file was around 400k uncompressed
[18:14] <dasjoe> ZFS is not memory greedy, actually. We're working on getting ABD merged asap, so we waste less RAM on linux. The hard-coded lower limit for RAM is 64 MiB
[18:14] <ogra_> dasjoe, well, now make zfs work on some device thats stuck on a 3.10 kernel and comes with 256MB ram
[18:15] <ogra_> (which you want to use to control your heating)
[18:15] <dasjoe> Relevant upstream pull request: https://github.com/zfsonlinux/zfs/pull/3441
[18:16] <dasjoe> ogra_: hah, I'd love to do that if I had the required knowledge about C and Linux' memory management
[18:16] <rajen> Hi Friends, I am trying to build latest Snappy img using ubuntu-device-flash tool. Do you happen to know if I will need a special version of ubuntu-device-flash for the latest Snappy  image.
[18:16] <ogra_> does zfs support labels ?
[18:17] <dasjoe> ogra_: labels?
[18:17] <ogra_> rajen, yes, the latest one from http://people.canonical.com/~mvo/all-snaps/
[18:17] <qengho> dasjoe: ZFS is not likely. We could binary-diff other ways, and most Ubuntu Core machines are going to be (for a while) 32-bit ARM machines.
[18:17] <ogra_> dasjoe, all filesystem operations depend on the partition label in snappy currently
[18:18] <ogra_> so whatever FS we use needs to support labels
[18:18] <jamiebennett> dpm, did you try rebooting between tests?
[18:18]  * jamiebennett rebooted, was working before
[18:18] <ogra_> jamiebennett, this isnt windwos :P
[18:18] <jamiebennett> I now get this http://paste.ubuntu.com/15954540/
[18:18] <qengho> dasjoe: ... and I love ZFS. I worked to get ZFS support into zfsutils-linux and grub2 in time for 16.04.
[18:18] <jamiebennett> ogra_, the opposite, I rebooted and it _stopped_ working
[18:18] <ogra_> heh
[18:18] <dasjoe> qengho: hey, so did I. Hello :)
[18:19] <dasjoe> ogra_: I see. I think you can name the partition however you want, ZFS reads its own labels at fixed positions inside
[18:19] <qengho> dasjoe: high five! I wish we had started support in the installer earlier, but ZFS wasn't on my radar until January.
[18:20] <ogra_> dasjoe, our initrd needs to find the label ...
[18:20] <dasjoe> qengho: so, I've heard about installer support for 16.10, is this still the current plan? Do you think Debian could merge the relevant installer patches?
[18:20] <ogra_> if that works in zfs without adding megabytes of userspace tools to the initrd ...
[18:20] <dpm> jamiebennett, I only rebooted on Monday when I removed the whole /snaps folder and restarted snapd. I've not done it since then. Let me see if I also get a denial for gsettings schemas, it might be a red herring
[18:20] <ogra_> ... then we're fine
[18:21] <dasjoe> ogra_: well, I've seen people booting off ZFS snapshots. Anyway, I am sure we can work something out once ZoL supports x86 and ARM in any meaningful way
[18:21] <ogra_> and ppc
[18:21] <qengho> dasjoe: Do not quote me, but I would be astonished if we didn't have an unsupported path even for 16.04 before summer. Try Ubuntu"
[18:21] <ogra_> and ppc64el ... s390x ... arm64
[18:22] <qengho> dasjoe: Do not quote me, but I would be astonished if we didn't have an unsupported path even for 16.04 before summer. "Try Ubuntu", open terminal, add PPA, update, start installer.
[18:22] <dasjoe> ogra_: s390x and arm64 are supported as of now, I believe
[18:22] <ogra_> ah, cool
[18:22] <rajen> Tanks, ogra_..Did anything change w.r.t gadget snap. Earlier I used "--gadget canonical-pc.canonical" option. Now it does not work.
[18:22] <dasjoe> qengho: interesting. I'll query you what my current installation script does
[18:22] <dpm> jamiebennett, I'm getting another type of denials, but those don't stop the app from starting: http://paste.ubuntu.com/15954571
[18:22] <ogra_> rajen, drop the .canonical from the end
[18:22] <dasjoe> qengho: I've been working with rlaager to get his How-To up to date for 16.04
[18:22] <ogra_> not needed anywhere anymore
[18:23] <qengho> Nice.
[18:23] <rajen> ogra_  What about "--os ubuntu-core.canonical"
[18:23] <jamiebennett> dpm, and you snap looks like this?
[18:24] <jamiebennett> ubuntu-clock-app  3.6+snap3  ubuntucoredev
[18:24] <ogra_> rajen, same thing
[18:26] <dasjoe> ogra_: I just checked, PPC seems to be supported, too
[18:26] <ogra_> neat
[18:26] <rajen> ogra_, Doesn't seem to work :(  http://pastebin.ubuntu.com/15954604/
[18:27] <ogra_> anyway, i doubt we'd win many of the embedded developers with defaulting to zfs
[18:27] <dasjoe> So we're waiting for 32 bit support to become better, which follows above ABD patches and possibly more work
[18:27] <ogra_> having it optional once we have an installer is another story though :)
[18:27] <dasjoe> I'm just starting out as an embedded guy, I've been trying to buy a Qseven dev kit from Seco for the past few days
[18:28] <ogra_> (but that installer thing is still far out i fear)
[18:29] <dasjoe> Also, does anybody know of a Pico-ITX (or similar) sized SBC which comes with ECC RAM and 2x SATA ports? 1x SATA + 1x mSATA/mini-PCIe is fine, too
[18:29] <dasjoe> Oh right, amd64 only for above reasons. http://www.seco.com/prods/eu/sbc-a44-pitx.html seems to be the only one
[18:29] <ogra_> i use alix apu boards here ... if these are fine, the pico ones should be too
[18:31] <dasjoe> Very interesting boards, the apu2c4 comes with ECC, too
[18:33] <rajen> ogra_, Any suggestions http://pastebin.ubuntu.com/15954604/
[18:38] <ogra_> rajen, hmm, not really
[18:39] <ogra_> that line should just work
[18:39] <rajen> doesn't seem to
[18:40] <dpm> jamiebennett, sorry, was having dinner. Yes, that's the one I've got installed. Actually, you might want to remove it and reinstall it,
[18:40]  * jamiebennett tries that
[18:40] <dpm> jamiebennett, so with the 16 release being opened yesterday on the store, all apps had to be reuploaded
[18:41] <jamiebennett> dpm, yeah, the clock worked fine until I rebooted a couple of hours ago
[18:41] <ogra_> rajen, might be that you need 16 instead of rolling
[18:41] <jamiebennett> dpm, before that everything was up-to-date
[18:41] <rajen> let me check
[18:42] <netpheak> hi, guys!
[18:42] <netpheak> is mvo's rpi2-all-snap.img.xz image compatible with rapid?
[18:42] <jamiebennett> dpm, nope, remove and install didn't work :(
[18:42] <netpheak> rpi3?
[18:42] <rajen> ogra_, now it proceeds. With 16.
[18:42] <ogra_> netpheak, it should (though hasnt been tested on pi3 i think)
[18:43] <netpheak> i'll give it a spin ;)
[18:43] <dpm> jamiebennett, argh :( not sure what else to try next
[18:43] <jamiebennett> dpm, slightly different error this time http://paste.ubuntu.com/15954752/
[18:43]  * jamiebennett will investigate more
[18:44] <netpheak> do i need to do anything to prepare the image?
[18:45] <dpm> jamiebennett, let me try on my laptop (I've not updated it since yesterday), see if I can reproduce the issue
[18:53] <netpheak> The image appears to work :)
[18:55] <netpheak> how do i enable classic mode?
[18:57] <josepht> netpheak: classic mode has been removed from the latest images but will be reworked and reintroduced in the coming months
[18:58] <netpheak> :/
[18:58] <netpheak> Hmm.. how to build armhf packages then?
[18:58] <netpheak> the rpi is my only arm device...
[19:00] <ogra_> netpheak, http://cdimage.ubuntu.com/ubuntu-core/daily/current/xenial-core-armhf.tar.gz ... download that ... scp it to your pi ... untar it in a subdir under /home/ubuntu ... copy /etc/resolv.conf from the pi inot the unpackaged chroot and use the chroot command to work in it
[19:03] <netpheak> Is there a way to cross compile?
[19:03] <ogra_> only for kernels so far
[19:28] <roadmr> heya, anybody know how to get snappy 2.0 to work inside a xenial lxc container? It errored during "Mount snap "ubuntu-core""
[19:28] <roadmr> s/lxc/lxd/ really
[19:30] <slangasek> roadmr: by default a container doesn't allow mount privs inside; you have to make adjustments to the profile for nested containers
[19:31] <roadmr> slangasek: ok, let me try that
[19:35] <dpm-mostly-afk> jcastro, how are you getting on with your first snap?
[19:36] <dpm-mostly-afk> qengho, do you mind if we add your kodi snap to lp:snappy-playpen? We've got a kodi snap built from .debs there, and it'd be good to have the build from sources example too
[19:36] <jcastro> dpm-mostly-afk: The thing I tried to snap has a build system so I'm not sure how to proceed
[19:37] <roadmr> is there any way for snap to cache downloads somehow?
[19:37] <jcastro> so I moved on to charm-tools and give that a shot.
[19:37] <jcastro> I have enough of that to show some other people on my team
[19:39] <dpm-mostly-afk> jcastro, yeah, that's the same I had with atom. Unless the build is generic, it might be worth writing a custom snapcraft plugin to do the build
[19:42] <rajen> Hi, I need some help with latest security profile updates that went in. While we are Snapifying our app, we are running unconfined for now. I need to know what is the equivalent for http://pastebin.ubuntu.com/15955468/
[19:44] <ogra_> i dont think there is an equivalent ... but you can install your sanp in developer mode
[19:44] <ogra_> snap install --help
[19:52] <kyrofa> Does the unity7 interface give me the ability to have a tray icon?
[19:55] <zyga> kyrofa: maybe, I don't know if anyone tried
[19:55] <zyga> rajen: old security and unconfined is gone, you will have to work with us on a proper interface
[19:56] <ogra_> Unity7 wontt though
[19:56] <rajen> zyga, Who will be the best person to work with. We have a lot of stuff we do in our app that will require permission tweaking.
[19:57] <ogra_> (trayicon is dead since we have indicators)
[19:58] <zyga> rajen: perhaps me, perhaps jdstrand, perhaps yourself
[19:58] <zyga> rajen: the first thing would be to run your snap in devel mode
[19:58] <zyga> rajen: and collect logs
[19:58] <kyrofa> ogra_, indicators is what I meant, I suppose
[19:58] <josepht> roadmr: if you get that working please let me know
[19:58] <kyrofa> ogra_, "an icon next to the clock thingie"
[19:59] <rajen> Zyga, Got it. Let me explore more. Do you happen to have a link to documentation on new security profiles.
[19:59] <roadmr> josepht: what, lxd? asking in #lxcontainers now, since I can't even run a simple nested container :(
[19:59] <josepht> roadmr: yes, I'm trying to figure that out as well
[19:59] <ogra_> Yeah, I doubt that would work from a snap... tedg might know
[20:02] <kyrofa> ogra_, what makes you doubt it? I thought it was just dbus
[20:03] <ogra_> It communicates through dubs.... You still need the UI
[20:03] <ogra_> dbus
[20:04]  * zyga published http://www.zygoon.pl/2016/04/snappy-interfaces-plugs-slots-connections.html
[20:05] <tedg> kyrofa: Basically there are a set of dbus interfaces with a TODO next to them. If it was opened, you could.
[20:05] <zyga> roadmr: hey
[20:05] <tedg> kyrofa: Depends on what gets configured in the unity7 interface.
[20:06] <kyrofa> tedg, alright that's what I thought. zyga how would I figure that out?
[20:06] <zyga> kyrofa: try it
[20:06] <zyga> kyrofa: run it with confinement, then try --devmode
[20:07] <tedg> kyrofa: https://github.com/ubuntu-core/snappy/blob/master/interfaces/builtin/unity7.go#L119
[20:07] <kyrofa> zyga, I did. It doesn't work. Okay, I didn't know about devmode
[20:07] <zyga> kyrofa: I'm sure the security team will review all changes if we choose to open more dbus interfaces but it seems reasonable to allow desktop apps to have access to this
[20:07] <zyga> kyrofa: snap install --devmode
[20:07]  * zyga will write a mini-post just about that
[20:08] <roadmr> zyga: hello! how's it going?
[20:08] <rajen> What is the new equivalent of "snappy service" command?
[20:08] <zyga> rajen: it is removed for now, it will be reintroduced later with richer APIs
[20:08] <zyga> roadmr: good, trying to rest after the marathon
[20:08] <zyga> roadmr: (the 16.04 release)
[20:09] <zyga> roadmr: trying to stay off work but you see how bad I am at this
[20:09] <zyga> roadmr: how are you doing?
[20:10] <rajen> zyga, Any alternative that I can work with meanwhile. systemctl ??
[20:11] <zyga> rajen: yes but snaps cannot use it directly (or unless they use --devmode)
[20:11] <rajen> zyga, okay..slowly slowly...
[20:26] <roadmr> zyga: hehe yea, you suck at that :) but thanks for the hard work :)
[20:26] <roadmr> zyga: doing fine, lots of fun stuff happening
[20:44] <jdstrand> kyrofa, tedg: there are still a few todos in the unity7 interface because I couldn't get various apps to work quickly enough and had to move to other things and because people who had those skills couldn't use interfaces because they only recently landed in a form that people could really develop on them
[20:44] <jdstrand> kyrofa, tedg: in other words, try this stuff and if it doesn't work file a bug, tag it with snapd-interface and we'll look at it
[20:45] <tedg> Cool, I think the only bummer is some of those interfaces won't work with unity8, but eh. I guess that's why it's called "unity7" :-)
[22:58] <wililupy> Question: When I run sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pc-linux --gadget canonical-pc -o my-snappy.img I get the following error: Determining gadget configuration expected a gadget snaps: snap not found.
[22:58] <wililupy> Anyone else running into this issue? It worked for me in the past.


[08:13] <kdeuser56> shadeslayer
[11:10] <jtaylor> doko__: has -fno-strict-aliasing disappeared from python2 build flags?
[11:10] <jtaylor> thats not good, python2 is not strict-aliasing asafe
[11:10] <jtaylor> python3 is
[11:11] <jtaylor> python2 builds now have hundreds of aliasing warnings :(
[16:54] <marvin-hh> Is there anyone in here who thinks closing this bug was sane?  https://bugs.launchpad.net/ubuntu/+source/apt-setup/+bug/38712
[16:56] <marvin-hh> I have seen such behaviour -- closing perfectly understandable bug reports -- a million times already. I would like to know a good reason for that practice. Just because you close a ticket, doesn't mean that the underlying problem goes away.
[18:08] <Novice201y> Hello. How can I check my changes in  source? Do I need to install second Ubuntu on testing machine?
[22:44] <Noskcaj> Could someone please retry pry? It's tests work fine locally
[22:45] <Noskcaj> Also, diod
[23:07] <cjwatson> Noskcaj: I'm just doing a mass give-back of failures in utopic now that it's the weekend and builders are relatively quiet.
[23:07] <cjwatson> So that'll cover that.
[23:07] <Noskcaj> thanks
[23:08] <Noskcaj> cjwatson, Is it possible to for an arch:all package to build on amd64 in ubuntu, or do i have to make it arch:amd64?
[23:09] <Noskcaj> Package is "infernal", it's amd64 and kfreebsd-amd64 in debian, but ftbfs here because of our arch:all buildd
[23:10] <cjwatson> Happy day-long build queue.
[23:10] <cjwatson> Noskcaj: The architecture-independent builder isn't customisable per-package, no.
[23:11] <cjwatson> Though we have talked about switching it to amd64 for everything.  We'd probably have to do that at a series boundary though.
[23:11] <Noskcaj> ok. I'll made a patch to make the arch:all part arch:amd64 later today
[23:11] <cjwatson> That sounds bad.
[23:11] <cjwatson> That'll mean it isn't even *available* elsewhere.
[23:12] <cjwatson> Might be better to revert the patch that stopped it working on i386, even though the point about SSE2 is in general somewhat reasonable.
[23:13] <Noskcaj> cjwatson, ok. Hopefully no one in ubuntu is using it on non-SSE2
[23:14] <cjwatson> Well, worst case is it carries on breaking for them, right?
[23:14] <cjwatson> Make sure to make a note in the changelog that this should be reverted when we change the Architecture: all build architecture to amd64 in Ubuntu.
[23:15] <jtaylor> which package?
[23:15] <cjwatson> 00:09 <Noskcaj> Package is "infernal", it's amd64 and kfreebsd-amd64 in debian, but ftbfs here because of our arch:all buildd
[23:18] <jtaylor> how does that get built on an arch:all buildd? the -doc package?
[23:19] <Noskcaj> yeah


[00:15] <cjwatson> wgrant: Is it deliberate that we typically scan building slaves twice per cycle?  Once in rescueIfLost and once in updateBuild.
[00:16] <cjwatson> Perhaps that should be hoisted up to SlaveScanner.scan.
[00:16] <wgrant> cjwatson: Not deliberate, as such, just not avoided.
[00:16] <wgrant> It should indeed.
[00:17] <cjwatson> Gets more noticeable when we may need to update the master's record of the slave version.