[01:30] hi, guys! === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [05:58] morning [07:45] ogra_: if you have time at some point it would be great if we could update the arm64 kernel in xenial in the store [08:03] Good morning [08:08] ogra_: hm, the latest rpi2 kernel from the archive (canonical-pi2-linux.canonical_4.4.0-1004.5-1.snap) appears to not boot at all, hangs at "Uncompressing Linux... done, booting the kernel." [08:09] ogra_: auto-rollback-broken-boot ftw :) [08:19] good morning [08:19] dholbach: good morning! [08:19] salut didrocks [08:38] hello, i am working on repack mopidy (http://github.com/mopidy/mopidy.git) into snap format. i'm referring py2-project of snapcraft-examples. after snapcraft build, i notice the execute file /usr/bin/mopidy as a python script file contain my work directory path in first line. [08:40] i wonder mopidy is pip compatible but spongeshaker don't has weird path. any idea how to solve or workaround it? [08:58] mvo, the cdimage snaps shoudl work ... [08:58] (for updating the store) [09:00] hmm. running snapcraft from within snapcraft tree isnt possible anymore? it cannot find the plugins for me :/ [09:01] odd [10:05] mvo, for arm64 we now have the linux-snapdragon kernel, the cdimage snap is already built from it by default since friday, i need to create as new package in the store for the new name [10:05] s/as/a/ [10:06] * ogra_ is waiting for dd to finish to chekc the rpi image [10:07] mvo, hmm, i think we need a gadget update for the rpi side [10:08] ogra_: is the kernel available as an artifact on cdimage? [10:08] ogra_: do we need a new dtb ? or why is the gadget update needed? [10:08] http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ [10:09] mvo, iirc the 4.4 support was added, the all-snaps gadget is still on older firmware [10:10] (i updated the 15.04 one but forgot about all-snaps back then) [10:11] above on the cdimage link are all all-snaps snap artefacts [10:11] ogra_: I can upload the dragonboard snap thats fine, I will upload to edge and you can test on your board? [10:11] hi, all [10:11] mvo, sure ... but create a new package called canonical-linux-snapdragon then [10:12] and delete the old one [10:12] ogra_: oh, its called differently? ok [10:12] yeah, and that kernel is supposed to support more snapdragons as i understood [10:12] ogra_: I assume the dragonboard.device tar file is not available on cdimage? "just" the snap? [10:12] ogra_: aha, interessting [10:12] the tarballs are still there too [10:13] ogra_: in the past the tarball device stuff would not boot on the dragonboard [10:13] ogra_: is that no longer the case, i.e. does it boot now? [10:13] i'm booting the cdimage snaps daily since a few weeks on the dragonboard [10:13] ogra_: cool [10:13] i admittedly havent tries the rpi in a while ... nor the BBB [10:13] *tried [10:14] how to install apache on a rpi 2 ubuntu snappy core? [10:14] rpi should work after gadget update (will work on that now) ... [10:14] BBB still needs someone to test (but i can do that as well, just later) [10:15] Sin_, sure, you just need to snap it up using snapcraft [10:16] ogra, i'm trying to install snapcraft on rpi, but no luck [10:16] if you are on the 16.04 image: sudo snappy enable-classic; snappy shell classic [10:17] that gives you an apt environment in whicgh you can do work to create snaps [10:17] (you can just apt-get install snapcraft there) [10:18] "ubuntu core does not use apt-get" [10:19] 15.04 img [10:20] Sin_, http://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz take that one [10:21] thank you! === chihchun is now known as chihchun_afk [11:05] sergiusens: i cannot run the 96boards example from withing my snapcraft-master checkout [11:05] it tells me "kernel plugin ot found" [11:05] odd because its in the snapcraft/plugins directory [11:05] are we still supporting running from within tree? [11:08] i am running ../../bin/snapcraft --target arm64 from within that 96b dir [11:08] sergiusens: http://paste.ubuntu.com/15452970/ [11:09] asac, yeah, it is supposed to just work, I've been running in tree [11:09] asac, kernel plugin is not in master [11:10] asac, https://github.com/ubuntu-core/snapcraft/pull/366 [11:11] ppisati, hmm, did you ever get around the FDT_ERR_BADMAGIC on the pi2 ? [11:11] * ogra_ is just trying the -next branch of the firmware [11:11] ogra_: yep, there's a way [11:11] ogra_: hold on [11:12] (or do you happen to have an up-to-date packaged version of the firmware) [11:12] ogra_: well, the newest formware relocate the dtb in memory [11:12] ogra_: so the answer is: [11:12] ogra_: https://github.com/piso77/ubuntu-embedded/blob/master/boards/raspi3/rootfs/boot/firmware/config.txt [11:13] ogra_: see at the end [11:13] ogra_: device_tree_address=0x02000000 [11:13] ogra_: and uboot.env needs to be modified to look for the dtb there too [11:13] ogra_: here is some more info [11:14] https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=134018 [11:14] ogra_: search for "The slot at 0x100 is limited to...| [11:14] that gives some more context [11:14] ppisati, thanks a lot ! [11:14] ogra_: our kernel support teh rpi3 btw [11:15] yeah, but we have no fully working u-boot yet i think [11:15] ogra_: yes we do :) [11:15] (i havent checked swarrens branch on the weekend ... last i checked it still was WIP [11:15] ) [11:15] ppisati, oh ! [11:15] yeah, i was using that one [11:15] and it worked [11:15] for both pi's [11:15] no [11:15] ? [11:15] ah [11:15] it's not merged [11:16] right+ [11:16] one for rpi2 and one for rpi3 [11:16] preferably i'd like to use the same image on both ... for 32bit at least [11:19] Good morning [11:42] hmpf ... [11:42] still not booting the new kernel [11:44] aha [11:45] eeek ! [11:45] ppisati, i get a massive load of "cant mount device as F2FS filesystem" during boot [11:46] purely cosmetic, but looks really scary [11:48] mvo, so i got it booting ... but you wont like the solution ... our dtb from the kernel snap needs to end up in the toplevel of system-boot and overwrite the one from the firmware [11:49] ubuntu@localhost:~$ uname -a [11:49] Linux localhost.localdomain 4.4.0-1004-raspi2 #5-Ubuntu SMP Mon Mar 14 22:27:12 UTC 2016 armv7l armv7l armv7l GNU/Linux [11:49] (using the cdimage kernel snap) [11:50] hmm, and resizing worked just fine [11:50] ubuntu@localhost:~$ df -h |grep /writable [11:50] /dev/mmcblk0p2 118G 151M 111G 1% /writable [11:50] not sure what issue ali1234 had with his === chihchun_afk is now known as chihchun [11:50] kyrofa, didnt you also see the rpi not resize ? [11:50] ogra_, indeed, yes [11:51] weird [11:51] ogra_, ppisati I've been seeing garbled HDMI output and evbug errors whenever I press keys on the keyboard as well === chihchun is now known as chihchun_afk [11:52] kyrofa, well, lets see if todays update will get you going then [11:53] ogra_, awesome :) [11:53] just need to discuss with mvo what we do with the dtb [11:54] ogra_, so reading the scrollback, it seems you have a booting rpi3? [11:54] (as a quick hack i can indeed just copy it into the gadget, but thats no solution long term) [11:54] kyrofa, no, paolo has ... i'm working on the existing images today ... once we have a release i'll look at the pi3 [11:54] kyrofa, good morning! I could really use a review on the kernel plugin PR ;-) [11:55] ogra_, ah, read too quickly then, but awesome :) [11:55] sergiusens, yessir! Part way through now [11:55] kyrofa: sergiusens: hi, is there a way to add an export to the launch wrapper created by snappy/snapcraft? [11:55] davidcalle, no; the launch wrapper is an implementation detail [11:56] davidcalle, it shouldn't be promoted to anyone ;-) People should write their own wrappers if they need that [11:56] davidcalle, or create a plugin that exports env [11:59] sergiusens: right, so, maybe the best course of action would be to create a wrapper part myself that exports what I want and launch the actual binary [12:00] sergiusens: (first time I'm trying to snap something that's not a terminal game, some concepts and ways of doing things are still abit blurry to me :) ) [12:02] davidcalle, exactly [12:02] kyrofa: sounds good, thanks [12:02] davidcalle, you'll find little wrapper scripts here and there to be pretty central to how things are done [12:07] darn, in an hour I have meetings for 5 hours :-/ [12:07] sergiusens, brutal [12:12] enoch85, you around? [12:13] sergiusens: i am using your feature bran [12:13] ch [12:14] sergiusens: http://paste.ubuntu.com/15452970/ [12:14] dholbach: kyrofa: sergiusens: it worked, thanks a lot :) [12:14] ls -la ../../snapcraft/plugins/kernel.py [12:14] -rw-rw-r-- 1 asac asac 10623 Mar 21 09:55 ../../snapcraft/plugins/kernel.py [12:15] sergiusens: let me know if you need anything [12:15] i am on 559044dc02646a3b10f078bd1d74182a3efd9a8d [12:44] mvo, http://people.canonical.com/~ogra/snappy/canonical-pi2_3.1_all.snap built from https://code.launchpad.net/~ogra/+junk/snappy-systems (see revision 32-34) ... that one boots with the cdimage kernel [12:45] mvo, the dtb problem persistes though and i'm not sure it could boot with a 4.2 kernel at all [12:46] (without manually copying the 4.2 dtb in place) [12:48] mvo, bah, you didnt use any of the cdimage snaps for the store, thats not ok [12:48] (i want to auto-submit them starting this week) [12:49] oh, wait, i got tricked by the versioning [12:50] hmm, no, actually correct, not one of them [12:50] asac, you need to be on f8fea60694c2f2540c9f7490bdd0376848179c1f [12:50] asac, https://github.com/ubuntu-core/snapcraft/pull/366/commits/f8fea60694c2f2540c9f7490bdd0376848179c1f [12:51] davidcalle, is it running already? [12:52] dholbach: yep, got it running :) Now, I'm trying to ship games in the snap and have them accessible to it [12:52] upload to the store! :) [12:52] snapcraft upload! [12:54] mvo, so i think we have to re-do all of this [12:54] we need to use the cdimage snaps here [13:07] dholbach: still trying to figure out some runtime details :) [13:07] ok ok :) [13:20] Hello, guys! [13:35] ogra_: sorry, I went for the safe route to ensure the cves are fixed, once they are in stable (i.e. now) I am more than happy to switch to the new artifacts [13:35] ogra_: this was "upload-cve-fixes-first-without-any-risk" mode [13:36] ? [13:36] these snaps all come from the very latest xenial archive debs [13:36] i would not expect any open CVEs in them [13:37] (they are completely identical to the tarballs ... content wise) === Abhishek__ is now known as Abhishek_ [13:40] ogra_, the resize on boot thing, is that for the writable partition? [13:40] yes [13:40] ogra_, should that continue to work if the writable partition is on a separate device? [13:49] mvo: hey, fyi, there is a new xenial kernel that might land today. this is going to require updates to ubuntu-core-security and ubuntu-core-launcher. I'm not sure when you are planning new os and kernel snap updates, but you might want to ping me if you are doing them before wednesday [14:00] mvo: related to that, if we are going with a two week cadence, we need to prepare today the 16.04 stable release to publish it tomorrow. [14:00] do you think we should talk to the kernel team first about doing 3 weeks instead of 2? [14:05] Hi jdstrand short question is it possible to use security-override and caps ( network-listener, ...) together? [14:05] noizer: in 16.04, yes. in 15.04, no [14:06] jdstrand: ok thx [14:08] elopio: I think we can do that [14:09] elopio: i.e. prepare update today [14:10] elopio: I triggered a new image build [14:14] mvo: ok. I also like the idea of trying a release tomorrow to get an idea of what will make it easier. We can decide on the # of weeks a little later. [14:20] elopio: yeah, we did not have a stable release since 8. match, so +1 for a new update [14:22] Will snappy be compatible with the Raspberry pi 3? [14:23] noizer, yes [14:24] ogra_: ok that will be nicee [14:25] ogra_, think the writable partition resize would continue to work if it was on another device (e.g. an external HD)? [14:26] kyrofa, thats what my "yes" above was for ... as long as the patition is properly named it should all work [14:26] (and as long as the old label from the old writablöe was removed ... i never tried what happens if you have two of them :) ) [14:26] ogra_, excellent thank you! And yeah, I imagine other problems would occur if that were the case! [14:27] jospoortvliet, are you around? [14:38] what does the caps exactly with a snap. Does it changes the apparmor profiles? [14:39] noizer: yes under the hoot it generates the profile for that specific app [14:39] ogra_, out of the blue question; how do I build a 32 kernel ofrom an amd64 system? [14:39] sergiusens, hmm, better aks the kernel guys :) [14:39] ppisati, ^ :-) [14:39] sergiusens: -m32? [14:39] :) [14:39] i guess with some clever ARCH= setup [14:39] asac, is that all? [14:39] asac Is that possible to get the changes for some caps? because i need to make my apparmor myself for my own snaps got special restrictions [14:39] passed to the toolchain [14:40] noizer: are you on 15.04? [14:40] asac no im on 16.04 rolling [14:41] asac, how about a 32 bit kernel from an armhf system? [14:41] sergiusens: i386_defconfig [14:41] dunno i will check this later and let you know if you havnet found :_) [14:42] you surely would want a cross compiler on armhf [14:44] you want to build an x86 kernel on an arm host ? [14:44] what did you guys smoke today ? [14:44] yeah or on amd64 :) [14:45] its important that you can read live the build process [14:46] hi, does ubuntu-core support booting on a GPT disk? [14:47] ysionneau, indeed [14:47] it seems the init scripts are searching for writable using findfs LABEL=writable, but in GPT you need to do findfs PARTLABEL=writable [14:47] the amd64 and arm64 images default to it [14:48] ysionneau, we set both ... partition label and filesystem label [14:48] I'm on a Tegra X1 board and I'm using my own xml to describe the partitionning [14:48] I guess my issue is in this xml [14:49] I set name="writable" for the partition, but it does not seem to set the label, only the partlabel [14:50] http://paste.ubuntu.com/15463687/ [14:50] ubuntu@localhost:~$ findfs LABEL=writable [14:50] /dev/mmcblk1p9 [14:50] ah, I guess it's my ext4 "file" which is missing its label then [14:50] (thats both on a dragonboard) [14:51] well, ubuntu.-device-flash creates the labels [14:51] before it unpacks the os snap in it [14:51] ("system-boot" and "writable" are the defaults) [14:53] I'm creating the ext4 myself, maybe I should just use udf [14:53] yeah, you definitely should [15:08] ogra_, ah, the pi2 gadget was updated? [15:08] ogra_, means I need to update my fork [15:08] ogra_, what changed? [15:09] kyrofa, last three commits https://code.launchpad.net/~ogra/+junk/snappy-systems [15:09] (i'm about to merge that into the main tree) [15:09] ogra_, ah, very nice. Okay I'll keep an eye out [15:11] kyrofa, meeting? [15:12] sergiusens, sure! I figured you were booked [15:12] kyrofa, join snapcraft [15:27] yeah, I've got snappy booting on the drone board o/ [15:34] nice ysionneau \o/ [15:37] elopio: ping [15:39] I just updated my snappy machine:- [15:39] /var/lib/dpkg/info/tzdata.config: 379: /var/lib/dpkg/info/tzdata.config: cannot create /etc/timezone: Directory nonexistent [15:39] (sorry, classic dimension) [15:39] (classic)ubuntu@localhost:~$ ls -l /etc/timezone [15:39] lrwxrwxrwx 1 root root 17 Feb 3 09:22 /etc/timezone -> writable/timezone [15:40] that looks wrong (writable/timezone) is in red in my shell [15:43] popey, it exists outside of the classich container [15:43] (and we can only use relative links for that) [15:43] (though even absolute wouldnt help in this case) [15:46] elopio: I think we have an updated ubuntu-core in 16.04/edge ready for tesing [15:46] mvo: thanks. I will start. [15:46] elopio: \o/ [15:47] mvo: what about the 15.04 update? is it still happening today? [15:47] ogra_: so what's the fix? [15:49] popey, dunno, copy that dir into classic ... (no idea how) [15:50] there are a bunch more files (three iirc) [15:50] in /etc/writable [15:51] elopio: hey, the example tests appear to have errored on the plainbox snapcraft PR, would appreciate you having a quick look [15:51] elopio, please take into acocunt that we have a new name for the dragonoboard kernel and that you *need* the new pi2 gadget snap (3.1) to make the 4.4 kernel boot [15:55] joc_: looking. [15:56] mvo: the tests are failing on the rollback when comparing the versions: 16.04-20160321-05-01+fake1 <= 16.04-20160321-05-01 [15:56] that date 20160321-05-01 in the version is new. I suppose the function you wrote to compare is not ready to handle it. [15:57] ogra_: noted. [15:57] elopio, use ~fake1 ? [15:57] (i would expect this to work the same as dpkg versions) [15:58] elopio: can you point me to the actual test output please? the statement is correct, I don't think this is a version compare issue [15:59] mvo: https://paste.ubuntu.com/15464432/ [15:59] ta [15:59] mvo: fgimenez was saying that the version maybe shouldn't include the date, because we already have a date field. [16:00] elopio: aha, I think I have an idea [16:00] and we can easily change the +fake1 to ~fake1 as ogra says. That's probably better. [16:00] elopio: that may indeed be a bug in the version compare code, iirc you normally can only have a single "-" but thats ok, should be easy to fix [16:00] elopio, thats a limitation if using cdimage to build the snaps now ... [16:00] (the date in the version string) [16:01] elopio: I think ~fake1 is not what we want it will be a lower version this way but we want the fake version to be higher [16:01] i cant make cdimage aware of the latest version in the store so that i could bump it or some such ... [16:01] fgimenez, ^^ [16:02] lower, hum. This version rules are complex. [16:03] ogra_: I think the output of snappy list will be a lot nicer if we don't have the dates twice. I didn't fully understand what you said about making cdimage aware of the latest version. Could you expand a little on that? [16:04] mvo: hmmm, bug #1553040 seems to be happening on the hour [16:04] bug 1553040 in systemd (Ubuntu) "systemd-logind crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/1553040 [16:04] ogra_: lets wait with that before we figure the actual issue out [16:04] elopio, cdimage doesnt know about the store ... by default it uses version numbers based on the date for everything it builds ... i can neither know what the last version was to bump it nor can i know whats in the store to bump it by 1 [16:04] jdstrand: meh, that sucks [16:04] I guess I can uninstall ubuntu-core and reinstall [16:04] as a workaround [16:04] jdstrand: sorry for the language, I think we need to set the priority to high [16:04] jdstrand: yes, that should work [16:04] mvo: no need to be sorry. it does :) [16:05] elopio, the only safe way to generate a version on cdimage auto-builds is to actually use a version string (or parts of it) [16:05] err [16:05] is to actually use a date string [16:05] :P [16:05] jdstrand: the real fix is to just ensure the bootloader detection magic is smater and will not attempt to reboot if its not a snappy system [16:05] ogra_, could you use something like curl -s -H "X-Ubuntu-Architecture: amd64" -H 'Accept: application/hal+json' 'https://search.apps.ubuntu.com/api/v1/package/ubuntu-core.canonical/edge' | jq '.version' to get the version? [16:05] ogra_: could you take the version from the debian changelog? [16:05] * jdstrand nods [16:06] fgimenez, no, i dont have any access to the outside world during builds [16:06] elopio, which debian changelog ? [16:06] Removing ubuntu-core.canonical [16:06] elopio, ogra_: lets keep the version for now until this is better understood, it smeels like a bug in the version compare code in snappy [16:06] snappy package cannot be removed [16:06] hmm [16:06] jdstrand: lol, of course not, can't remove your os [16:06] mvo: ogra_: sounds good. [16:06] mvo, well, i agree with fgimenez that we shouldnt have the date twice ... but i have no idea wht to do [16:07] ogra_: oh, thats orthogonal I guess, thats fine [16:07] what is that -05-01 appended to the date? [16:07] elopio, the os snap isnt bound to any debian/changelog ... and cant be [16:07] elopio, time [16:08] mvo: yes, that obviously makes sense on a device, but sdoc now is interesting... I really should be able to remove that. I guess I can look at the cron job [16:08] got it. [16:08] not cron [16:08] systemd timer :) [16:08] /lib/systemd/system/snappy-autopilot.timer [16:08] yes, I was getting there :) [16:09] jdstrand: yes you should [16:09] jdstrand: I mean, yes you should be able to do that, this was written when we had no idea about this use-case [16:10] mvo: oh sure, I was simply acknowledging that fact :) [16:11] joc_: looks like an error connecting to the testbed. You can re-try them commenting: "retest this please" [16:15] jdstrand: yeah :) [16:20] updating my snappy pi.. I get this... [16:20] 2016/03/21 16:19:37.029389 sort.go:162: Invalid version "16.04-20160321-14-25", using '0' instead. Expect wrong results [16:20] is that normal? [16:21] popey, most likely related to the issue that elopio and mvo are looking at above [16:21] oh, sorry [16:22] popey: yes, thanks, what ogra_ said, but this error message is actually very useful [16:22] Oh good :) [16:23] yeah, that explins elopio's error :) [16:23] *explains [16:23] http://paste.ubuntu.com/15464724/ is the full output fwiw [16:25] popey, funny, i wonder what happens after reboot :) [16:26] seems it thinks it installed them [16:26] ogra_: I finally looked at this and I think changing the version to only have a single "-" in it would be best if that is possible [16:26] popey: thanks a lot. So it affects more than the integration tests, and you caught it early :) [16:26] ogra_: i.e. 16.04+2016032114-25 [16:27] mvo, hmm, yeah ... i can do that but need to re-build and re-upload [16:27] mvo, with a plus sign ? [16:27] ogra_: yeah, plus is fine [16:27] ok [16:27] ogra_: or give me a sec and I paste a new string, "-" and ":" are problematic [16:27] ogra_: "+" and "." are fine [16:27] that takes quite some turnaround time though (livecd-rootfs upload ... waiting for publisher for 2h ... then rebuild and re-upload to the store) [16:28] ogra_: and "-" is fine as long as there is only one [16:28] Do I dare reboot this? [16:31] do you ? [16:36] kyrofa: I'm around now for a bit [16:36] sadly, not feeling well today [16:36] mvo, http://paste.ubuntu.com/15464880/ [16:36] spend most of the day in bed and will be returning soon [16:36] sergiusens: hey [16:37] jospoortvliet, ah I'm sorry! Nothing important here, go back to bed :) [16:37] ogra_: maybe a "." in between? "date +20%y%m%d.-%M" ? [16:37] ogra_: otherwise looks fine [16:37] jospoortvliet, OC9 will be released as soon as it's built [16:37] sergiusens: did we have a nack on supporting patch files in snapcraft, or is this something that just needs work? [16:37] ogra_: I think we can not avoid this delay, we could unpublish this particular version that is problematic though [16:37] kyrofa: rocking [16:37] kyrofa: we didn't figure out what PHP modules were missing though [16:37] sergiusens: other question, is there anything discussing extending CFLAGS/CPPFLAGS/LIBS etc. somewhere? [16:37] mvo, i'll upload to the PPA first ... that at least speeds up the publlisher [16:38] jospoortvliet, the images require imagick [16:38] jospoortvliet, that build process is complicated though, so it won't make it by tonight [16:38] ok... got it [16:38] jospoortvliet, it's dog slow on the rpi2 too, FYI [16:39] kyrofa: yeah, of course... ;-) [16:39] jospoortvliet, things are a bit snappier without it :P [16:39] kyrofa: for ownCloud, we should add caching at least, that'll help with performance [16:39] quite a bit ;-) [16:39] was hoping somebody would help... [16:40] jospoortvliet, yeah, that'll help [16:40] btw see https://doc.owncloud.org/server/9.0/admin_manual/installation/source_installation.html for a list of deps that are useful/helpful [16:40] add what you can ;-) [16:41] jospoortvliet, yeah I'm familiar with it, the snap config is pretty bare-bones at the moment indeed [16:41] lool, nack on patches [16:41] lool, extend CFLAGS, CPPFLAGS and LIBS where? [16:41] * sergiusens needs to leave for a bit [16:42] sergiusens: I want to pass an extra flag in CFLAGS to my build on top of the snapcraft ones [16:42] e.g. cmake build, autotools build etc. [16:42] lool, can't you do that with the flags keywords those support? [16:43] I cant extend the current flags with this [16:43] if I say CFLAGS="foo", it will override [16:43] I could try CFLAGS="$CFLAGS foo", but dont think this works [16:43] jospoortvliet, anyway, go back to bed. I'll send out an email [16:43] lool, maybe CFLAGS="$CFLAGS foo" [16:43] kyrofa: thanks! [16:43] lool, why do you think it wouldn't ? :-) [16:43] sergiusens: I think I tried it, but I'll try again [16:44] it was before fixing the shell escaping issue, perhaps it works now [16:45] lool, btw, what is your strategy with those PRs? [16:45] lool, stop scaring your shell, then it doesnt try to escape :P [16:45] sergiusens: what's the proposed approach for patches? point at a patched tree? I'm adapting this bb recipe https://github.com/open-switch/ops-build/blob/master/yocto/openswitch/meta-distro-openswitch/recipes-ops/openvswitch/ops-openvswitch.bb which is openswitch's openvswitch build (naming is confusing); it uses upstream's tree and adds openswitch patches; trying to do the same with snapcraft is hard [16:45] sergiusens: I'm about to update them [16:46] lool, the policy is you will have your own tree [16:46] lool, if you think about, that is what patches really are; git just makes patching obsolete [16:46] just look at our ubuntu kernel :-) [16:48] sergiusens: sure, it's just that there is no merge support either, so how do you automatically take latest upstream git with your changes? [16:48] it means people need an automation point on their own [16:48] if we had something like Launchpad git recipes, then it would be fine though [16:49] e.g. I'd point at my branch with patches and merge it with upstream before building [16:49] lool, sorry, I can't follow; but more so because I need to run; can we talk later or tomorrow? [16:49] sure [16:49] ttyl [16:56] ogra_: thanks [17:22] new image build triggered === heath__ is now known as heath [17:38] thanks ogra_ [17:38]