[07:10] <dholbach> good morning
[08:38] <Chipaca> mo'in
[09:03] <JamesTait> Good morning all; happy Global Beatles Day! 😃
[09:55] <Chipaca> fgimenez: gave up on cross-compiling
[09:55] <Chipaca> fgimenez: it'll be easier and quicker to build the packages 'by hand'
[09:55] <Chipaca> fgimenez: if building on the device is not an option, that is
[09:57] <Chipaca> fgimenez: now reviewing your funcitonal tests branch
[09:59] <fgimenez> Chipaca, ok np thanks a lot :)
[10:00] <fgimenez> Chipaca, i'm also exploring the cross toolchain path, no luck so far either
[10:09] <Chipaca> fgimenez: give me a shout when you want me to re-review that branch. looks mostly good.
[10:09] <Chipaca> mostly <=> needs fixing, but minor
[10:11] <fgimenez> Chipaca, ok, it'll be ready shortly thanks :)
[11:26] <Chipaca> fgimenez: you realise GOARCH will be arm, not armhf, on arm boards?
[11:26] <Chipaca> fgimenez: and 386, not i386, on i386 boards
[11:27] <fgimenez> Chipaca, yes, i've seen the function you mentioned in the helpers, it takes care of the change, do you think we should mimic it's behaviour here?
[11:27] <Chipaca> fgimenez: what are you using defaultArch for, now and in the future?
[11:27] <fgimenez> Chipaca, i mean, if we are going to execute the tests from that platforms we need to do the change
[11:28] <Chipaca> fgimenez: if it's for building the triplet or whatever it is, yes you need to do that
[11:28] <Chipaca> yeah
[11:28] <Chipaca> fgimenez: I'd say yes, then
[11:28] <fgimenez> Chipaca, ok, i'll put the function then
[11:30] <fgimenez> Chipaca, there's an arch parameter, that's what will be used for building the debs/image, right now the defaultArch helps to determine if you have to cross compile (if defaultArch != arch)
[11:30] <fgimenez> Chipaca, but indeed 386 != i386
[11:30] <Chipaca> :)
[11:31] <fgimenez> Chipaca, :) it'll be ready soon thanks!
[11:38] <sergiusens> morning
[11:38] <fgimenez> Chipaca, done
[11:39] <fgimenez> hey sergiusens
[11:40] <sergiusens> fgimenez: pretty please can you get rid of the dpkg -i from the tests? This won't work soon-ish
[11:40] <sergiusens> ogra_: feeling better today?
[11:41] <sergiusens> ogra_: if you do, mind reviewing https://code.launchpad.net/~sergiusens/livecd-rootfs/no-walinuxagent/+merge/262963 ?
[11:41] <Chipaca> sergiusens: he hasn't said a peep all day
[11:41] <sergiusens> Chipaca: he did review one of my MPs :-P
[11:41] <fgimenez> sergiusens, ok, we are carrying this from the shell version, are there any progress in the image creation from the branch?
[11:42] <ogra_> sergiusens, only partially... just returned from the dentist and i'm full of painkillers and antibiotics (they can extract the tooth only on monday once i got rid of that golfball on my jaw)
[11:42] <sergiusens> fgimenez: I am not tracking that, but we want to get rid of dpkg ASAP, even if it means breaking to not go down the path of never being able to remove it like on the phone
[11:42] <ogra_> but for a code review it will be good enough :)
[11:42] <sergiusens> ogra_: strong liquor can't get the job done wrt the pain?
[11:42] <rsalveti> ogra_: :-)
[11:42] <sergiusens> :-)
[11:43] <ogra_> sergiusens, i'll try that tonight ... ;)
[11:45] <fgimenez> sergiusens, ok, i'll put hands on it
[11:45] <ogra_> sergiusens, what if we need to re-build 15.04 stable azure images ?
[11:46]  * ogra_ guesses we need to check which livecd-rootfs is used for them ... if its the wily one that code dropping wont work but needs release checks)
[11:46] <sergiusens> ogra_: there's a livecd-rootfs in the ppa as well
[11:47] <ogra_> ah, and that is used for 15.04 builds ?
[11:47]  * ogra_ goes to check the logs 
[11:48] <ogra_> Get:1 http://ppa.launchpad.net/snappy-dev/image/ubuntu/ vivid/main livecd-rootfs armhf 2.301~ppa7 [32.3 kB]
[11:49] <ogra_> looks fine then
[11:49] <sergiusens> ogra_: I was told that was the case, but confirming would be good
[11:49] <sergiusens> yay :-)
[11:49] <sergiusens> ogra_: doesn't an image build for vivid pick up the livecd-rootfs for vivid?
[11:49] <ogra_> yes, but the PPA has higher prio so it doesnt pick the one from the archive
[11:50] <sergiusens> ogra_: great, in any case this would be pushed to wily only so it doesn't really matter anyways, does it?
[11:50] <ogra_> no, it is all fine, just wanted to make sure we dont break anything for that case
[11:52] <sergiusens> \o/
[11:56] <ogra_> sergiusens, top approved
[12:01] <sergiusens> ogra_: should I get rsalveti to dput?
[12:02] <ogra_> sergiusens, nope, on it
[12:02] <sergiusens> thanks
[12:05] <sergiusens> ogra_: I might be pushing it, but here's one more ;-) https://code.launchpad.net/~sergiusens/ubuntu-seeds/no-python-for-core/+merge/262966
[12:06] <ogra_> oh, wow ... well, system-image will still pull in some python i guess
[12:06] <ogra_> (py3 though)
[12:06] <sergiusens> ogra_: python3 is still there :-)
[12:07] <sergiusens> ogra_: they are different languages, one is called python and the other python3 ;-)
[12:07] <ogra_> yeah
[12:07] <sergiusens> if they were the same, there would only be 'python' pointing to whatever version :-P
[12:11] <fgimenez> sergiusens, i've removed dpkg from https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748, the tests are built locally and copied to the testbed, let me know what do you think
[12:12] <ogra_> sergiusens, i wonder if an announcement mail would make sense before merging https://code.launchpad.net/~sergiusens/livecd-rootfs/byeByeDebbie/+merge/262786 so people are prepared
[12:54] <Chipaca> sergiusens: i get what dpkg-deb is being kept for; what's dpkg itself kept for?
[13:04] <sergiusens> Chipaca: I don't know, I know why I'm removing all others
[13:05] <sergiusens> Chipaca: and it's not that big
[13:05] <Chipaca> sergiusens: ok :)
[13:05] <sergiusens> Chipaca: and I don't want to test all over again and maybe it's due to dpkg --print-architecture
[13:06] <sergiusens> ogra_: nah
[13:06] <sergiusens> :-)
[13:06] <sergiusens> it's rolling!
[13:06] <seb128> sergiusens, ogra_, I wonder if that change should be done to ubuntu-desktop-next at the same time
[13:07] <sergiusens> seb128: well I did do this one for you guys https://code.launchpad.net/~sergiusens/livecd-rootfs/no-walinuxagent/+merge/262963 :-)
[13:07] <sergiusens> seb128: although I'm not sure why you had it in the first place ;-)
[13:07] <seb128> sergiusens, thanks ;-)
[13:07] <seb128> sergiusens, we copied the ubuntu-core hooks to start
[13:07] <seb128> so we had it because core had it :p
[13:08] <sergiusens> seb128: fair enough, wrt dpkg/apt, I don't mind replicating that to desktop next
[13:09] <seb128> I'm unsure if we decided on what we want the personal image to be
[13:09] <seb128> having apt is useful for debugging, but I guess people who want it can wget & dpkg(-deb)
[13:12] <sergiusens> seb128: I would prefer someone being encouraged to bring all these tools to a snap :-)
[13:12] <sergiusens> but whatever gets the job done!
[13:12] <seb128> yeah
[13:13] <seb128> I need to try ubuntu-core to see if /etc/default/locale is missing there as well
[13:13] <seb128> oh, and if recovery mode is working
[13:13] <seb128> on personal it just do a normal boot
[13:16] <sergiusens> seb128: we do have /etc/default/locale on core
[13:19] <sergiusens> ogra_: oh, adduser is perl...
[13:19] <seb128> sergiusens, right, you have a live-build/ubuntu-core/hooks/13-set-locale.chroot
[13:19] <seb128> unsure why we didn't copy that one
[13:19] <ogra_> sergiusens, yeah :/
[13:19] <seb128> we should ;-)
[13:20] <sergiusens> seb128: locale should probably be an ubuntu-core config thing and we should be able to set it up on first boot
[13:20]  * sergiusens creates teask
[13:20] <sergiusens> err, task
[13:20] <seb128> sergiusens, can you include keyboard layout in that?
[13:20] <sergiusens> seb128: yes
[13:20]  * seb128 is tired to type loadkeys fr after every boot
[13:20] <seb128> thanks
[13:21] <ogra_> seb128, are you doing the locale thing now ?
[13:22] <seb128> ogra_, adding the file you mean? was about to, but if you have pending commit feel free to get that done first and let me know when I can do the change
[13:22] <ogra_> seb128, well, i was about to ask if you could merge https://code.launchpad.net/~sergiusens/livecd-rootfs/byeByeDebbie/+merge/262786 along :)
[13:22] <ogra_> saves wrangling in the branch
[13:22] <seb128> ogra_, you mean adding the same diff to desktop-next?
[13:22] <ogra_> and to core ...
[13:23] <ogra_> i didnt merge it yet
[13:23] <seb128> oh, if you want sure
[13:23] <ogra_> thanks
[13:23] <seb128> yw
[13:26] <seb128> ogra_, should I wait for it to be top approved though?
[13:26] <ogra_> you can ... one sec :)
[13:26] <ogra_> *click*
[13:26] <ogra_> done ;)
[13:26] <seb128> :-)
[13:28] <olli> pardon my stupidity... if I wanted to put the snappy core image onto physical x86 HW, do I just dd the image onto the disk?
[13:29] <mvo> olli: yes or to a usb stick
[13:29] <olli> nice
[13:31] <olli> mvo, also, nw config on core/snappy ... is there any way to set a fixed IP
[13:31] <olli> not sure I saw that in the wiki
[13:31] <ogra_> just edit /etc/network/interfaces.d/eth0
[13:32] <ogra_> (defaults to dhcp usually)
[13:32] <olli> that's writable
[13:32] <olli> ok
[13:32] <olli> great
[13:32] <seb128> mvo, can you dd to a partition or does it need to take all disk? and how do you configure grub then?
[13:32] <elopio> fgimenez: meeting.
[13:33] <mvo> seb128: all disks currently, it relies on a certain partiton layout and partition labels
[13:33] <ogra_> olli, the whole dir is (in case you want to create a wlan0 or some such at some point)
[13:33] <seb128> mvo, k
[13:33] <olli> ogra_, I am covered then
[13:34]  * ogra_ nods
[13:34]  * olli is preparing the matchbox to become his home "gateway"
[13:35] <ogra_> heh, with two USB NICs ?
[13:35] <olli> hence the ""
[13:35] <ogra_> :)
[13:35] <olli> it'll be my inet accessible machine
[13:36] <ogra_> we need images for alix boards :)
[13:36] <ogra_> (my favorite home router HW)
[13:45] <ogra_> rsalveti, sergiusens, any idea why we forcefully install flash-kernel into the snappy armhf rootfs ? (nothing makes use of it in our system design or does it ?)
[14:00] <sergiusens> ogra_: no, it shouldn't be needed
[14:11] <elopio> thanks for the review Chipaca!
[14:12] <elopio> fgimenez_: lets skip our qa show today...
[14:13] <fgimenez_> elopio, ok, la hora de la calidad will be back tomorrow
[14:13] <elopio> :)
[14:14] <fgimenez_> elopio, i've added changes in https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748 to remove dpkg, the tests are built locally and copied to the testbed
[14:15] <fgimenez_> elopio, seems to work good, but it's exercising the snappy shipped in the image of course
[14:16] <elopio> fgimenez_: yes, for now I would stick with the deb from trunk.
[14:16] <fgimenez_> elopio, ok, this makes cross compiling a lot easier/possible at all, i'll change that branch too
[14:19] <elopio> fgimenez_: I think I didn't explain myself correctly. I think we need to build the deb from trunk and install it.
[14:20] <elopio> but you are right that we don't need to build the deb for the tests, at least not yet.
[14:20] <elopio> fgimenez_: actually, lets go to the hangout. Sorry :)
[14:21] <fgimenez_> elopio, ok np :)
[14:43] <fgimenez_> elopio, pushed
[14:43] <elopio> fgimenez_: thank you!
[14:44] <elopio> fgimenez_: last thing, can you please remove the sudo from:
[14:44] <elopio> 315	+	infoOutput := s.execCommand(c, "sudo", "snappy", "info")
[14:44] <elopio> that was my mistake.
[14:45] <fgimenez_> elopio, sure, we can remove also the buildDebs function
[14:49] <elopio> fgimenez_: +1
[14:51] <elopio> sergiusens: ^ fixed your bzr bd problem :)
[14:52] <fgimenez_> elopio, ok, done
[14:59] <elopio> fgimenez_: bash: /tmp/snappy-test/tests/snappy.tests: No such file or directory
[14:59] <elopio> this fails because the -o of go test doesn't work.
[15:00] <elopio> I think you will have to move snappy.tests from cwd to testsDir.
[15:00] <sergiusens> elopio: go build -o does work
[15:00] <sergiusens> elopio: go build -o /tmp/snappy ./cmd/snappy
[15:00] <fgimenez_> elopio, i se it working here
[15:03] <elopio> fgimenez_: that works, but $ go test -c ./_integration-tests/tests/ -o /tmp doesn't
[15:03] <sergiusens> elopio: -o needs to be the full output file, not a path
[15:04] <elopio> sergiusens: $ go test -c ./_integration-tests/tests/ -o /tmp/snappy.test
[15:04] <elopio> doesn't work either.
[15:04] <fgimenez_> elopio, http://paste.ubuntu.com/11773748/ with the current code, the binary seems to be there
[15:05] <fgimenez_> elopio, meeting
[15:06] <fgimenez_> and Chipaca, ^
[15:06] <elopio> http://cdn.meme.am/images/84688.jpg
[15:15] <fgimenez_> sergiusens, ogra_, tedg, elopio sorry guys, trying to reconnect
[15:15] <ogra_> fgimenez_, we finished
[15:15] <sergiusens> fgimenez_: no worries, we are done
[15:15] <elopio> fgimenez_: we are done. You can give two updates tomorrow :)
[15:16] <tedg> What they said
[15:16] <fgimenez_> ok, np :)
[15:18] <elopio> fgimenez_: so, if you run this, do you get the file in tmp? $ go test -c ./_integration-tests/tests/ -o /tmp/snappy.test
[15:20] <elopio> if I do that on my two machines, I get the file in pwd. Nothing in tmp.
[15:33] <sergiusens> elopio: go test has no -o though
[15:37] <elopio> that's why I think it shouldn't work for fgimenez.
[15:38] <elopio> fgimenez: maybe you already had the test in /tmp/ ?
[15:39] <fgimenez> elopio, nope, http://paste.ubuntu.com/11773921/
[15:40] <fgimenez> here mentions the -o flag https://golang.org/cmd/go/#hdr-Test_packages, perhaps it's outdated?
[15:42] <fgimenez> elopio, what is the output of go help test for you, is the -o flag there?
[15:43] <elopio> fgimenez: http://paste.ubuntu.com/11773927/
[15:43] <elopio> I do the same and the file doesn't exist for me. You are on wily, right?
[15:43] <elopio> what's your golang version?
[15:46] <elopio> fgimenez: yes, golang test on vivid doesn't have the -o option. On wily it does.
[15:46] <fgimenez> elopio, ah! ok that makes sense
[16:03] <elopio> wow, it sucks that go doesn't have mv.
[16:03] <elopio> fgimenez: this should work for both: http://paste.ubuntu.com/11774045/
[16:07] <elopio> fgimenez: also, defaultArch, getArchForImage and ubuntuArchitecture are not used.
[16:12] <fgimenez> elopio, ok pushed, when we will have multiple tests we can parameterize this without problems
[16:14] <elopio> fgimenez: ok, looks good, thank you.
[16:56] <kyrofa> sergiusens, ping
[16:59] <sergiusens> kyrofa: pong
[17:01] <kyrofa> sergiusens, I'm not sure why I didn't notice this before, but the Snappy REST doc doesn't discuss searching. Is that something you considered?
[17:01] <kyrofa> The WebDM README discusses it in the v1 API, but that's the only reference I know about
[17:01] <sergiusens> kyrofa: yes, simple search like today; I guess I need to add it
[17:02] <sergiusens> kyrofa: do we want crazy elastic search or as it is today? (webdm and cli?)
[17:02] <sergiusens> I guess the stores elastic search gets encapsulated by the API itself in most of the cases
[17:02] <sergiusens> if not all
[17:03] <kyrofa> sergiusens, well, correct me if I'm not mistaken but all we have today is filtering by installed or package type... no?
[17:03] <sergiusens> kyrofa: no
[17:03] <sergiusens> kyrofa: http://localhost:4200/api/v2/packages/?q=hello
[17:04] <sergiusens> kyrofa: http://localhost:4200/api/v2/packages/?q=hello&installed_only=true
[17:04] <kyrofa> sergiusens, ah, I didn't know about that! Haha
[17:04] <kyrofa> sergiusens, if someone types a search query into the scope... nothing happens right now :P
[17:05] <sergiusens> kyrofa: not sure you noticed, but I changed installed_only to sources=[remote,local]
[17:05] <sergiusens> kyrofa: for the new api; that makes the definition of a resource look better
[17:05] <kyrofa> sergiusens, I didn't notice, but I agree
[17:06] <kyrofa> sergiusens, okay, so to answer your question: Can you define what you mean by elastic search?
[17:06] <sergiusens> kyrofa: and I am debating if PUT should change state (installed,uninstalled) and if we should get rid of DELETE
[17:06] <kyrofa> sergiusens, you mean turn PUT into a toggle?
[17:06] <sergiusens> kyrofa: the store allows you to do stuff like https://search.apps.ubuntu.com/api/v1/search?q=content:%22framework%22
[17:07] <sergiusens> kyrofa: but if the scope is just going to be a random search box (which makes it user friendly), I don't see much use of exposing that directly
[17:07] <kyrofa> sergiusens, agreed, I don't think the scope can possibly make use of that
[17:08] <sergiusens> in other words, snappy takes care of that for you
[17:08] <sergiusens> or should at least
[17:08] <kyrofa> Yeah, just knowing that I can use the q param fixes my problem
[17:08] <kyrofa> Want me to add a comment to the REST doc?
[17:14] <sergiusens> kyrofa: sure, btw, you have edit rights now too so if you want to edit or suggest feel free
[17:14] <kyrofa> sergiusens, ah good deal!
[17:36] <elopio> sergiusens: how is it possible that your tarmac catches lint errors that mine locally doesn't?
[17:36] <elopio> aren't we all getting it from github?
[17:40] <elopio> I see the errors now, it needed an update.
[17:40]  * elopio fixes lints.
[17:43] <sergiusens> elopio: heh, so two things can cause this, the merge causes lint errors (unlikely) or your lint package needs updating
[17:43] <sergiusens> tarmac installs the latest lint on every merge
[17:43] <elopio> sergiusens: it seems lint was updated recently and now it catches more errors than before. Which is nice.
[17:44] <elopio> probably we should make our run_checks smarter, so it updates golint.
[17:44] <sergiusens> elopio: yeah, I prefer tarmac always grabbing latest instead of having to manually do this every now and then
[17:44] <sergiusens> elopio: for real success just run ./.tarmac.sh
[17:45] <sergiusens> elopio: btw, do you QA approve of this https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 ?
[17:47] <sergiusens> ogra_: did you trigger a new build?
[17:48] <elopio> sergiusens: I do, yes. As far as I could see, it doesn't affect the reboots, updates, rollbacks.
[17:48] <sergiusens> elopio: ok, I'll get it into the store in a bit
[17:57] <elopio> can somebody please take a look at this? https://code.launchpad.net/~elopio/snappy/fix1468846-lint/+merge/263012
[17:57] <elopio> so we can resume landings.
[17:57] <sergiusens> sure
[17:58] <sergiusens> elopio: strange that helpers/touch.go was not errored on before though
[20:56] <ralsina> Hello! I am trying to setup snappy on kvm using https://developer.ubuntu.com/en/snappy/start/ and it seems to work, except that I can't login into the VM using ubuntu/ubuntu as it says there. Any hints/other passwords? ;-)
[21:25] <bschaefer> hello, is there a 15.10 daily image of snappy core? Or a 15.10 core image sitting around? (Been testing on 15.04 and want to move up :)
[21:29] <manik_> bschaefer: you can see the schedule for released images here- https://launchpad.net/snappy
[21:29] <manik_> bschaefer: 15.04.1 is the latest snappy core available at the moment
[21:30] <bschaefer> but there should still be a 15.10 image or from the site a rolling image
[21:30] <bschaefer> manik_, thanks!