| sergiusens | popey, I'd log them against snappy | 00:21 |
|---|---|---|
| sergiusens | kyrofa, so when you rebased you missed a fetch ;-) | 01:02 |
| sergiusens | no worries :-) | 01:02 |
| sergiusens | cherry-picking ftw | 01:03 |
| sergiusens | elopio, you around? | 01:56 |
| stgraber | jdstrand: lxd 2.0 rc7 is awaiting review in the store (maybe the last rc before final 2.0, one can hope :)) | 04:59 |
| dholbach | good morning | 06:42 |
| didrocks | good morning dholbach! | 06:52 |
| dholbach | salut didrocks | 06:53 |
| dholbach | hey davidcalle | 07:31 |
| davidcalle | dholbach: hey o/ Good weekend? | 07:42 |
| dholbach | davidcalle, yep, very much so - how was yours? | 07:44 |
| davidcalle | dholbach: great :) | 07:45 |
| davidcalle | dholbach: finishing my upgrade and trying to reproduce the issue with the snap | 07:47 |
| dholbach | ok cool | 07:48 |
| zyga | good morning | 08:08 |
| davidcalle | dholbach: resolved by making the launcher executable :) | 08:20 |
| dholbach | haha | 08:20 |
| dholbach | nice one | 08:20 |
| * dholbach hugs davidcalle | 08:20 | |
| popey | https://bugs.launchpad.net/snappy/+bug/1563223 | 08:33 |
| ubottu | Launchpad bug 1563223 in Snappy "Some standard updates break on classic, breaking snapcraft" [Undecided,New] | 08:33 |
| popey | dholbach: ^ this kinda blocks me using snapcraft in classic on my pi | 08:33 |
| dholbach | mvo, ^ have you seen anything like this before? | 08:34 |
| mvo | dholbach: I have not seen this, no, sorry, need to debug (trying to reproduce first) | 08:51 |
| === Marin is now known as Guest38540 | ||
| Guest38540 | Hey guys. Anybody using snappy with Beaglebone Black | 09:10 |
| Guest38540 | ?? | 09:11 |
| === chihchun_afk is now known as chihchun | ||
| dholbach | davidcalle, shall we catch up in a bit? | 10:46 |
| davidcalle | dholbach: sure, but we can do a quick one now if you want/have time | 10:46 |
| dholbach | yep. let's do it | 10:47 |
| davidcalle | +1 | 10:47 |
| ogra_ | ppisati, could you take a look at bug 1561920 ... that seems to actually be a kernel issue | 10:51 |
| ubottu | bug 1561920 in Snappy "Seccomp error on recent builds of snappy" [Critical,Confirmed] https://launchpad.net/bugs/1561920 | 10:51 |
| ogra_ | ppisati, i also see permission denied errors when simply running dmesg as a normal user | 10:52 |
| ogra_ | (probably related) | 10:52 |
| ppisati | ogra_: me looking | 10:58 |
| ogra_ | thanks :) | 10:58 |
| stevebiscuit | win 12 | 11:09 |
| stevebiscuit | oops | 11:09 |
| ogra_ | lose 3, keep 9 | 11:10 |
| popey | mvo: a dist-upgrade of the snappy classic install should be enough to reproduce it | 11:20 |
| noizer | Hello everyone | 11:25 |
| noizer | Just a short question is it necessary to do first a snapcraft clean and then snapcraft snap or is it good enough to do only the snapcraft snap? | 11:27 |
| ogra_ | apw, any idea whats holding back https://launchpad.net/ubuntu/+source/linux-raspi2/4.4.0-1005.6 ? | 11:41 |
| davidcalle | noizer: from my experience, it depends which changes you have made. I've found it quite useful (and faster) to clean a specific part I've changed (eg. snapcraft clean <part>;snapcraft snap) | 11:41 |
| noizer | oooh ok nicee | 11:43 |
| noizer | davidcalle: didn't knew that you can clean only one part :p | 11:43 |
| davidcalle | noizer: discovered it this morning ;) | 11:44 |
| noizer | davidcalle: heheh xD | 11:44 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | hrm | 12:05 |
| ogra_ | ubuntu@localhost:~$ ls -l /etc/network/interfaces.d/ | 12:05 |
| ogra_ | total 8 | 12:05 |
| ogra_ | -rw-r--r-- 1 root root 64 Mar 28 09:23 50-cloud-init.cfg | 12:05 |
| ogra_ | -rw-r--r-- 1 root root 40 Mar 28 09:19 eth0 | 12:05 |
| ogra_ | so thats why i have no more network at all then | 12:08 |
| jdstrand | stgraber: done | 12:12 |
| popey | dholbach: when using snapcraft, I have an app which has pre-requisites which need pulling and building. I can use after:, and it pulls and builds them fine, but I need to set --prefix to where the main package is being built. Is there some env var for the build dir in snapcraft, so i can install them there? | 12:13 |
| zyga | popey: use DESTDIR | 12:14 |
| zyga | popey: prefix is irrelevant | 12:14 |
| zyga | popey: but snapcrat will give you a DESTDIR to instal to | 12:14 |
| mvo | popey: thanks, I have not managed to find time yet but I put it on my list of things to look at | 12:14 |
| jdstrand | zyga: hey, so, a few of my PRs for the security interfaces landed, but most didn't. says there were failures witn 'integration tests', but when I click on the link to see the test result, it just spins and never shows me anything | 12:15 |
| zyga | jdstrand: that's VPN for you, you have to be connected to see jenkins | 12:15 |
| zyga | jdstrand: (hi btw) | 12:15 |
| jdstrand | ah | 12:15 |
| jdstrand | zyga: ok, well, now I get a 404 :) | 12:16 |
| jdstrand | https://github.com/ubuntu-core/snappy/pull/723 | 12:16 |
| zyga | jdstrand: I reviewed a few of your branches, my suggestion would be to keep a few open and merge/rebase the rest so that it's easier to land them | 12:18 |
| zyga | jdstrand: or try to not make them co-depend on each other | 12:18 |
| zyga | jdstrand: well, jenkins ... reliable as usual | 12:18 |
| popey | zyga: got an example? | 12:18 |
| jdstrand | zyga: they have to co-depend on each other the way all* are written | 12:19 |
| zyga | jdstrand: yeah, I know | 12:19 |
| zyga | jdstrand: example of ... ? | 12:19 |
| jdstrand | I mean, I guess I can have them all be separate and add all at the end, but that is not what you said you wanted | 12:19 |
| popey | zyga: i need to install the libs so the subsequent build finds them | 12:19 |
| zyga | jdstrand: right, I know, perhaps it'd be easier if we didn't | 12:19 |
| * jdstrand redoes all the PRs | 12:20 | |
| zyga | popey: in the sname part? | 12:20 |
| zyga | jdstrand: hmm, perhaps ask gustavo on telegram | 12:20 |
| popey | oh, these should be separate parts | 12:20 |
| zyga | jdstrand: he said he'll look at your branches | 12:20 |
| popey | oh, they are... | 12:20 |
| zyga | jdstrand: and we can always review individual patches | 12:20 |
| zyga | popey: separate parts can use typical stuff, e..g. pkg-config | 12:20 |
| zyga | popey: I don't think snapcraft gives you a way to do cross-part directory inspection easily | 12:21 |
| popey | zyga: http://paste.ubuntu.com/15551251 this is what I have so far | 12:21 |
| zyga | but don't quote me on that | 12:21 |
| zyga | popey: that looks sane, I suspect you may want to ask sergiusens how to make it work while still looking pretty | 12:21 |
| popey | zyga: is there some way to specify the build dependencies in the snapcraft yaml? | 12:26 |
| zyga | popey: yes, sure | 12:26 |
| jdstrand | oh my gosh | 12:26 |
| zyga | popey: build-packages or something like that (on each part) | 12:26 |
| * popey googles | 12:26 | |
| popey | ta | 12:27 |
| zyga | popey: I don't remember, I always check the source | 12:27 |
| popey | heh | 12:27 |
| zyga | popey: googling is not useful IMHO | 12:27 |
| zyga | popey: docs are old or useless | 12:27 |
| jdstrand | tg is saying over and over 'Error: one of the params is missing or invalid' | 12:27 |
| jdstrand | what param? /me is just trying to send a message | 12:27 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/744 (for later) | 12:28 |
| zyga | jdstrand: I'm iterating over feedback that gustavo left earlier today | 12:28 |
| sergiusens | zyga, popey jdstrand `snapcraft help plugins` (and the reason I'm doing a pseudo rtfm is because I want feedback :-) ) | 12:34 |
| zyga | sergiusens: I know about that but it's always insufficient (could have been improved since I last looked) | 12:35 |
| zyga | sergiusens: I'd personally prefer a man page that mentions that | 12:35 |
| zyga | sergiusens: or other well-known way to discover this | 12:35 |
| popey | sergiusens: thanks | 12:35 |
| zyga | sergiusens: but I'm skewed already and I always read the source for up-to-date knowledge about each plugin | 12:35 |
| popey | sergiusens: is qmake on your list of plugins to make sometime? | 12:35 |
| popey | or some other way I can inject a "qmake" call before "make" using the make plugin? | 12:36 |
| sergiusens | popey, yeah, we will make a qmake one; but we are working on foundation stuff right now | 12:36 |
| popey | no workaround for now? | 12:36 |
| * zyga recalls qmake sucking for not having standardized DESTDIR | 12:37 | |
| sergiusens | popey, in your project dir cp cmake.py -> parts/plugins/x-qmake.py | 12:37 |
| sergiusens | and edit x-qmake.py to your liking (changing the cmake calls for qmake ones) | 12:37 |
| jdstrand | sergiusens: imho, strip feels like a weird name for that step. I understand why-- you are taking away stuff from staging, but you are also adding meta. 2 cents | 12:37 |
| sergiusens | and in snapcraft.yaml specify 'plugin: qmake' | 12:38 |
| popey | project dir? | 12:38 |
| sergiusens | popey, your project dir == where snapcraft.yaml is | 12:38 |
| popey | ah | 12:39 |
| jdstrand | sergiusens: I think this is quite handy. I would be even more so if there was an example that used each that you then tersely explained | 12:41 |
| sergiusens | jdstrand, thanks for the tip; I think we can add individual topics for each of the keywords | 12:46 |
| jdstrand | sergiusens: you could go that way, which would be handy, or(/and?) add a 'Putting it all together' section that has a larger example and how they all relate to each other, the timing of things, etc | 12:47 |
| sergiusens | sounds good | 12:49 |
| popey | sergiusens: the nodejs plugin seems to assume the thing I want is in npm.. what if it's something that's on github? the nodejs plugin doesn't support source: ? | 12:49 |
| sergiusens | popey, it does support source | 12:49 |
| === inaddy_ is now known as inaddy | ||
| popey | "no handler to manage source" is what i guet | 12:49 |
| sergiusens | popey, https://github.com/ubuntu-core/snapcraft/tree/master/examples/webchat | 12:50 |
| popey | *get | 12:50 |
| * popey looks | 12:50 | |
| sergiusens | popey, really? | 12:50 |
| popey | ah, your source is in current dir | 12:51 |
| popey | I'm trying to get it to grab from github for me, I'll do your way | 12:51 |
| sergiusens | popey, you can do it your way too | 12:52 |
| popey | wonder why it fails here | 12:52 |
| sergiusens | popey, use source and "source-type: git" | 12:52 |
| popey | ahhh | 12:52 |
| popey | doh | 12:52 |
| popey | ta | 12:52 |
| sergiusens | or use the git uri instead of https | 12:53 |
| popey | building \o/ | 12:53 |
| popey | thanks sergiusens | 12:53 |
| popey | sorry for the newb questions :) | 12:53 |
| sergiusens | \o/ | 12:53 |
| popey | this is all a new adventure for me ㋛ | 12:53 |
| ogra_ | and dont use any left padding ;) | 12:53 |
| sergiusens | popey, all good, if anything feels confusing a bug report is always welcome :-) | 12:53 |
| popey | holy freole, it built | 12:54 |
| sergiusens | popey, making it work is the hard part ;-) | 12:55 |
| sergiusens | popey, node projects use the source dir as the place to land config | 12:56 |
| sergiusens | popey, shout irc was sort of sane and had a flag to tell it where to store config | 12:57 |
| ogra_ | mvo, where do we stand with the release, it would be really helpful to finally have an all-snaps beta image at some point | 12:58 |
| ogra_ | (o5r even alpha) | 12:58 |
| jdstrand | olli: fyi, bug #1562989 is fixed. upgrade to ubuntu-core-launcher 1.0.22 and ubuntu-clock-app.clock starts again | 12:59 |
| ubottu | bug 1562989 in ubuntu-core-launcher (Ubuntu) "'aa_change_onexec failed with -1. errmsg: Permission denied'" [Critical,Fix released] https://launchpad.net/bugs/1562989 | 12:59 |
| popey | sergiusens: yeah, this is gonna be tricky I imagine. | 13:00 |
| olli | jdstrand, most awesome! | 13:00 |
| sergiusens | popey, just patches upstream :-) | 13:00 |
| sergiusens | kyrofa, btw, did you see my comments, we need to sync | 13:01 |
| ogra_ | sigh | 13:11 |
| ogra_ | ubuntu@localhost:~$ snap find | 13:11 |
| ogra_ | error: cannot list snaps: cannot communicate with server: Get http://localhost/2.0/snaps?sources=store: dial unix /run/snapd.socket: connect: no such file or directory | 13:11 |
| ogra_ | aha ... a manual "sudo systemctl start ubuntu-snappy.snapd" fixes it | 13:13 |
| kyrofa | Good morning | 13:30 |
| sergiusens | kyrofa, hey! | 13:32 |
| kyrofa | sergiusens, sorry, family is sick, just got in. You're right, looks like I was still out of date on that branch :P | 13:33 |
| kyrofa | sergiusens, fixing now | 13:33 |
| didrocks | good morning kyrofa, sergiusens :) | 13:38 |
| kyrofa | didrocks, good afternoon! | 13:38 |
| sergiusens | kyrofa, I squashed everything already; look at my comments in the PR though ;-) | 13:41 |
| sergiusens | kyrofa, unpacking stage-packages into a different dir than installdir taxes python again | 13:42 |
| kyrofa | sergiusens, ah, that explains the issues I'm having rebasing :P | 13:42 |
| kyrofa | Alright I haven't caught up on email yet-- going to the PR now | 13:43 |
| sergiusens | kyrofa, and no worries, my kid has some sort of a fever as well; I had a sleepless night again; it seems he is toothing | 13:48 |
| kyrofa | sergiusens, oh yes, that's a fun stage. The molars are the worst | 13:48 |
| sergiusens | kyrofa, for a minute I thought you were talking stage-packages and got all confused :-P | 13:49 |
| kyrofa | Apparently I don't get good wifi in that room. sergiusens you're right, the unpackdir isn't going to work. So I'm going to simply make the build cleaning smarter and unpack the debs again. Not ideal, but I think it's the only way to make this work correctly | 14:10 |
| sergiusens | kyrofa, yeah, that's what I wanted to sync on; so yeah, all good as I was thinking about double unpack | 14:12 |
| kyrofa | sergiusens, easy, I'll get back to you | 14:12 |
| kyrofa | I'm going to add a good integration test for this as well, make sure this continues to work | 14:13 |
| === kickinz1|eod is now known as kickinz1 | ||
| elopio | kyrofa: answering your ping from yesterday, I see no way of showing that the branch is not merged with master without making it required. | 14:23 |
| kyrofa | elopio, alright, thanks for getting back to me! | 14:24 |
| elopio | kyrofa: if we handle the merge on jenkins, we could do anything we want. But without nice buttons, just comments with the bot back and forth on the PR. | 14:24 |
| sergiusens | ogra_, mind looking at Jian LUO's email? | 14:24 |
| ogra_ | sergiusens, was there a new one (is my mailserver slow again ?) | 14:28 |
| ogra_ | i answered one on wednesday | 14:28 |
| sergiusens | ogra_, no did not see any reply from you, there is a new one from an hour or go or so | 14:29 |
| ogra_ | https://lists.ubuntu.com/archives/snappy-devel/2016-March/001645.html | 14:30 |
| ogra_ | just me whining though ... | 14:31 |
| ogra_ | here is the proper answer: https://lists.ubuntu.com/archives/snappy-devel/2016-March/001642.html | 14:31 |
| ogra_ | ricmm, mvo i filed bug 1563358 for one of you :) | 14:38 |
| ubottu | bug 1563358 in Snappy "snappy can only handle one bootloader (if grub is installed, uboot is completely ignored)" [Undecided,New] https://launchpad.net/bugs/1563358 | 14:38 |
| ogra_ | (there was also the snappy list issue that falls apart if grub is installed on uboot systems, i sadly lost the logs for that one) | 14:39 |
| elopio | mvo: sergiusens: following your discussion about snapcraft build... Shouldn't we move all the snappy build unittests to snapcraft? | 14:54 |
| elopio | We can leave the build integration tests in snappy if snapcraft is installed in the os. | 14:55 |
| sergiusens | elopio, oh, certainly | 14:58 |
| sergiusens | it makes sense | 14:58 |
| sergiusens | but what weird build unit tests are there in snappy? | 14:58 |
| sergiusens | is there anything worth porting over? | 14:58 |
| elopio | sergiusens: both have great coverage, so most tests should overlap. But I am not sure, we should compare them. | 15:00 |
| sergiusens | elopio, want to take care of that? Not really do the work, just see if we are missing anything and add it to our suite | 15:02 |
| sergiusens | err, kyrofa or me can add it to our suite that is | 15:02 |
| kyrofa | Yeah, that makes sense | 15:03 |
| josepht | sergiusens, kyrofa: would it be worthwhile for me to add support for configflags for the make plugin? | 15:10 |
| kyrofa | josepht, just to add to the `make` invocation? | 15:13 |
| sergiusens | josepht, I would call the entry `make-parameters`; not a fan of the generic configflags name | 15:15 |
| sergiusens | josepht, and what kyrofa asked | 15:15 |
| Iot_developer | Hi, I'm new here :) | 15:20 |
| kyrofa | Welcome Iot_developer | 15:21 |
| Iot_developer | thanks | 15:21 |
| Iot_developer | i'm developing IOT on BBB | 15:21 |
| Iot_developer | and we have some problems wiht snappy | 15:22 |
| Iot_developer | we build our app as a snapp | 15:22 |
| Iot_developer | but we are not able to get bonescript working | 15:22 |
| ogra_ | doesnt that just need a working nodejs setup ? | 15:23 |
| ogra_ | snapcraft has a plugin for nodejs iirc | 15:23 |
| elopio | sergiusens: sure | 15:24 |
| Iot_developer | we done that | 15:24 |
| Iot_developer | node is working fine | 15:25 |
| awe | sergiusens, is there a way to list the files that a specific snap has installed? | 15:25 |
| Iot_developer | when we build app with bonescript our service is dead | 15:25 |
| awe | ( ie. the equivelent to running dpkg -L )? | 15:26 |
| kyrofa | sergiusens, this is a separate bug I'll need to file, but cleaning the build step for python plugins doesn't work since it clears out the installdir which is written to in the pull step. Think it would work to do the pip stuff into another folder that can be copied into installdir on build? | 15:26 |
| Iot_developer | when we build snap without bonescript module everything is working fine | 15:26 |
| elopio | fgimenez: can we skip la media hora de la calidad today? | 15:27 |
| ogra_ | WOAH ! | 15:27 |
| fgimenez | elopio, sure, no problem | 15:27 |
| * ogra_ just booted with "cloud-init=disabled" .... thats unbelivable fast !!! | 15:27 | |
| fgimenez | elopio, i have a couple of prs for you to review, other than that i've been preparing the connection to practitest, it'll be ready tomorrow | 15:30 |
| elopio | fgimenez: I'll take a look at your profile and review them. | 15:30 |
| ogra_ | Iot_developer, theer should be info in the logfiles telling you why that happens | 15:31 |
| fgimenez | elopio, thx, i've been also debugging the integration test coverage generation error, something's wrong with the current production server, it works fine in an older one | 15:31 |
| sergiusens | ogra_, did you take care of password, ssh and all that mumbo jumbo? | 15:34 |
| ogra_ | sergiusens, i did set it after i had a firestboot done | 15:34 |
| ogra_ | so cloud-init still did set this up but doesnt run on subsequent boots | 15:35 |
| ogra_ | sergiusens, the cloud-init from the weekend completely broke outr boots | 15:35 |
| Iot_developer | the logfile says that ( is missing, and we don't know what to do | 15:36 |
| ogra_ | looks like a syntax error in one of your files then | 15:36 |
| Iot_developer | that is the problem, beacuse we run that program on ubuntu debian and everything works fine | 15:37 |
| noizer | rpi 3 installation is just installing the image on a sd card? | 15:46 |
| ogra_ | noizer, just dd it to the card, yeah | 15:51 |
| ogra_ | there migth still be issues and glitches, thats a very first shot | 15:51 |
| noizer | ogra_: Thx | 15:52 |
| === shuduo-afk is now known as shuduo | ||
| elopio | sergiusens: kyrofa: there is no good way to rebase the branch before merging, because the plugin uses the github API and we only have the equivalent of the green merge button. | 16:07 |
| elopio | we could do it without the plugin all in bash, but it wouldn't be as nice. Anyway, it's ready if you want to try it. I can unprotect the branch now and you comment "merge this please" when you are happy. | 16:07 |
| zyga | jdstrand: hey | 16:08 |
| zyga | jdstrand: I think this is ready for another review https://github.com/ubuntu-core/snappy/pull/744 | 16:09 |
| sergiusens | elopio, kyrofa but without rebasing it feels weird | 16:09 |
| kyrofa | And it doesn't really chance anything, right? | 16:09 |
| kyrofa | change* | 16:09 |
| jdstrand | ack. it'll be a little bit | 16:12 |
| elopio | sergiusens: kyrofa: | 16:16 |
| elopio | sorry. | 16:16 |
| elopio | sergiusens: kyrofa: no, we still have to ask the author for a manual rebase. | 16:16 |
| elopio | and when he rebases, the tests will be triggered. So this will just slow down the merge by re-running the tests again. | 16:17 |
| elopio | I've asked the plugin author about adding rebase. I'll make a quick job with all manual, to see how it goes. | 16:18 |
| kyrofa | elopio, alright so using this can we leave the rebase requirement in place to merge with github but allow merging via jenkins in case there's something we know doesn't need a rebase? | 16:18 |
| kyrofa | If we remove the requirement there's no way to know if a rebase is needed without manual work | 16:18 |
| elopio | kyrofa: that would work only if the github protection is not at the API level, just on the GUI. Which I doubt, but have to try. | 16:19 |
| kyrofa | elopio, ahh, I see | 16:20 |
| kyrofa | Yeah I'm not sure it's worth it just yet, then | 16:20 |
| elopio | kyrofa: oh wait, I'm stupid. I can allow admins to ignore the required status checks. | 16:22 |
| kyrofa | elopio, ah! And not being up-to-date is a status check? | 16:23 |
| elopio | kyrofa: done. You can now click a red merge pull request button. | 16:23 |
| kyrofa | elopio, I don't see it-- though I'm not actually sure I'm an admin | 16:24 |
| elopio | kyrofa: right, you are not ^_^ | 16:25 |
| kyrofa | But that's exactly the kind of functionality I wanted! Good find :) | 16:25 |
| elopio | kyrofa: take a look now. | 16:25 |
| kyrofa | elopio, peeeerfect! | 16:25 |
| elopio | so I guess that if I make snappy-m-o admin, the jenkins plugin merge would work. Now I think it's not useful, but good to know. | 16:27 |
| kyrofa | elopio, yeah this is what I was hoping for :) . Thank you! | 16:33 |
| AnInstanceOfMe | Following snappy tutorial on ubuntu dev site, but just get "Issues while validating snapcraft.yaml: The 'parts' property does not match the required schema: None is not of type 'object'" when running 'snapcraft stage'. Any idea where I'm going wrong? | 16:33 |
| kyrofa | AnInstanceOfMe, mind pasting your snapcraft.yaml on http://pastebin.ubuntu.com/ ? | 16:35 |
| kyrofa | AnInstanceOfMe, also, what version of Snapcraft are you using? | 16:35 |
| AnInstanceOfMe | kyrofa: It's version 2.6.1 and I'm running on Ubuntu Mate 16.04 beta. The snapcraft.yaml is just the example on the Ubuntu dev site. | 16:37 |
| kyrofa | AnInstanceOfMe, okay, which tutorial then? | 16:38 |
| AnInstanceOfMe | https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/ | 16:38 |
| josepht | kyrofa: yes | 16:40 |
| josepht | sergiusens: make-parameters sounds fine to me :) | 16:40 |
| kyrofa | josepht, sure. And I agree, the name "configflags" makes sense for autotools and cmake, but not make. | 16:43 |
| kyrofa | AnInstanceOfMe, the tutorial works for me. So please paste your yaml | 16:44 |
| === kickinz1 is now known as kickinz1|eod | ||
| AnInstanceOfMe | kyrofa: Rebooted the machine and that issue is no more. Sorry for the bother. | 17:00 |
| kyrofa | AnInstanceOfMe, not a problem :) | 17:01 |
| ogra_ | popey, your system looks really odd | 17:03 |
| ogra_ | (snaps not removed on upgrade ... snaps that arent actually published installed etc) | 17:03 |
| === chihchunl is now known as chihchun | ||
| === ubott2 is now known as ubottu | ||
| === FourDollars_ is now known as FourDollars | ||
| === attente_ is now known as attente | ||
| plars | ogra_: do you know if there are known problems with the dragonboard image? I am getting an error trying to boot it: | 17:25 |
| plars | https://www.irccloud.com/pastebin/ptzM39TI/ | 17:25 |
| popey | ogra_: it's edge | 17:37 |
| === nessita__ is now known as nessita | ||
| sergiusens | elopio, what is this about ERROR: No artifacts found that match the file pattern "adt-run-output/binaries/*.deb". Configuration error? | 17:45 |
| sergiusens | elopio, in http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/296/console | 17:45 |
| sergiusens | makes adt tests fail | 17:45 |
| elopio | sergiusens: let me fix that | 17:50 |
| sergiusens | elopio, I think I made a mistake in that process as well :-/ | 17:51 |
| sergiusens | elopio, you will see | 17:51 |
| elopio | sergiusens: I don't see it. | 17:54 |
| elopio | It's fixed, but I'm running the job to confirm. I forgot to add the -o parameter. | 17:55 |
| joc_ | elopio: will that make my branch pass again? :) | 17:56 |
| elopio | joc_: yes, that's the same error you got on your last run. | 17:57 |
| elopio | however... | 17:57 |
| elopio | we have a new one: | 17:57 |
| elopio | The following packages have unmet dependencies: | 17:57 |
| elopio | linux-generic : Depends: linux-image-generic (= 4.4.0.16.17) but it is not going to be installed | 17:57 |
| elopio | Depends: linux-headers-generic (= 4.4.0.16.17) but 4.4.0.15.16 is to be installed | 17:57 |
| joc_ | :/ | 17:58 |
| elopio | let me see how to fix that. | 17:58 |
| sergiusens | elopio, you don't see it; I'll share it privately | 17:58 |
| elopio | that error is on the cloud image that autopkgtest uses. Not much I can do for it. | 18:02 |
| elopio | I suppose it needs to be refreshed, somehow. | 18:02 |
| kyrofa | sergiusens, alright I remember the insidious problem with simply unpacking again in build(), but I think I have a rather elegant solution | 18:06 |
| ogra_ | elopio, smells like you are enabling proposed | 18:07 |
| ogra_ | (thats a typical out-of-sync breakage of a half migrated package) | 18:08 |
| ogra_ | (you will see tha every now and then in -propoased, pretty normal) | 18:09 |
| kyrofa | sergiusens, I just pushed up a new commit to my branch, which is up-to-date with yours | 18:10 |
| sergiusens | kyrofa, \o/ | 18:12 |
| kyrofa | sergiusens, agh, wait I broke a few tests. Hold on a sec | 18:13 |
| kyrofa | (just log messages) | 18:14 |
| elopio | ogra_: not me. Maybe the image has proposed enabled. But we are just copying what they do on the distro, so everything should be failing now. | 18:17 |
| ogra_ | elopio, well, linux-generic just migrated | 18:17 |
| elopio | right, just bad timing | 18:20 |
| elopio | it's running now. | 18:20 |
| ogra_ | thats why i'm so critical about using -proposed ... it simply isnt reliable | 18:21 |
| ogra_ | you will have failures every now and then | 18:21 |
| elopio | ogra_: please help me going again through the snappy release process. | 18:28 |
| elopio | so, we put every day a deb build from the branch into xenial-proposed. | 18:28 |
| elopio | we generate a ubuntu-core snap using proposed as the source and put it into edge. | 18:28 |
| elopio | we test, test, test, and when we are happy to get it into stable, we move snappy and all it's dependencies from proposed to the archive. | 18:28 |
| elopio | then we regenerate the snap without using proposed, and put it into stable. | 18:28 |
| kyrofa | sergiusens, NOW it's all good | 18:28 |
| elopio | is that right or am I missing something important? | 18:28 |
| ogra_ | elopio, we generate all kernel and os snaps on cdimage | 18:28 |
| ogra_ | elopio, i'm still working on auto-submission to the sotre for these daily builds | 18:28 |
| ogra_ | (just got disctracted by researching all the newly introduced cloud-init breakage today) | 18:29 |
| elopio | ogra_: we can submit the snaps to the store on jenkins. I'm not sure if that would make your life easier. | 18:29 |
| ogra_ | elopio, i cant tell yet how tht will look in the store, but i was hoping that we can auto-publish the auto-uploaded snaps to edge | 18:29 |
| ogra_ | so you could roll edge images and teste them ... if they are good you can promote the snaps to the stable channel in the store | 18:30 |
| ogra_ | elopio, well, can you watch http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ (for changed MD5SUM file or some such) and pull from there with jenkins ? | 18:31 |
| ogra_ | as soon as there are updated snaps showing up ... | 18:31 |
| elopio | ogra_: yes. We put a listener on that url and any changes will trigger a job. | 18:31 |
| ogra_ | that way would indeed work too | 18:31 |
| ogra_ | and save me from hacking snap uploading into our 12.04 cdimage server :) | 18:32 |
| elopio | on the job I can put a snapcraft upload command with the credentials that we are storing in vault behind the vpn. | 18:32 |
| ogra_ | perfect | 18:32 |
| elopio | what we would be missing is the publish command, but vila told me he'll be working on that. | 18:32 |
| ogra_ | you will need some name mapping i guess though | 18:32 |
| ogra_ | i.e. xenial-preinstalled-core-armhf.raspi2.kernel.snap is in reality canonical-pi2-linux | 18:33 |
| elopio | that's easy. We make one job per snap, and hardcode the name change. | 18:34 |
| ogra_ | and xenial-preinstalled-core-arm64.dragonboard.kernel.snap ... canonical-snapdragon-linux | 18:34 |
| ogra_ | you could grab the name from inside the snap ... but i think thats overkill (the true name is in the snap.yaml indeed) | 18:34 |
| elopio | ogra_: I wonder if snapcraft is not doing that already. | 18:35 |
| kyrofa | elopio, for the name of the upload? | 18:35 |
| ogra_ | when uploading ? not sure ... it would either need to bind-mount the snap or extract the squashfs | 18:35 |
| elopio | anyway, I'll get to it tonight, give it a try uploading to my account and give you the code for the job to review. | 18:36 |
| ogra_ | i guess thats quite time and space consuming | 18:36 |
| kyrofa | elopio, it's parsing the in-tree yaml | 18:36 |
| ogra_ | yeah | 18:36 |
| ogra_ | there is no tree | 18:36 |
| ogra_ | its a binary snap ... the tree is long gone (an didnt exist on a machine that has outside world access) | 18:37 |
| kyrofa | ogra_, yeah snapcraft's upload is pretty tied into the build steps (e.g. if the snap doesn't exist it'll try to build it, etc) | 18:37 |
| ogra_ | but you can upload an existing snap ? | 18:37 |
| elopio | kyrofa: but if the snap exists, it will just upload it. I think. | 18:37 |
| elopio | if not, I can write the code for that. | 18:38 |
| ogra_ | (worst case we could loop/bind mount the snap and extract the snap.yaml from it though) | 18:38 |
| ogra_ | (assuming jenkins can mount stuff) | 18:38 |
| kyrofa | elopio, indeed, but it has to be named correctly (and it still needs the in-tree yaml). If we bind-mounted it and parsed the in-snap yaml, we could add a parameter for uploading any old snap | 18:38 |
| sergiusens | elopio, kyrofa here's a reading one in the meantime https://github.com/ubuntu-core/snapcraft/pull/409 | 18:38 |
| ogra_ | the naming wouldnt be the prob ... but the version would | 18:39 |
| ogra_ | so one way or the other we need to extract the snap.yaml | 18:39 |
| ogra_ | to get that info | 18:39 |
| elopio | the version is not important. The store assigns an increasing revision for each new version. | 18:39 |
| ogra_ | the version is part of the name | 18:40 |
| ogra_ | so to have the file named correcly you need to know the version that was used in the snap.yaml afaik | 18:40 |
| sergiusens | ogra_, unsquashfs -l | 18:41 |
| ogra_ | yeah, or loop mounting | 18:41 |
| sergiusens | `unsquashfs squashfs-root/meta/snap.yaml` to only get yaml | 18:42 |
| elopio | well, bottom line is that on jenkins can do anything. I will make a first version with the least ugly thing. | 18:42 |
| elopio | I think it would be nice for snapcraft upload to take an optional .snap argument. | 18:43 |
| elopio | and if there's no tree, unsquash. | 18:43 |
| ogra_ | yeah, especially since you only need the snap.yaml after all | 18:43 |
| kyrofa | elopio, agreed, and if we get the code to get the yaml out of the snap, don't use the in-tree yaml (since it could theoretically change) | 18:45 |
| ogra_ | sergiusens, btw, it would b nice if you could name your announcements a bit more careful in the future :) | 18:46 |
| ogra_ | "- support for building the os snap (from a directory)." | 18:46 |
| * ogra_ waits for all these people that create random busybox rootfses and throw them into the store now | 18:46 | |
| ogra_ | (and file tons of bugs because snappy doesnt work :P ) | 18:47 |
| ogra_ | s/name/phrase/ | 18:50 |
| plars | ogra_: so the dragonboard is known to be broken now? | 18:50 |
| sergiusens | kyrofa, I created a PR for easier review; added one comment | 18:50 |
| ogra_ | plars, mine works ... why do you think that ? | 18:50 |
| sergiusens | ogra_, oh; what happened? | 18:51 |
| plars | ogra_: won't boot for me - elopio said it was broken for him when he tried it last too | 18:51 |
| plars | ogra_: https://www.irccloud.com/pastebin/ptzM39TI/ | 18:51 |
| ogra_ | sergiusens, nothing, but "- support for building the os snap (from a directory)." soinds liek we are encouragin these rootstock users to roll their own rootfses | 18:51 |
| ogra_ | plars, using the right kernel ? | 18:52 |
| ogra_ | canonical-snapdragon-linux is the one you want | 18:52 |
| sergiusens | ogra_, oh, we allow that apparently; but it will never make it into the store ;-) | 18:52 |
| ogra_ | (we sadly cant delete old packages fromthe store) | 18:52 |
| sergiusens | ogra_, ask beuno to do it for you | 18:52 |
| plars | ogra_: I'm using core rolling --kernel=canonical-dragon-linux.canonical --gadget=canonical-dragon.canonical --os=ubuntu-core.canonical --developer-mode --channel edge | 18:53 |
| ogra_ | plars, yeah, thats the old kernel .. i told elopio last week that he needs to use the new one ;) | 18:53 |
| plars | ogra_: ah, ok what's the new magic? :) | 18:53 |
| ogra_ | i guess that drowned in a lot of other conversation about the new snaps | 18:53 |
| ogra_ | canonical-snapdragon-linux.canonical | 18:53 |
| plars | ogra_: I'll give it a try, thanks! | 18:54 |
| ogra_ | as kernel | 18:54 |
| elopio | we have to update zyga's script. | 18:54 |
| ogra_ | or yu can just grab the snaps from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ | 18:54 |
| ogra_ | (though the naming isnt matching) | 18:54 |
| elopio | ogra_: is the gadget still canonical-dragon.canonical? | 18:56 |
| ogra_ | yeah, that didnt change | 18:56 |
| ogra_ | someone uploaded a 4.4 package for canonical-dragon-linux though, i wonder where that comes from | 18:56 |
| elopio | https://github.com/zyga/devtools/pull/1 | 18:56 |
| * ogra_ really hates that we are all using the same account for uploading ... no way to figure out wwho did that upload now | 18:57 | |
| ogra_ | anyway, off to the TV to watch germany lose vs italy | 18:58 |
| sergiusens | kyrofa, replied to all the comments; wrt stage-pkg you said tests were in order? | 19:04 |
| sergiusens | or is that not really needed | 19:05 |
| sergiusens | ? | 19:05 |
| sergiusens | ogra_, I've been complaining about the account issue for a while; but to be fair, we have the same problem with cdimage ;-) | 19:05 |
| kyrofa | sergiusens, it's less magical now, I actually don't think the integration test is needed | 19:06 |
| ogra_ | sergiusens, well, depends if you use cdimage the right way (for code changes there ar proper trees that keep your name) | 19:06 |
| ogra_ | but yeah, it is hard to tell who tiggered an image build | 19:07 |
| sergiusens | ogra_, true; so I bet whoever updated the gadget snap in the store did not update the bzr branch? | 19:07 |
| ogra_ | sergiusens, which gadget snap ? | 19:07 |
| sergiusens | ogra_, the dragonboard one, but now I see you mention a kernel snap ;-) | 19:08 |
| ogra_ | (pi2 might by my fault, i'm holding back the branch til ppisati and i found out whats the issue with the console) | 19:08 |
| ogra_ | yeah, dragonboard gadget hasnt changed in a while | 19:08 |
| ogra_ | i'll do a final upload before 16.04 (with a final checkout of the dragon uboot tree) ... but didnt plan to touch it til then | 19:09 |
| ogra_ | yay ... goal | 19:09 |
| elopio | ogra_: change the credentials, and start sharing the snap. | 19:09 |
| elopio | yay! | 19:09 |
| ogra_ | elopio, and it will then still be a .canonical one ? | 19:10 |
| elopio | ogra_: that's what I understood. | 19:10 |
| ogra_ | oh, neat ! | 19:11 |
| * ogra_ will look at that toorrow | 19:11 | |
| elopio | I will give it a try, because now I'm not so sure it's not only for installing. | 19:12 |
| elopio | sergiusens: kyrofa: do you want to keep that comment by coveralls, or should I disable it? | 19:12 |
| kyrofa | elopio, yeah it doesn't add much since we can see it in the checks | 19:20 |
| kyrofa | sergiusens, done on the should_step_run refactor | 19:22 |
| sergiusens | kyrofa, \o/ | 19:28 |
| sergiusens | elopio, kyrofa I don't mind the email telling me everything is good though; but I won't miss it if it is gone either | 19:29 |
| joc_ | sergiusens: i'd like to ask you about some snapcraft behaviour i've noticed recently when testing the plugin i'm trying to land for plainbox | 19:32 |
| sergiusens | kyrofa, you inspired me to a small refactor (but different branch) | 19:33 |
| kyrofa | sergiusens, hahaha | 19:33 |
| joc_ | sergiusens: i've noticed that if my part has some stage-packages the sys.path in which my manage.py script is run is different | 19:33 |
| joc_ | sergiusens: if there are stage-packages defined sys.path seems to search for modules in parts/part-name/install/.. | 19:35 |
| joc_ | otherwise the sys.path is looking in locations in stage/.. | 19:35 |
| joc_ | sergiusens: whats the reason for this? | 19:36 |
| sergiusens | joc_, I'd have to look, maybe kyrofa know right off the bat | 19:42 |
| sergiusens | a small snapcraft.yaml would be easier to follow | 19:43 |
| joc_ | ok, will try and come up with something | 19:44 |
| kyrofa | joc_, only the python plugins touch the PYTHONPATH | 19:50 |
| joc_ | kyrofa: none of the parts in my yaml are using python plugins | 19:51 |
| joc_ | kyrofa: just this plugin https://github.com/jocave/snapcraft/blob/plainbox-provider-plugin/snapcraft/plugins/plainbox_provider.py | 19:52 |
| joc_ | kyrofa: i have been printing sys.path in manage.py (called in build function) to debug some failures of that script | 19:53 |
| joc_ | it seems to change depending on presence of stage-packages on the part | 19:54 |
| attente | hi, could someone explain to me the difference between /usr/bin/snap and /usr/bin/snappy? | 20:09 |
| pedronis | attente: /usr/bin/snap will be the main command in 16.04, /usr/bin/snappy is going away but the move isn't quite complete, they have somewhat different syntax for some things, and snap does most things through the snappy daemon (snapd), while snappy was doing them directly | 20:22 |
| attente | pedronis: great, thanks for the clear explanation | 20:23 |
| sergiusens | elopio, mind testing this on armhf now https://github.com/ubuntu-core/snapcraft/pull/335 ? | 20:24 |
| sergiusens | joc_, kyrofa it changes becase if you add stage-packages that have a hint of python in it, it will be the prefered interpreter | 20:25 |
| kyrofa | sergiusens, how? | 20:26 |
| sergiusens | the one that ends up in `stage` (or soon in `install` for the part if in the same part) | 20:26 |
| sergiusens | kyrofa, say you use this plugin https://github.com/jocave/snapcraft/blob/plainbox-provider-plugin/snapcraft/plugins/plainbox_provider.py | 20:26 |
| sergiusens | kyrofa, no stage-packages at all; that plugin will use the system plugin just fine | 20:27 |
| sergiusens | kyrofa, now add a stage-package that depends on python3 you end up getting `stage/usr/bin/python3` | 20:27 |
| sergiusens | kyrofa, I guess sys.path is dynamically set | 20:28 |
| kyrofa | sergiusens, but what part of the code changes... ah | 20:28 |
| kyrofa | sergiusens, because I didn't see anything in snapcraft itself that changes sys.path or PYTHONPATH to look in the stage directory | 20:28 |
| sergiusens | kyrofa, we change sys.path iirc but to run from source | 20:29 |
| kyrofa | sergiusens, indeed | 20:29 |
| kyrofa | sergiusens, and to find local plugins. That's it | 20:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!