| liuxg | elopio, ping | 03:03 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| zyga | good morning | 08:40 |
| LefterisJP | morning | 08:56 |
| NoiZeR | morning | 09:20 |
| JamesTait | Good morning all! Happy Tuesday, and happy Australia Day! 😃 | 09:37 |
| mvo | kgunn: hey, if I can help with updating your mir snap, please do let me know | 11:02 |
| asac | mvo: do i name the vmlinuz just like that in a snap or shall i append the -KERNELVERSION? | 11:53 |
| asac | same for system.map etcv. | 11:53 |
| mvo | asac: sorry, I disconnected, it has to be named vmlinux and initird.img for now, but that is a bug | 12:07 |
| diwic | I've defined a git URL in "parts: pulseaudio: source:", but when I run "snapcraft pull", it does not seem to download anything. Help? (I'm using 16.04 version of snapcraft.) | 12:09 |
| asac | mvo: vmlinux or vmlinuz? | 12:14 |
| mvo | asac: vmlinuz | 12:15 |
| mvo | asac: sorry | 12:15 |
| asac | mvo: can you look into this one: https://people.canonical.com/~asac/kernel-snap-example_0_amd64.snap | 12:23 |
| asac | and tell me beyond not appending the version is missing? | 12:23 |
| asac | (ignore the odd initrd name) | 12:23 |
| mvo | asac: sure, I check after lunch | 12:24 |
| diwic | found it | 12:30 |
| mvo | asac: from a quick look it looks great, I can give it a test in a vm next. you can use symlinks for the vmlinuz, its just needed right now so that grub can find it | 12:56 |
| === chihchun is now known as chihchun_afk | ||
| dholbach | kyrofa: thanks for the reviews | 13:35 |
| dholbach | (https://github.com/ubuntu-core/snapcraft/pull/256 has the fix you were asking for) | 13:36 |
| kyrofa | dholbach, thanks for the fixes :) | 13:37 |
| kyrofa | dholbach, for what it's worth, snappy logs <package name>.<service name> doesn't seem to work for me on 15.04. Is that a 16.04 thing? | 13:39 |
| dholbach | https://github.com/ubuntu-core/snapcraft/pull/242 is updated now too | 13:39 |
| dholbach | kyrofa: this was part of the 15.04 appdev manual - let me check | 13:39 |
| kyrofa | dholbach, yeah sanity check me there. I may be being stupid | 13:40 |
| kyrofa | dholbach, https://github.com/ubuntu-core/snapcraft/pull/261 is a good-looking doc, though I wonder if it actually belongs in snappy instead of snapcraft. Thoughts? | 13:45 |
| dholbach | kyrofa: what works for me in rolling/edge is: sudo snappy service logs shout (for shout.sergiusens) | 13:45 |
| dholbach | let me check for 15.04 | 13:46 |
| kyrofa | dholbach, ah indeed-- but no .servicename eh? | 13:46 |
| kyrofa | dholbach, that works on 15.04 as well | 13:46 |
| dholbach | kyrofa: I thought about it too, but thought that if we split up our docs into "what's interesting for app developers?" and "what's general/structural information?" and "what does a device builder need to know?" ... I feel it belongs in the app context | 13:47 |
| dholbach | kyrofa: yep - looks like it... ok, let me fix that | 13:47 |
| kyrofa | dholbach, good deal, you're the pro there | 13:47 |
| dholbach | kyrofa: but if we were to move the doc I guess that'd be fine with me too | 13:47 |
| dholbach | it's just how I tried to explain the situation to myself ;-) | 13:47 |
| kyrofa | dholbach, heh, I really just want what is most clear to developers. And you're right-- they're probably using snapcraft to make the .snap, so why not have general .snap development guides there? | 13:48 |
| kyrofa | dholbach, of course, once you have the syncing all done to developer.ubuntu.com, it matters less | 13:48 |
| dholbach | if we want, we can still go and split it up or move it elsewhere - I'm happy to do that if we have concensus | 13:48 |
| kyrofa | dholbach, no I'm happy with that :) | 13:49 |
| dholbach | cool | 13:49 |
| diwic | awe_, so I was wondering about the autotools plugin - two questions: | 13:50 |
| kyrofa | dholbach, snappy-debug has been around for a while now. Any idea when it'll actually include gdb, strace, ltrace, etc.? | 13:50 |
| dholbach | jdstrand: ^ do you know if this coming soon or who might be working on it? | 13:51 |
| diwic | awe_, 1) I have build headers installed on my local development machines, but not all dev headers are (yet) in "stage-packages". | 13:51 |
| diwic | awe_, this seems to have the surprising result that ./configure detects them but gcc does not? | 13:52 |
| awe_ | hmmm, that sounds odd; probably something wrong in your Makefile.in | 13:52 |
| kyrofa | diwic, dev headers don't need to be in stage-packages | 13:52 |
| diwic | kyrofa, where should they be, then? | 13:53 |
| awe_ | kyrofa, build-packages instead? | 13:53 |
| kyrofa | awe_, indeed. diwic snapcraft will use your system-installed packages for building, but you need to make sure stage-packages sets it up for run-time | 13:53 |
| awe_ | kyrofa, nobody's ever truly explained the diff between the two. I use build-packages for build tools ( eg. pkg-config ) and stage-packages for dev-headers | 13:53 |
| awe_ | and I also build in a lxc container | 13:54 |
| awe_ | that I can reset to it's initial state | 13:54 |
| awe_ | so that I know my dependencies are correct | 13:54 |
| dholbach | kyrofa: thanks for the reviews - I'll check if there's any other new content to add to snapcraft :-) | 13:54 |
| kyrofa | diwic, so put mylib-dev in build-packages, and mylib in stage-packages | 13:54 |
| diwic | kyrofa, ok | 13:55 |
| kyrofa | dholbach, I'm loving the docs! | 13:55 |
| kyrofa | diwic, build-packages install on the host (and don't go into the .snap), stage-packages go into the .snap | 13:55 |
| awe_ | kyrofa, but if you put -dev in stage-packages, it automatically pulls in the lib, and then you can just not snap the dev headers | 13:55 |
| diwic | 2) whenever you add or remove anything in stage- or build-packages, you have to manually remove parts/pulseaudio/state for the changes to take effect. Is this expected? | 13:55 |
| awe_ | stage-packages only go in the snap if you tell them to... | 13:56 |
| awe_ | diwic, did you try using snapcraft clean? | 13:56 |
| kyrofa | awe_, hmm... stage-packages go into the snap unless you filter them out somehow with the stage/snap keywords | 13:56 |
| awe_ | instead? | 13:56 |
| awe_ | kyrofa, which I'm currently doing... | 13:56 |
| awe_ | so I guess it's a style thing | 13:57 |
| kyrofa | awe_, I suppose :P | 13:57 |
| awe_ | but your approach makes sense | 13:57 |
| diwic | awe_, *testing* hmm, that works too, but that re-clones the git repo too | 13:58 |
| awe_ | I'm not sure if there's a way to clean the build w/out clobbering the source(s) | 13:58 |
| awe_ | seems like you figured out a way to cheat by manually removing the file | 13:59 |
| diwic | I mean, there is code to check if there's a git repo and if so update it (rather than wipe and clone), when is that code supposed to be run? | 14:00 |
| awe_ | diwic, I'm not sure... you could check the snapcraft source directly; it's all-python | 14:01 |
| diwic | awe_, already hacked it ;-) | 14:01 |
| awe_ | ;D | 14:01 |
| diwic | awe_, the git server I'm working against (just as a test) didn't support --depth=1 so I had to remove that | 14:02 |
| kyrofa | diwic, I've never heard of that. What software is running on the server? | 14:02 |
| diwic | kyrofa, no idea - git://anonscm.debian.org/pkg-pulseaudio/pulseaudio.git is the URL I'm currently testing with | 14:05 |
| diwic | (again - might change that to something else later, this is just to get started) | 14:05 |
| jdstrand | dholbach: I don't, no. mvo may have more info | 14:07 |
| dholbach | mvo: ^ kyrofa asked earlier: snappy-debug has been around for a while now. Any idea when it'll actually include gdb, strace, ltrace, etc.? | 14:07 |
| dholbach | thanks jdstrand | 14:07 |
| diwic | awe_, 3) I was also wondering about https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/autotools.py#L85 - it ends with '--prefix=', looks weird | 14:09 |
| diwic | awe_, what is the prefix set to and how? | 14:09 |
| kyrofa | diwic, huh, looks like other people have hit that as well, and no one seems to know why. Perhaps you should use a snapshot .tar.gz from gitweb | 14:09 |
| kyrofa | diwic, https://anonscm.debian.org/gitweb/?p=pkg-pulseaudio/pulseaudio.git | 14:10 |
| awe_ | diwic, I guess it depends on how self.options.configflags is initialized | 14:11 |
| awe_ | I'll check when I do my next build | 14:11 |
| awe_ | I'm in the middle of a change right now | 14:11 |
| diwic | sure | 14:11 |
| awe_ | that said, my builds were working fine last night | 14:11 |
| kyrofa | diwic, --prefix= means "no prefix". You can still set the prefix in the configflags though | 14:12 |
| diwic | kyrofa, ok | 14:12 |
| kyrofa | diwic, autotools takes the last one | 14:13 |
| awe_ | guess that explain that; thanks kyrofa | 14:13 |
| kyrofa | awe_, hey, any time :) | 14:14 |
| diwic | kyrofa, anyhow, so now I need to add --disable-A, --disable-B, --disable-C etc in configflags in order for it to skip that dependency (otherwise it'll find it as it is installed on the system) | 14:14 |
| awe_ | are you asking how to do this? | 14:15 |
| awe_ | configflags: | 14:15 |
| kyrofa | diwic, yeah, should be easy with configflags | 14:16 |
| diwic | awe_, I'm asking whether this is actually the desired behaviour? It seems less error prone if the part being built did *not* find system-installed headers | 14:16 |
| awe_ | http://pastebin.ubuntu.com/14671891/ | 14:16 |
| diwic | awe_, and it seems even stranger that configure finds them but not gcc | 14:17 |
| awe_ | well.. you are running configure right? | 14:17 |
| awe_ | again, that's probably because the Makefile.in is wrong | 14:17 |
| awe_ | gcc only finds what you tell it | 14:17 |
| diwic | awe_, you have to excuse me for thinking the problem is snappy rather than Makefile.in | 14:18 |
| awe_ | diwic, it's new, and it's changing rapidly. It *might* be a snapcraft thing, but off the top of my head, it sounds more like a Makefile.in thing | 14:18 |
| diwic | awe_, based on the fact that snappy is very new and Makefile.in/pulseaudio is several years old, builds on many architectures and autogenerated by autotools | 14:19 |
| awe_ | sure, but you'll need to dig in and see what's really happening | 14:19 |
| diwic | awe_, yeah | 14:19 |
| awe_ | if it is a snapcraft bug, then please report it! ;)- | 14:19 |
| awe_ | I noticed yesterday that snapcraft --help seems to be broken in 2.0 | 14:19 |
| * awe_ needs to check if that's already been filed | 14:20 | |
| kyrofa | awe_ can you define "broken"? | 14:20 |
| awe_ | it generates a stacktrace | 14:21 |
| kyrofa | awe_, *cough* sound broken | 14:21 |
| awe_ | http://pastebin.ubuntu.com/14671916/ | 14:21 |
| kyrofa | Ah, wait I think I read about that on the mailing list. Due to a lack of locale setting or something | 14:22 |
| kyrofa | Definitely a bug that it's not handled in snapcraft, but you can work around it by setting your locale | 14:23 |
| kyrofa | awe_, ^^ | 14:23 |
| awe_ | kyrofa, thanks. It's more of annoyance than anything else | 14:24 |
| awe_ | but I'll give that a try | 14:24 |
| awe_ | if/when I next need to refer to the help | 14:24 |
| awe_ | been grokin' the source instead | 14:24 |
| kyrofa | awe_ are you running out of master? Or using 2.0.1 on xenial? | 14:25 |
| awe_ | the latter | 14:25 |
| dholbach | kyrofa: I bet it's the “ and ” in the help text | 14:28 |
| awe_ | kyrofa, is it possible to add a multi-line description in snapcraft.yaml? This seems to cause grief whenever I try to do so | 14:28 |
| dholbach | changing them to " should probably make it work | 14:28 |
| kyrofa | awe_ indeed, use YAML-foo! | 14:29 |
| kyrofa | dholbach, brilliant! I'm trying to figure out how to UNset my locale to test :P | 14:29 |
| awe_ | ? | 14:29 |
| kyrofa | awe_, heh, hold on | 14:29 |
| kyrofa | awe_ https://stackoverflow.com/questions/3790454/in-yaml-how-do-i-break-a-string-over-multiple-lines | 14:29 |
| kyrofa | awe_ does that help? | 14:29 |
| kyrofa | awe_ it's just YAML, so anything YAML supports, snapcraft supports | 14:30 |
| kgunn | so i just moved to snapcraft 2.0 | 14:30 |
| awe_ | yes, of course it appears there are nine different ways to do it! groan | 14:30 |
| awe_ | welcome to the party kgunn! | 14:30 |
| kgunn | i used to be able to muck with my snap (fka apps) files | 14:30 |
| kyrofa | awe_ hahaha | 14:30 |
| kgunn | but now i can't | 14:30 |
| * kgunn looks for disco ball | 14:30 | |
| kgunn | anyone know of a trick ? | 14:31 |
| kyrofa | kgunn, I don't quite understand | 14:31 |
| kyrofa | kgunn, can you define "muck"? :P | 14:31 |
| kgunn | kyrofa: so i have a script a-la /snaps/app.sideload/bin/dostuff | 14:31 |
| kgunn | i used to just stop my service | 14:31 |
| kgunn | tweak it | 14:31 |
| kgunn | but...it just refuses to become writable | 14:32 |
| awe_ | ah | 14:32 |
| awe_ | probably the change in file format of the snaps | 14:32 |
| kyrofa | kgunn, yeah squashfs | 14:32 |
| kgunn | yeah figure | 14:32 |
| kgunn | but is there a trick to circumvent | 14:32 |
| awe_ | yea, but you need some squashfs foo, to be able to do so.. I looked at this yesterday, and decided it wasn't worth the trouble | 14:33 |
| kgunn | lol | 14:33 |
| kyrofa | kgunn, hmm.... not that I know of I'm afraid | 14:33 |
| awe_ | if you figure it out, please share the wealth | 14:33 |
| kgunn | sure :) | 14:34 |
| kyrofa | kgunn, I see guides for layering unionfs on top of squashfs to add write capabilities, which to me means squashfs just doesn't support writing | 14:34 |
| kgunn | ack | 14:35 |
| kyrofa | elopio, agh, sorry I'm late, got distracted | 14:35 |
| mvo | dholbach: no really good idea at this point, hopefully soon when the store lands support for per-architecture snap | 14:39 |
| awe_ | kyrofa, seems on the "flow" style line wrapping methods are supported which strip any embedded new lines... | 14:39 |
| mvo | dholbach: snaps | 14:39 |
| mvo | dholbach: right now it would have to be a pretty big snap that is a bit tricky to build | 14:39 |
| elopio | fgimenez: ping. Could you ssh? | 14:45 |
| dholbach | kyrofa: ^ see what mvo said? | 14:58 |
| kyrofa | dholbach, yeah, good info. I'm a little worried a developer might miss the "snappy-debug only includes security right now" note and wonder why he can't use strace after reading the docs | 15:00 |
| kyrofa | dholbach, what do you think? | 15:01 |
| asac | mvo: is there the notion of a type: in snap.yamnl still? | 15:03 |
| asac | e.g. should snapcraft learn about type: kernel? etc.? | 15:04 |
| mvo | asac: yes | 15:04 |
| asac | mvo: did you take a look at the .sanp? i uploaded a new one | 15:05 |
| dholbach | kyrofa: ok, let me change it a little bit | 15:06 |
| asac | kyrofa: does snapcraft already allow me to use type: kernel ? e.g. in the yaml? | 15:06 |
| asac | ../../bin/snapcraft clean | 15:07 |
| asac | Issues while validating snapcraft.yaml: 'kernel' is not one of ['app'] | 15:07 |
| asac | ok seems not | 15:07 |
| mvo | asac: should I test it? | 15:07 |
| * asac checks and adds | 15:07 | |
| asac | mvo: well, the initrd has modules only | 15:07 |
| asac | beyond that is there anything missing compared from what you added? | 15:07 |
| mvo | asac: I think its fine, won't work right now because we don't have the generic-initrd yet, but that is something someone needs to work on soon | 15:08 |
| kyrofa | asac, yeah I don't think so yet | 15:09 |
| asac | mvo: lool is experimenting with how to concat those initrd | 15:09 |
| asac | in the bootloaders | 15:09 |
| asac | kyrofa: ok... i will incolude that in my mammoth patchset :) | 15:10 |
| asac | was just a scheme patch | 15:10 |
| mvo | asac: cool | 15:10 |
| mvo | asac: accoridng to apw its really just "cat initird1 initird2> initrd.img" and the kernel will DTRT | 15:10 |
| asac | lool: will you work on getting an indep initrd into OS snap from our builders? | 15:11 |
| asac | yeah | 15:11 |
| asac | but we prefer to not concat on disk | 15:11 |
| asac | but rather from bootloader | 15:11 |
| asac | e.g. have them load both files and just boot | 15:11 |
| mvo | asac: if the boorloader supports it | 15:11 |
| asac | thats what lool is testing now | 15:11 |
| mvo | asac: I think for grub thats fine and we can do that | 15:11 |
| asac | e.g. grub + u-boot | 15:11 |
| asac | think both could work | 15:11 |
| dholbach | kyrofa: updated - let me know if it's cleare now :) | 15:11 |
| lool | (I'm installing the test machine ATM) | 15:12 |
| asac | cool | 15:12 |
| mvo | asac: but uboot seems to not support it, but that is ok because for uboot we need to extract the kernel and initird anyway so we might as well do more magic | 15:12 |
| apw | they need to be next ot each other in memory and the right bracketing start,length passed to the kernel | 15:12 |
| asac | uboot allows to load to raw mem position | 15:12 |
| mvo | asac: trouble if of course rollback, once we combine them on disk everything becomes harder | 15:12 |
| asac | so trick is to just load the two files neck to neck | 15:12 |
| kyrofa | dholbach, ah, yeah that works :) | 15:12 |
| asac | yeah | 15:12 |
| mvo | asac: yeah, uboot is flexible enough for that | 15:12 |
| lool | apw: is there an easy well to tell grub / u-boot to do this, or do we need to write all the tiny scripting logic to compute the addresses and kernel args? | 15:12 |
| asac | uboot needs to have special boot partition anyway right? | 15:12 |
| asac | or can we read squshfs etc. there? | 15:13 |
| lool | no we cant | 15:13 |
| mvo | asac: it has special handling | 15:13 |
| lool | albeit there are patches to run grub-efi as a payload to u-boot now | 15:13 |
| asac | right. so arm still needs to gert files put into special place | 15:13 |
| apw | lool, can't say as i have ever looked at it, typically initrds are single things loaded and that sets the kernel data at the same time | 15:13 |
| asac | we can as well concat them when doing that | 15:13 |
| asac | but having them cleanly separate is surely better | 15:13 |
| asac | guess also for trusted boot etc. | 15:13 |
| asac | lool: grub allows just list of files for initrd | 15:14 |
| asac | i found on some blog | 15:14 |
| lool | apw: IIUC, the concatenation only works for init ramdisks, not initramfses; is there a big difference between the two we shoudl be worried about? | 15:14 |
| asac | so just initrd list of files | 15:14 |
| lool | asac: ah cool | 15:14 |
| asac | uboot you have to somewaht load first, then parse the end address | 15:14 |
| asac | and load second to that | 15:15 |
| apw | lool, it only works for the initramfs format ones, ie the cpio.gz style ones, those can be concantenated and the kernel will unpakc them all into the kernel root ramdisk before entering it | 15:15 |
| lool | apw: and are all kernel compression types supported, or only gz? | 15:16 |
| lool | is it ok if we do gz? | 15:16 |
| apw | lool, i believe its all of the initrd compression types which are enabled in your kernel config | 15:16 |
| asac | lool: http://savannah.gnu.org/bugs/?35238 | 15:18 |
| asac | not sure how it was fixed | 15:18 |
| asac | but seems it got fixed | 15:18 |
| Sweet5hark | trying to setup a vagrant snappy image results in ssh timeout failure on "vagrant up" ... | 15:20 |
| asac | apw: is it very dirty (or even breaks) to ship the full modules.dep if i only have a subset of the modules (e.g. ship the full in the initrd)? | 15:20 |
| apw | asac, it is just a dependancy list, so i would expect that to be non-fatally "wrong" | 15:22 |
| qengho | Are there xenial snappy test images for download? I can't find any. | 15:22 |
| asac | ok here status quo ... https://github.com/asac/snapcraft/commits/kbuild-kernel-wip for those taht want to produce not-yet-booting kernel snaps | 15:22 |
| apw | asac, though if the device dependant parts contain nonoverlapping subsets it is not clear how you can make a correct one in the generic bit anyhow, as it does not list the non-gneeric bits | 15:22 |
| asac | https://github.com/asac/snapcraft/blob/kbuild-kernel-wip/examples/kernel/snapcraft.yaml | 15:22 |
| apw | asac, or indeed visa-versa | 15:23 |
| asac | apw: hmm. well its that i managed to filter the right modules out of my local build, just dont want to write code to remake a modules.dep with just that subset | 15:23 |
| asac | e.g. i am using it from the right tree (not the generic one) | 15:23 |
| asac | (if i understood your comment correctly) | 15:23 |
| Sweet5hark | Showing the VM in the VirtualBox UI gives me a something apparently looping a kernel boot again and again. any hints? | 15:24 |
| asac | utlemming: ^^ | 15:25 |
| asac | Sweet5hark: utlemming is vagrant/vbox expert... not sure if he is around today though | 15:25 |
| NoiZeR | hello, im busy with compiling Boost on Ubuntu 14.04 LTS but does i need to compile it before i make a snap of it? | 15:25 |
| utlemming | Sweet5hark: I've seen that once before and it was the CPU. | 15:26 |
| utlemming | Sweet5hark: can you capture what happens immediately before reboot? | 15:26 |
| NoiZeR | Or can i just install boost itself on snappy? | 15:29 |
| Sweet5hark | utlemming: any hints on what to press to prevent the box from rebooting right away? | 15:30 |
| asac | NoiZeR: you can use snapcraft to pull the binaries from archive | 15:31 |
| asac | into your snaop | 15:31 |
| NoiZeR | ok do you know where the binaries are? | 15:35 |
| NoiZeR | asac see above | 15:36 |
| kyrofa | elopio, would you mind taking a look at https://github.com/ubuntu-core/snapcraft/pull/210 when you have a chance? I want one more pair of eyes | 15:36 |
| asac | NoiZeR: dont know if i understand your question | 15:37 |
| asac | do you know the ubuntu packages you want? | 15:37 |
| asac | i would suggest to start with making a xenial chroot, and then use apt-cache search and apt-get isntall to find what you need | 15:37 |
| asac | once you have the packages you can use stage-packages: field in snapcraft.yaml to ensure those get put into your snap | 15:38 |
| asac | alongside with your app etc. | 15:38 |
| NoiZeR | but i want that as framework because the C++ boost library needs to be available everywhere | 15:39 |
| NoiZeR | asac | 15:40 |
| NoiZeR | ps im a total noob on Snappy just started | 15:41 |
| asac | NoiZeR: if you dont need have one runtime instance (e.g. a mediating service/agent) then dont feel bad about folks including copies in their snaps for now | 15:43 |
| asac | make it easy to include it through having a snapcraft part etc. | 15:44 |
| kyrofa | elopio, travis has been failing left and right yesterday and today | 15:54 |
| kyrofa | elopio, hahaha, what is the standard on the copyrights? sergio told him to just make it 2016, I would have made it 2015-2016, and you said 2015, 2016 | 15:59 |
| elopio | kyrofa: you have to put every year the file was touched. And according to the fsf, if you use the - you have to documment that usage. | 15:59 |
| elopio | so I prefer to use the , | 16:00 |
| elopio | but of course, nobody pays attention to fsf and this is just a nit. | 16:00 |
| kyrofa | elopio, ah, excellent. I'll remember it! | 16:00 |
| asac | two years use a , ... more years use a - | 16:01 |
| asac | my 2c | 16:01 |
| elopio | asac: https://www.gnu.org/licenses/gpl-howto.html | 16:02 |
| kyrofa | elopio, for your admiration: http://pasteboard.co/15kdW9WN.jpg | 16:02 |
| elopio | sixth paragraph | 16:02 |
| elopio | kyrofa: wow. | 16:03 |
| kyrofa | elopio, I don't need to work out for a week after that job | 16:04 |
| elopio | here we have cozy 23 degrees C, with no clouds in the sky. | 16:04 |
| elopio | kyrofa: did you do it all the way to the car? | 16:05 |
| kyrofa | elopio, yeah | 16:06 |
| elopio | I'm impressed. | 16:06 |
| tedg | kyrofa: http://www.bbc.com/news/blogs-magazine-monitor-30119410 | 16:12 |
| tedg | kyrofa: I'm not saying living someplace with snow can kill you, the BBC is :-) | 16:12 |
| kyrofa | tedg, haha | 16:13 |
| mvo | JamesTait: hi, do you still need a meta/snap.yaml example snap? | 16:25 |
| JamesTait | mvo, I believe I have one (shout.seriusens), thank you. | 16:26 |
| * JamesTait can't type for toffee today. | 16:26 | |
| JamesTait | And I've now got the documentation for the internal snappy format, so I *think* that's everything I need to get started. But I'll shout up if I find I'm missing anything. | 16:28 |
| mvo | JamesTait: cool, http://people.canonical.com/~mvo/tmp/hello-world_3.0_all.snap is also one | 16:28 |
| * JamesTait hugs mvo. | 16:28 | |
| JamesTait | Thank you very much - having a couple of package to test with will be a great help. | 16:29 |
| mvo | JamesTait: I think for you and the metadata you need its almost identical to package.yaml, name, version are the same, vendor is no more, description comes from yaml instead of readme.md | 16:29 |
| mvo | JamesTait: your welcome, shout if you need anything :) | 16:29 |
| kyrofa | Well hey there sergiusens. I figured you'd be sleeping most of today | 16:42 |
| asac | sergiusens: kyrofa: https://github.com/ubuntu-core/snapcraft/pull/257 is green now :) | 16:43 |
| sergiusens | asac, bloody timing, I added some review comments :-P | 16:50 |
| lool | asac: sorry took me a while to confirm, but it works | 16:51 |
| fgimenez | elopio, disk space seems to be ok in the last server deployed http://paste.ubuntu.com/14672859/ | 16:51 |
| lool | asac: I cpio -i extracted snappy initrd, then split it into two dirs (moved lib/modules to a different one) then repacked | 16:51 |
| lool | asac: one key thing to pay attention to is that xz compression doesn't work but lzma does | 16:52 |
| sergiusens | kyrofa, I am super tired, but I also flew business (with a proper bed) so its not that bad | 16:52 |
| lool | it's very similar but not identical | 16:52 |
| lool | so just use "lzma" to compress | 16:52 |
| elopio | fgimenez: great. | 16:52 |
| lool | asac: I added break=top to cmdline to confirm that the initrd was fully populated, and then I completed a successful boot too | 16:52 |
| kyrofa | sergiusens, well take it easy today :) | 16:52 |
| lool | asac: next step is making sure our OS snap includes a generic initrd | 16:53 |
| asac | lool: you know the magic cli arguments for xz initrd packgin? | 16:53 |
| asac | just in case | 16:53 |
| asac | lool: so you could load two files from bootloader? | 16:53 |
| asac | and it was just one disk merged? | 16:53 |
| lool | asac: find . | cpio -c -H newc | 16:53 |
| lool | then lzma the result | 16:53 |
| lool | (you can pipe it directly too) | 16:54 |
| lool | probably better compression not to though | 16:54 |
| lool | asac: I used the initrd part1.img part2.img syntax you mentioned | 16:55 |
| lool | worked fine | 16:55 |
| lool | didn't try with u-boot, probably need to compute offsets myself there | 16:55 |
| lool | which wont be fun | 16:55 |
| lool | there also seems to be some alignment constraints | 16:55 |
| lool | apparently you can mix various types of compressions (or no compression) on the grub initrd line; not sure if this is a grub or linux thing though | 16:55 |
| asac | hmm. guess grub might do the uncompressing then? | 16:56 |
| asac | i would say its not good to mix :) | 16:56 |
| lool | it might be linux | 16:56 |
| asac | figuring that compression changes mid file? i doubt it :) | 16:57 |
| asac | but you newver know | 16:57 |
| lool | in fact, it's more likely linux as grub didn't bark at teh xz compression but linux failed to boot | 16:57 |
| lool | as in it panicked | 16:57 |
| fgimenez | elopio, i see that the build jobs are restricted by label in the config https://github.com/ubuntu-core/snappy-jenkins/blob/master/containers/jenkins-master/config/jobs/create-cloud-image-all-snaps/config.xml#L32 | 16:57 |
| asac | yeah | 16:57 |
| asac | lool: so i could only use xz with funnny cli arguments | 16:57 |
| asac | let me find them | 16:57 |
| fgimenez | elopio, but not in the deployed server http://10.55.32.123:8080/job/create-cloud-image-vivid/configure | 16:57 |
| lool | asac: it's not midfile, linux gets the cpio header from the first piece | 16:57 |
| lool | it knows how long the initrd will be | 16:57 |
| asac | lool: xz --check=crc32 --lzma2=dict=512KiB inputfile | 16:57 |
| asac | thats how it works | 16:57 |
| lool | yeah | 16:57 |
| lool | lzma is simpler to type :-) | 16:58 |
| asac | otherwise it always panicked for me not being able to uncompress initrd | 16:58 |
| asac | is it the same? no idea | 16:58 |
| asac | :) | 16:58 |
| lool | lzma is what I used | 16:58 |
| lool | it's lzmo compression anyway | 16:58 |
| asac | rihht, but above also works | 16:58 |
| asac | yeah | 16:58 |
| asac | kind of | 16:58 |
| asac | something is different afaik :) | 16:58 |
| lool | perhaps I should test this on rpi2 | 16:58 |
| asac | not compression, but maybe contgainer | 16:59 |
| asac | yeah do it | 16:59 |
| asac | just two uinitrds and then load it with manual address offset for now | 16:59 |
| lool | albeit if we're not doing squashfs loading there, there's no point in smarts to laod multiple initrds | 16:59 |
| lool | we dont use uinitrd AFAIK | 16:59 |
| asac | well, its good | 16:59 |
| lool | just plain initrds | 16:59 |
| asac | at least no need to add merge logic | 16:59 |
| elopio | fgimenez: that makes no sense. | 16:59 |
| asac | and if they are on disk | 16:59 |
| asac | there migth be stuff with secure boot | 16:59 |
| asac | as we can validate the signatures as they were shipped | 16:59 |
| asac | lool: dunno... uboot needs to load initrd... thought it needs the mkimage header | 17:00 |
| asac | ifg not, then even easier i guess | 17:00 |
| asac | maybe you can even do fatload file1 file2? | 17:00 |
| asac | :) | 17:00 |
| fgimenez | elopio, maybe we are creating the job before any slave with that label is available? that shouldn't be a problem imo... | 17:00 |
| elopio | fgimenez: when that happens, the job config just prints a warning. | 17:01 |
| lool | asac: as I said, it does not | 17:01 |
| asac | lool: anyway, i was hoping for your magic to make the uboot script do rthe right thing :) | 17:01 |
| elopio | but you can still create it. so weird... | 17:01 |
| lool | we dont use the mkimage headers | 17:01 |
| asac | e.g. address calc | 17:01 |
| asac | good | 17:01 |
| asac | but uImage? | 17:01 |
| lool | fatload multiple args is quite certainly incorrect as the initrds need alignment | 17:01 |
| lool | we dont use uimage | 17:02 |
| asac | really? wow :) | 17:02 |
| elopio | fgimenez: maybe canRoam needs to be false. | 17:02 |
| lool | uimage is only required for flash baked u-boot payloads; if built with the right configs, u-boot will happilly start a regular initrd | 17:02 |
| asac | guess that puts u-boot rquirement really high | 17:02 |
| asac | like 2014 crack | 17:02 |
| lool | just one config | 17:02 |
| fgimenez | elopio, the rest of things seem to be in place, once the images and packages are built we are ready to go | 17:02 |
| lool | it's mainly something that we need to make sure the boards enable | 17:02 |
| elopio | I tried manually adding the label, and that value changes | 17:02 |
| asac | right, which is the problem with putting sophisticated requirements on bootloaders :) | 17:03 |
| asac | anyway, lets give it a go | 17:03 |
| elopio | fgimenez: I'll made the change manually, and propose a branch for the next deploy. | 17:03 |
| asac | if you can figure the offset calc in uboot.scr | 17:03 |
| asac | you are my hero :) | 17:03 |
| asac | and we can go directly to making the plat-indep[ initrd in OS snap | 17:03 |
| lool | I wonder whether we'd be better off with using grub-efi on top of u-boot at this point | 17:04 |
| lool | asac: I'll try to repro on snapdragon or on rpi2 tonight, just to make sure there's no arch specific support issue there, then we can see which bootloader path we take | 17:05 |
| fgimenez | elopio, ok, leaving, have a great day | 17:06 |
| asac | lool: i dont know... feels thats even more sophisticated | 17:07 |
| asac | snapdragon has new uboot | 17:07 |
| asac | try something with old too | 17:07 |
| lool | asac: the thing with grub-efi is that it's a single thing to worry about enabling in u-boot, and hten we can use the same logic everywhere | 17:09 |
| pindonga | elopio, kudos on the xenial mp! :) | 19:56 |
| elopio | :D | 19:56 |
| pindonga | elopio, can I ask you to lobby for my MP with sergiusens ? ;-) | 19:58 |
| kyrofa | elopio, I'm trying to duplicate the lack of locale settings that causes snapcraft --help to barf a stacktrace on an lxc where it works fine | 20:15 |
| kyrofa | elopio, help? | 20:15 |
| kyrofa | sergiusens, you could probabyl answer that as well ^^ | 20:20 |
| elopio | kyrofa: take a look at the new .travis.yml | 20:39 |
| elopio | create a lxc following the same steps, and it won't have the locales set. | 20:39 |
| elopio | we need utf-8 to run some unicode tests, so I changed runtests.sh to set the language. | 20:39 |
| elopio | remove that, run the tests, and you'll get an error. | 20:40 |
| kyrofa | elopio, alright, thanks :) | 20:40 |
| elopio | kyrofa: however, my theory is that the error came from the unicode copyright symbol on some files. That's fixed already. | 20:40 |
| elopio | if my theory is correct, the unicode chars from the tests won't get imported, and you'll be able to run snapcraft in ascii. | 20:41 |
| kyrofa | elopio, or the quotation marks (dholbach noticed those) | 20:41 |
| elopio | hum, I didn't see them. Great we have more eyes :) | 20:41 |
| kyrofa | elopio, I know you've reviewed https://github.com/ubuntu-core/snapcraft/pull/209 . Do you have a sec for a question on it? | 21:09 |
| elopio | kyrofa: I just took a quick look and didn't fully understand the tests. What's your question | 21:10 |
| elopio | ? | 21:10 |
| kyrofa | elopio, yeah you had a good catch there | 21:10 |
| kyrofa | elopio, so right now, the copy plugin follows symlinks and copies in the original file, so no symlinks end up in the .snap | 21:10 |
| kyrofa | elopio, his change adds the ability to do the opposite, which is copy the symlinks themselves as leave them as links, even if they point outside the .snap. I think you and I agree that's not a good idea | 21:11 |
| elopio | kyrofa: that would be when this PR lands, right? | 21:11 |
| elopio | ah right, the default is true. | 21:12 |
| elopio | kyrofa: yes, I would like us to help people building correct snaps. | 21:12 |
| kyrofa | elopio, right. Thing is: if that PR gets fixed to prevent incorrect snaps, is there any downside to using symlinks all the time? i.e. why make it an option? | 21:12 |
| elopio | kyrofa: hum, that question means we need a good integration test for this branch. | 21:13 |
| elopio | I thought that you would have a link to a file, and you want both to end up in your snap. | 21:13 |
| elopio | but I suppose there are times when you want to keep only the real file, and get rid of the link. | 21:14 |
| kyrofa | elopio, ah, I was just thinking if the symlink pointed outside of the .snap, just copy the original | 21:14 |
| kyrofa | elopio, since sometimes the link will be absolute | 21:15 |
| elopio | kyrofa: that makes sense. If the real path is outside, copy the real, not the link. | 21:15 |
| kyrofa | elopio, exactly. It'll take a custom copy function and some decent tests, but then we have the best of all worlds | 21:16 |
| elopio | kyrofa: so that would be the default, and then you can override the behaviour with follow-symlinks: true | false ? | 21:17 |
| kyrofa | elopio, we can support that... but can you think of any reason why a developer wouldn't want symlinks in the .snap? | 21:17 |
| kyrofa | elopio, I can't, which begs the question: why add the option and incur the maintenance cost? | 21:18 |
| elopio | kyrofa: I assumed this would be coming from an external repo that has symlinks for some reason. | 21:18 |
| elopio | we should ask femdom for his usecase. | 21:19 |
| kyrofa | Well, his use-case involves _wanting_ the symlinks. I'm asking: is there ever a reason to NOT want symlinks? | 21:19 |
| elopio | kyrofa: right, I'm reading it on the bug now. | 21:19 |
| elopio | kyrofa: I agree that your proposed solution is better than his. | 21:20 |
| kyrofa | elopio, I'm under the impression that we didn't have symlinks in the first place to avoid the potential dangling link and just copying the original was the quickest path to that goal. I think if we eliminate that possibility symlinks will work for everyone | 21:22 |
| elopio | kyrofa: what I don't like about this is that the snap repo won't have all the files it needs. It depends on the developer machine. | 21:23 |
| elopio | but our goal is not to have reproducible builds. So I guess that's alright. | 21:24 |
| kyrofa | elopio, well, only potentially, and it's that way now if the repo has symlinks pointing outside of the repo | 21:24 |
| kyrofa | elopio, this proposal keeps everything the way it is now unless the symlink is pointing within the .snap already | 21:24 |
| elopio | yes, it'll be better than it is now. | 21:24 |
| kyrofa | Alright, thanks for your brain! I'll mull that over a little | 21:25 |
| kyrofa | elopio, also, when you have a minute: https://github.com/ubuntu-core/snapcraft/pull/264 | 21:27 |
| kyrofa | elopio, integration test failures suck | 21:46 |
| kyrofa | elopio, is there a way to get output from the build? | 21:47 |
| kyrofa | elopio, from run_snapcraft, specifically | 21:48 |
| === popey_ is now known as popey | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
