| mvo_ | ogra_: hi, do you have any expectation on the order of the uboot environment vars? I use alphabetic order right now but was wondering if I should keep the order of the input file inside the uboot.env. I guess it does not matter but I wanted to double check | 06:55 |
|---|---|---|
| fgimenez | good morning | 07:03 |
| dholbach | good morning | 07:19 |
| ogra_ | mvo_, no, no expectations, uboot loads all at once before processing, so any order should be fine | 07:26 |
| mvo_ | Chipaca: hi, I think https://code.launchpad.net/~mvo/snappy/snappy-snappy-bootsuccess-env2/+merge/265259 is good now, I fixed the missing dependency and update tha ppa. I also createda backport for 15.04 but have not proposed it yet, wanted to do the full willy image test first | 08:17 |
| mvo_ | Chipaca: if you could check if its really good now, that would be great | 08:17 |
| longsleep | mvo_: When this is merged and i build a new willy image, will that include the new behavior? | 08:18 |
| ogra_ | longsleep, yes | 08:18 |
| ogra_ | you will need the updated device snap | 08:19 |
| longsleep | ogra_: Even if i have my own device snap? | 08:19 |
| mvo_ | yeah, we are just wating for the final code review, I guess I could top-approve, john said "good except the missing package dependency wich i added) | 08:19 |
| * mvo_ wonders how impatient he is today :) | 08:20 | |
| ogra_ | longsleep, you will need uboot.env support in the bootloader | 08:20 |
| longsleep | yes i got that | 08:20 |
| longsleep | btw - did you see my script for resizing from yesterday: https://github.com/longsleep/snappy-odroidc/blob/master/scripts/resize-snappy-writable.sh | 08:21 |
| longsleep | i would suggest adding something like this to the boot process by default | 08:21 |
| longsleep | will just grow the writable partition no matter what | 08:22 |
| longsleep | (if it can be grown) | 08:22 |
| ogra_ | longsleep, we have a set of initramfs script already that are widely used (i.e. on the phones) ... we just havent decided to include them yet because there are potentially more and bigger changes to the partitioning setup ahead | 08:23 |
| longsleep | ok - understoot. So for now see it as easy way for people to resize their snappy installation. | 08:24 |
| longsleep | so just to be sure - once mvo_ merged the changes, 'ubuntu-device-flash core --channel edge .. 15.10 should' fuse them into an image right? | 08:26 |
| mvo_ | the snapy on the image will deal with both new uboot.env and old uEnv.txt, if uboot.env is there its used, otherwise it just keeps using the old system | 08:29 |
| ogra_ | ah, sweet | 08:29 |
| longsleep | ok - so i could now even remove the empty uEnv.txt ? | 08:31 |
| longsleep | and the snappy tool will still detect u-boot environment? | 08:32 |
| ogra_ | if there is no uboot.env file u-boot will fall back to the defaults | 08:33 |
| ogra_ | (and load uEnv.txt or boot.ini or whatever you have definaed by default) | 08:33 |
| zyga | ogra_: hey, I found two bugs in snappy amd64 boot config | 08:35 |
| ogra_ | file them then | 08:35 |
| zyga | ogra_: I'll report them later today after meetings but I wanted to share this | 08:35 |
| * ogra_ has never touched the grub stuff ... luckily :) | 08:35 | |
| zyga | ogra_: first, we use the wrong identifier for the hard drive and snappy really boots by accident | 08:35 |
| zyga | ogra_: it should be hd0 instead of hd1 everywhere | 08:35 |
| zyga | ogra_: I suspect this is because after the image was generated the grub config generator never ran again | 08:36 |
| zyga | ogra_: this makes it boot by accident really, it boots because -- | 08:36 |
| zyga | ogra_: the filesytem identifiers are used as a fallback and those actually work | 08:36 |
| zyga | ogra_: which is the second bug: everyone that downloads the pre-made image will have the same unique identifier | 08:36 |
| zyga | ogra_: and then mess happens, boot snappy, plug snappy on a usb drive, reboot -- you will boot into the random one depending on bios | 08:37 |
| zyga | ogra_: we should re-generate them on first boot | 08:37 |
| zyga | ogra_: like other things (ssh keys) | 08:37 |
| zyga | ogra_: I'll file them today, thanks | 08:37 |
| longsleep | ogra_: yeah if there is no uboot.env file, my uboot will now fail to boot as i have dropped the boot.ini. But i am also not loading uEnv.txt and in the past this file was used to detect u-boot environment - thus is shipped an empty one and still do. | 08:42 |
| ogra_ | well, why did you drop the boot.ini code ? | 08:42 |
| ogra_ | i assume thats just a fatload somewhere in the u-boot default config ? | 08:43 |
| longsleep | because it is not needed anymore as everthing is in boot.env | 08:43 |
| ogra_ | yes, and that means you can keep the old env around | 08:43 |
| ogra_ | uboot.env will completely replace it if it is there ... if it is not there you fall back to the old methid automatically | 08:43 |
| longsleep | Mhm - i thought to clean it up to avoid confusion | 08:43 |
| ogra_ | well, its a safety net :) | 08:44 |
| * ogra_ doesnt want to admit that he is just to lazy to clean that up in his own images :P | 08:44 | |
| longsleep | mhm - i was thinking to bring back uboot.ini eventually so people can customize "some" variables without modifying the .env file | 08:45 |
| longsleep | the .ini file is handy as it supports comments and empty lines | 08:45 |
| longsleep | i think these two points are the reason they added it | 08:45 |
| ogra_ | well, with uboot-go around changing the env vars isnt actually a biggie | 08:45 |
| ogra_ | but yeah, we dont remove the loading code for uEnv.txt either | 08:46 |
| ogra_ | so you could use it to override thins | 08:46 |
| ogra_ | *things | 08:46 |
| longsleep | well you have to do it from command line - i was thinking about people who insert the sdcard into some pc and use notepad to edit it | 08:46 |
| ogra_ | right | 08:46 |
| longsleep | there are some things people might want to change, like hdmi resolution, mode, sdcard compatibility | 08:47 |
| zyga | ogra_: btw, who's working / looking after the amd64 images? | 08:47 |
| JamesTait | Good morning all; happy Hammock Day! 😃 | 08:48 |
| longsleep | ogra_: and in my old boot.ini i was hacking and calling snappy_boot, so i really want to get rid of this | 08:48 |
| ogra_ | longsleep, just ship an empty one then | 08:53 |
| longsleep | yeah i will do that with some examples for customization | 08:54 |
| longsleep | this is not possible with uEnv.txt | 08:54 |
| longsleep | no comments and no empty lines right? | 08:54 |
| longsleep | i mean for the bbb uEnv.txt is just loaded with import -t -r | 08:55 |
| ogra_ | uEnv.txt is exactly the same | 08:55 |
| longsleep | same was what? | 08:55 |
| ogra_ | comments and all | 08:55 |
| ogra_ | they are identical ... just differently named | 08:56 |
| ogra_ | (i never understood why odroid felt they need their own filename) | 08:56 |
| longsleep | identical to what ? sorry i am not getting it :) | 08:56 |
| longsleep | you mean the boot.ini ? | 08:56 |
| longsleep | they are not the same | 08:56 |
| longsleep | they are similar | 08:56 |
| longsleep | but the boot.ini is parsed differently | 08:57 |
| ogra_ | boot.ini and uEnv.txt are absolutely identical, just that whoever implemented the odroid uboot bits decided he wants it called boot.ini | 08:57 |
| longsleep | no thats not true | 08:57 |
| longsleep | boot.ini supports empty lines and comments | 08:57 |
| ogra_ | i dont think there is any difference in parsing | 08:57 |
| ogra_ | uEnv.txt too | 08:57 |
| longsleep | oh | 08:57 |
| ogra_ | our beagle and RPi images hsip a uEnv.txt with empty lines and comments ;) | 08:57 |
| longsleep | well they have 100 lines parsing code added to u-boot | 08:57 |
| longsleep | so let me check that code | 08:58 |
| longsleep | i would be happy to use uEnv.txt | 08:58 |
| ogra_ | heh, seeing the wily-devel ML it looks like slangasek had "a-f day" :) | 09:00 |
| ogra_ | err ... wily-changes i mean indeed | 09:01 |
| longsleep | ogra_: so the code is here: https://github.com/hardkernel/u-boot/blob/odroidc-v2011.03/board/hardkernel/odroidc/cfgload.c - they have logic to load it from muliple locations which we do not need, the rest is about ignoring comments and parsing all with hush. Is uEnv.txt also parsed with hush? | 09:03 |
| * longsleep needs to learn about uEnv.txt | 09:03 | |
| ogra_ | if hush is enabled, yeah | 09:03 |
| longsleep | ok then - i do not know why they added this cfgload stuff either :) | 09:03 |
| ogra_ | it might be implemented a few mobnths before the uEnv.txt support landed or some such | 09:04 |
| longsleep | mhm well that wile was added end of 2014 - so i guess uEnv.txt support is older | 09:04 |
| ogra_ | uEnv.txt comes from 2010 or 2011 IIRC --- | 09:04 |
| ogra_ | might have been 2012 | 09:05 |
| longsleep | they have some text comparison verifying that the file is for the correct target - maybe that is the reason (it has to start with ODROIDC-UBOOT-CONFIG to be used). | 09:05 |
| longsleep | mhm - i still fail to see how "env import" can process stuff like "setenv foo bar" assuming uEnv.txt is the same as boot.ini | 09:08 |
| Chipaca | mvo_: approved; sorry for the delay (first day of school holidays!) | 09:13 |
| mvo_ | Chipaca: no problem at all | 09:13 |
| mvo_ | Chipaca: I *so* look forward to the school holidays too | 09:14 |
| * mvo_ will sleep until noon that day | 09:14 | |
| Chipaca | :) | 09:14 |
| Chipaca | i instead got a supermarket delivery at 6:30am, just to celebrate | 09:14 |
| Chipaca | but then went back to sleep \o/ | 09:15 |
| mvo_ | lol | 09:15 |
| ogra_ | your kids dont show up at your bed at 7 ? | 09:15 |
| Chipaca | 6:45 | 09:16 |
| Chipaca | but he's just started a longish book, so he was lost in it before 7 | 09:16 |
| Chipaca | i must admit the fact that he's reading "young adult" fiction does bother me a little bit :) | 09:17 |
| ogra_ | why is that ? | 09:19 |
| Chipaca | because he's 10? | 09:19 |
| ogra_ | nothing to bother about then :) | 09:19 |
| Chipaca | that's why the smile :) | 09:20 |
| Chipaca | especially considering i was reading LOTR at his age | 09:20 |
| ogra_ | i had a hang for scifi short stories at that age ... | 09:21 |
| Chipaca | (it's my grandpa's fault, as he gave me the best encouragement he could: he told me i was to young to read it) | 09:21 |
| ogra_ | (i think i was way older before i read LOTR) | 09:21 |
| Chipaca | nice, the kvm hung overnight | 09:22 |
| longsleep | ogra_: so - from my testing uEnv.txt gets loaded as key=value file - it supports comments, but one cannot use if, or setenv in it. Do you have an example for an uEnv.txt which does that? | 09:26 |
| Chipaca | mvo_: anything you'd do different wrt http://pastebin.ubuntu.com/11919018/ ? | 09:26 |
| ogra_ | lohmm, no | 09:27 |
| ogra_ | longsleep, hmm, no | 09:27 |
| ogra_ | longsleep, why do you feel the need for setenv ? | 09:28 |
| longsleep | well it all comes down how the uEnv.txt is loaded, in your bbb its just "env imported", the boot.ini is parse_string_outer line by line. | 09:28 |
| ogra_ | var=value is enough | 09:28 |
| longsleep | setenv is not required true | 09:28 |
| longsleep | but i need if/else | 09:28 |
| ogra_ | if/else work inside a var | 09:28 |
| ogra_ | look at the old snappy-system.txt | 09:29 |
| ogra_ | i.e. the snappy_boot cmd | 09:29 |
| longsleep | well, ok - i need to do this: if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi | 09:29 |
| longsleep | i need to run commands inside if/else | 09:29 |
| longsleep | and the settings should be controllable by user | 09:30 |
| ogra_ | mytest=if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi | 09:30 |
| ogra_ | then you exec mytest from somewhere | 09:30 |
| longsleep | ok i guess i could do that | 09:30 |
| longsleep | let me try :) | 09:30 |
| ogra_ | run mytest | 09:30 |
| ogra_ | ... | 09:30 |
| ogra_ | snappy_boot=if test "${snappy_mode}" = "try"; then if test ${snappy_trial_boot} = 1; then if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; else setenv snappy_ab "a"; fi; else setenv snappy_trial_boot 1; saveenv; fi; fi; run loadfiles; setenv mmcroot /dev/disk/by-label/system-${snappy_ab} ${snappy_cmdline}; run mmcargs; bootz ${loadaddr} ${initrd_addr}:${initrd_size} ${fdtaddr} | 09:30 |
| ogra_ | uenvcmd=run snappy_boot | 09:30 |
| ogra_ | like that :) | 09:31 |
| longsleep | yes, and those vars i could predefine in the .env file even | 09:31 |
| longsleep | ok sounds like a plan - thanks | 09:31 |
| ogra_ | :) | 09:34 |
| longsleep | i want to get rid of all hardkernel special stuff if possible, so make it easier to switch to upstream u-boot eventually. | 09:35 |
| ogra_ | +1 | 09:36 |
| ogra_ | mvo_, do you need an extra approval on https://code.launchpad.net/~mvo/snappy/snappy-bootsuccess-env/+merge/264981 ? i assume we wont get one from sergio this week | 10:18 |
| === bigcat is now known as bigcat[off] | ||
| mvo_ | ogra_: I self approved now, this branch is obsolete with the env2 one anyway | 10:27 |
| ogra_ | ah | 10:27 |
| ogra_ | so now i need to find out how to get the snap into the store | 10:28 |
| ogra_ | seems it was uploaded by a canonical account | 10:28 |
| ogra_ | (and i guess both people that could tell me about it are gone this week) | 10:29 |
| === bigcat[off] is now known as bigcat | ||
| mvo_ | ogra_: so the snappy change is merged, I triggered a ppa build, once that is in the PPA we can do a new image | 11:01 |
| mvo_ | ogra_: re store, | 11:01 |
| ogra_ | mvwe need the snap in the store ... | 11:01 |
| ogra_ | mvo_, we need the snap in the store ... | 11:01 |
| mvo_ | ogra_: so the snappy change is merged, I triggered a ppa build, once that is in the PPA we can do a new image | 11:02 |
| ogra_ | and i have not the slightest clue how to get it there | 11:02 |
| mvo_ | ogra_: re store, one sec | 11:02 |
| mvo_ | ogra_: you have a private message with details :) | 11:04 |
| ogra_ | ah, i need to go to the other machine then :) | 11:04 |
| * ogra_ is having brunch :) | 11:04 | |
| conyoo | is it possible to rollback more than 1 step? i kinda find it interesting to be able to rollback 12 versions back if i'm crazy. the a/b is nice but the whole alphabet is nicer :D | 11:08 |
| ogra_ | ii think currently only one step | 11:09 |
| conyoo | :'( | 11:09 |
| conyoo | oh currently :d | 11:09 |
| conyoo | so there is hope! | 11:09 |
| conyoo | OMG! | 11:09 |
| ogra_ | i'm not sure we plan to actually keep all versions of a snap on your disk forever ... | 11:10 |
| ogra_ | which would be needed for endless rollback | 11:10 |
| conyoo | maybe for selected snaps? :D | 11:10 |
| conyoo | i don't need all of them, but would be nice to work for selected snaps | 11:10 |
| conyoo | i also don't care about disk space | 11:10 |
| mvo_ | we plan to move to a more flexible way than a/b in the future, but its not done yet | 11:11 |
| ogra_ | mvo_, thats about app snaps | 11:11 |
| mvo_ | ogra_: let me know if the msg made it, if not I can also handle the upload | 11:11 |
| conyoo | thanks mvo_ and ogra_ :D sounds amazing to me! :D | 11:11 |
| ogra_ | i guess starting a discussion on the ML might be helpful | 11:11 |
| ogra_ | mvo_, well ~30min, then i'll be back in the office | 11:12 |
| mvo_ | oh, app snaps, yeah, we already keep 3 by default iirc, easy enough to keep more | 11:12 |
| mvo_ | ogra_: thats fine, I get lunch then I think | 11:12 |
| ogra_ | yeah | 11:12 |
| Chipaca | yeah, we'll allow a/b and *also* 𝛼/𝛽 \o/ | 11:35 |
| ogra_ | greek rollback ? | 11:37 |
| ogra_ | mvo_, ok, new bealeblack snap sits in review in the store, someone needs to manually approve it | 11:45 |
| ogra_ | *beagleblack | 11:47 |
| longsleep | ogra_: so now that the change is merged - you think i can build a new image which should handle uboot.env ? | 11:59 |
| ogra_ | longsleep, not yet ... we dont have a new rootfs yet | 12:00 |
| longsleep | ogra_: ah yes - that reminds me that i need to learn how to build a rootfs myself | 12:00 |
| ogra_ | yeah, thats next on my list ... making rootstock-ng work for home builds again | 12:00 |
| longsleep | well does it actually matter how the preinstalled tarball is created? I mean building that should be easy. I am only worried about what comes after that - as i have no clue yet :) | 12:03 |
| ogra_ | after that it gets processed by system-image | 12:04 |
| ogra_ | which unpacks it and the last tarball, diffs the files and creates a delta tarball | 12:05 |
| longsleep | yeah thats the scary part :) | 12:05 |
| * longsleep still needs to build a system-image and deltas for odroidc | 12:06 | |
| ogra_ | https://wiki.ubuntu.com/ImageBasedUpgrades/Server | 12:08 |
| longsleep | yes i have been reading that a couple of times - until now i found something which was more fun to work on | 12:08 |
| ogra_ | i'm also not sure it is worth the effort ... eventually your device tarball will become a snap too ... then a system-image server would be rather pointless (as you would just serve the same rootfs we serve) | 12:10 |
| mvo_ | ogra_: only for rolling right now, correct? | 12:11 |
| mvo_ | ogra_: the 15.04 backport is not approved yet, but we should focus on that now I guess | 12:11 |
| ogra_ | mvo_, well i didnt change anything in the package setup on the page ... it had both ticked ... can you just release for one ? | 12:11 |
| longsleep | ogra_: i am not so sure yet, i might require changes to the rootfs or some software inside it. Or for the paranoid, i might want to have self compiled versions of everything | 12:11 |
| mvo_ | ogra_: I think no, will it still install the old files? i.e. will a old snappy still work? | 12:12 |
| ogra_ | longsleep, that breaks snappy design though ... you should put your extra bits into snaps people can install at build time of the image | 12:12 |
| mvo_ | ogra_: eh, nevermind, of course not | 12:12 |
| ogra_ | mvo_, uEnv.txt is empty | 12:12 |
| mvo_ | ogra_: meh, ok | 12:13 |
| mvo_ | ogra_: I will ask Chipaca for another review then :) | 12:13 |
| ogra_ | yeah, then we can blame him if it breaks, good idea :) | 12:13 |
| mvo_ | ogra_: thats the idea, right? its always the reviewers fault | 12:14 |
| ogra_ | yup | 12:14 |
| mvo_ | ogra_: unless I did the review in which case its the original authors fault | 12:14 |
| ogra_ | *indeed* ! | 12:14 |
| mvo_ | Chipaca: if you have a moment, could you plese check https://code.launchpad.net/~mvo/snappy/15.04-snappy-bootsuccess-env2/+merge/265510 | 12:14 |
| Chipaca | I shall consider it. | 12:15 |
| longsleep | ogra_: yes, but what about images for certain hardware which come with pre installed stuff? | 12:15 |
| mvo_ | Chipaca: meh, I just noticed it may miss a upstream revision, let me quickly double check | 12:16 |
| ogra_ | longsleep, same thin | 12:16 |
| ogra_ | g | 12:16 |
| ogra_ | longsleep, your extras should be in snaps | 12:16 |
| longsleep | ogra_: ok i see - can the snap modify base behavior? Like add or change systemd services ? | 12:17 |
| ogra_ | theoretically yes, not sure how that will practically work ... but confinement is something we enforcxe artificially so you can indeed work around it (as long as a store reviewer approves it) | 12:18 |
| mvo_ | Chipaca: ok, should be ready now | 12:18 |
| longsleep | ogra_: what about third party devices with custom behavior, do these have their own store then? | 12:19 |
| ogra_ | i guess so | 12:19 |
| * ogra_ doesnt know the exactly planned setup for that | 12:19 | |
| longsleep | ogra_: ok, that is probalbly soemthing i need to investigate more then. | 12:20 |
| ogra_ | yep | 12:20 |
| ogra_ | beuno should be abck next week, he can elaborate | 12:20 |
| ogra_ | *back | 12:20 |
| beuno | well, don't kick me out just yet! | 12:21 |
| longsleep | :D | 12:21 |
| ogra_ | hey, didnt you mail that you are vacating ? | 12:21 |
| beuno | tomorrow and thu! | 12:21 |
| beuno | er, tomorrow and fri! | 12:21 |
| ogra_ | ah | 12:22 |
| beuno | longsleep, we're still working out the details on how to support third-party devices that need to break out of confinement. We can point you to the commercial team to help you flesh that out if you'd like | 12:22 |
| longsleep | beuno: Yeah - i just had a call with Marteen and he sent an email to connect me with lool | 12:23 |
| beuno | ah, perfectd | 12:24 |
| longsleep | but i also would prefer to have as less customizations as possible. So i am checking all the possibilies here. Not sure if it really needs to break out of confinement. | 12:26 |
| lool | longsleep: hi! | 12:27 |
| longsleep | I have control on uboot, kernel, snaps and device part. Device part will become a snap eventually. What i need in addition is a customization like some post image build scripts. | 12:27 |
| lool | longsleep: just read through Maarten's email; reading the fwded one now | 12:27 |
| longsleep | lool: hey - no hurries | 12:27 |
| lool | longsleep: ok, done reading, and BTW well done on the ODROID-C OEM snap :-) | 12:28 |
| lool | longsleep: I didn't find details of the questions around SSL and ports; is this written up somewhere in email or bug? | 12:28 |
| longsleep | lool: thanks - that was the easy part. Getting the thing doing the same as with normal ubuntu is the hard part. | 12:28 |
| longsleep | lool: i sent some points to the mailling list in the past, and i have added some stuff to the tracker as well. | 12:29 |
| dholbach | rsalveti, do we have much of an agenda for the snappy community call? | 12:29 |
| ogra_ | oh, i totally forgot about that one | 12:30 |
| ogra_ | no asac today too | 12:30 |
| longsleep | lool: bot i think its best explained all together rather to get the idea | 12:30 |
| dholbach | rsalveti, I had a few days off so not too much to report on my side | 12:30 |
| longsleep | lool: right now it comes down to entropy, having a NGINX framework so many snaps can share port 443 and SSL setup | 12:31 |
| * ogra_ was busy with technical stuff the last days ... | 12:31 | |
| ogra_ | not much from my side either | 12:31 |
| lool | longsleep: I see | 12:32 |
| lool | longsleep: I think it's a great thing to provide | 12:33 |
| lool | longsleep: so in general, we have not been mandating how this or that should be designed but rather gave a set of primitives (like frameworks and apps) as to let various experiences bloom | 12:33 |
| lool | longsleep: and then we see what picks up and makes the most sense | 12:34 |
| lool | longsleep: I think it's a wonderful example | 12:34 |
| lool | longsleep: in general, framework provide services typically in the sense of a shared resource; port 443 is one; entropy pool is another; great things to expose in a framework | 12:34 |
| lool | longsleep: how would the API be? apps depend on your nginx-based framework and register a name over HTTP/REST to localhost to get traffic forwarded to them for /name/ or for name.xyz? | 12:35 |
| longsleep | lool: yes something like that - not sure if it needs to be an api though. In non snappy we just have a conf.d folder where packages can put their configs. | 12:36 |
| ogra_ | well, you could have snappy config do it from your oem snap | 12:36 |
| ogra_ | snappy config can use script hooks to apply the config | 12:37 |
| longsleep | lool: and the entropy one is tricky, on first boot keys need to be generated - it needs to be ensured that there is entropy available. Right now it creates key with essentially no entropy on first boot. | 12:37 |
| longsleep | ogra_: ok, snappy config - thats something i need to investigate then. Is that only for oem snaps or also for software snaps? | 12:38 |
| lool | longsleep: so apps (and frameworks) are sandboxed as to prevent apps to see files from other apps; there needs to be a provisioning mechanism; we dont want maintainer scripts, but you could have data bits | 12:38 |
| ogra_ | longsleep, thats for all snaps | 12:38 |
| ogra_ | but in context of oem it can indeed be more powerful | 12:38 |
| lool | I dont think config hook will help to cross app barriers | 12:38 |
| ogra_ | no, but to alter system defaults without having to hack the rootfs snap | 12:38 |
| lool | the idea of config hooks if to have a standard interface for one snap to load/dump its config in YAML | 12:39 |
| ogra_ | (or tarball) | 12:39 |
| ogra_ | what longsleep wants, as i understand is some firstboot config to be applied | 12:39 |
| ogra_ | for that the config hooks in the oem snap should be fine | 12:39 |
| longsleep | only if applying that would block boot | 12:40 |
| longsleep | or start of systemd services | 12:40 |
| longsleep | i mean, the problem exists today. The SSH keys are generated on first boot with essentially no entropy. | 12:40 |
| longsleep | Thats why i think the problem needs solving on snappy level. | 12:40 |
| lool | we're discussing two different things | 12:40 |
| ogra_ | well, on a cloud-init level | 12:41 |
| lool | one is the entropy, the other is providing nginx to other apps | 12:41 |
| longsleep | yes true | 12:41 |
| longsleep | lets talk nginx first | 12:41 |
| longsleep | i was thinking to have something similar to the docker framework | 12:41 |
| longsleep | it essentially the same | 12:41 |
| longsleep | provide outside resouces to snaps | 12:41 |
| longsleep | right? | 12:41 |
| lool | yup, kind of | 12:42 |
| longsleep | right now i would have to ship nginx inside my snap | 12:42 |
| longsleep | instead i could create a nginx snap | 12:42 |
| longsleep | and somehow depend on it | 12:42 |
| longsleep | are frameworks snaps too? | 12:42 |
| lool | so generally, we are not trying to use frameworks as a mean to distribtue dependencies | 12:42 |
| lool | liek packages were | 12:43 |
| lool | snaps are apps | 12:43 |
| ogra_ | yes, frajmeworks are snaps | 12:43 |
| lool | fully contained | 12:43 |
| lool | frameworks are to deliver a service or access to a shared resource | 12:43 |
| longsleep | yes | 12:43 |
| lool | for instance, a bluetooth service | 12:43 |
| lool | but if the goal is to make it easy for an app to embed a HTTP server like nginx, then I think this is more of a snapcraft topic | 12:43 |
| lool | which is the optional developer tool to create snaps | 12:44 |
| longsleep | mhm not sure - that would mean there would be multiple nginx running | 12:44 |
| lool | with snapcraft, you can say "embed a java runtime in my snap" | 12:44 |
| lool | similarly, you might want to embed a HTTP server | 12:44 |
| lool | yes, multiple HTTP servers running is fine | 12:44 |
| lool | obviously not on the same port | 12:44 |
| longsleep | not on the same port - and they all would need access to the same private key | 12:44 |
| lool | not necessarily | 12:45 |
| lool | that's if they serve the same site | 12:45 |
| longsleep | true | 12:45 |
| lool | so perhaps it would make sense to discuss the larger problem you're trying to solve | 12:45 |
| longsleep | right now we have a bunch of micro services all providing HTTP web server. To the outside they get exposed with specific configuration by Nginx TLS on 443/tcp | 12:46 |
| lool | is it to make it easy to server a bunch of websites from a snappy install? | 12:46 |
| longsleep | well, if web sites mean differnt domains then no. | 12:46 |
| longsleep | its about exposing web services on port 443/tcp with a secure TLS configuration. | 12:47 |
| longsleep | lets take the example from spreed-webrtc | 12:47 |
| longsleep | its a go service, wich listens on port 8080/tcp | 12:47 |
| longsleep | it needs to be exposed to the world on port 443/tcp with tls | 12:48 |
| longsleep | it could do that itself or the snap could include a web service which does it | 12:48 |
| lool | longsleep: is there an architecture diagram of spreed somewhere? | 12:48 |
| longsleep | sure | 12:48 |
| longsleep | hold on | 12:48 |
| longsleep | but spreed-webrtc is simple | 12:49 |
| longsleep | in the default setup it has only one end point | 12:49 |
| lool | longsleep: yes, but rather than discussing bottom up, I'd like us to have a top down discussion | 12:49 |
| longsleep | let me upload it | 12:49 |
| lool | longsleep: for instance, from my naive understanding, I understand that this is about delivering spreed easily; I instinctively think this shoud be implemented by delivering a single spreed snap that offers the whole thing with hardcoded configs for most things, then exposing more and more features | 12:50 |
| longsleep | lool: yes - but that only works if no other snap uses port 443. | 12:50 |
| lool | longsleep: basically, the closest thing that matches this for me is how I'd run Kodi on an Android device | 12:50 |
| lool | I'd install the Kodi app | 12:51 |
| lool | and then run it | 12:51 |
| ogra_ | and perhaps have snappy config options to en/disable single spreed bits | 12:51 |
| lool | in the first version, this would not expose all the crazy advanced features like the web services for the remote control or the storage abstraction or etc. | 12:51 |
| * ogra_ tried a kodi snap on the weekend but failed to build a static binary *sniff* | 12:52 | |
| longsleep | lool: can you go to https://spreed.me/struktur/longsleep and i share the diagram with you there | 12:52 |
| lool | longsleep: so port conflicts are a real issue; we need to provide a definitive solution for this, but for now I'd say take port 443 by default, make the port configurable in the config hook and let anyone install the app; if the port is free, it's used, otherwise it's configurable | 12:52 |
| lool | longsleep: I have a personal opinion on how we should solve the port issue, but I dont think it was discussed | 12:52 |
| lool | longsleep: the current plan was around having an API to negociate/reserve ports | 12:52 |
| longsleep | lool: ok - what about muliple ips - do you have ideas around that as well? | 12:53 |
| lool | my personal opinion is that we should start apps in some kind of network namespace where they can do what they want and some core snappy config allows routing host ports to snappy apps | 12:53 |
| mvo_ | Chipaca: \o/ | 12:53 |
| Chipaca | :) | 12:53 |
| ogra_ | lool, sounds like ubuntu-fan for ports :) | 12:53 |
| lool | longsleep: I'm there | 12:54 |
| longsleep | lool: ok - i shared the file with you. | 12:55 |
| rsalveti | longsleep: https://wiki.ubuntu.com/Snappy/CoreImageBuild as well | 12:55 |
| rsalveti | dholbach: we can do a short call, just wanted to talk about snapcraft quickly | 12:56 |
| dholbach | sure | 12:56 |
| lool | longsleep: got it | 12:56 |
| longsleep | so you see Nginx STUN and TURN | 12:57 |
| longsleep | In the simple case we have only Nginx | 12:57 |
| longsleep | that is on port 443 | 12:57 |
| longsleep | but what if we want to have a TURN server as well | 12:57 |
| longsleep | that would be a different snap | 12:57 |
| longsleep | also needs to listen on port 443 | 12:58 |
| longsleep | different IP | 12:58 |
| longsleep | or if we would add other backend services | 12:58 |
| lool | longsleep: ok, so what's the minimal first version we could target? coudl we do everything on top of User 2 in a single snap to start with? | 12:58 |
| longsleep | yes that is no problem | 12:58 |
| lool | longsleep: BTW, checkout snapcraft; it's alpha but it allows bundling binaries from .debs easily | 12:58 |
| lool | I've used it to embed a java runtime and tomcat with a webapp | 12:58 |
| longsleep | lool: Maarten told me about this today | 12:59 |
| longsleep | will check it out for sure | 12:59 |
| lool | longsleep: (NB: I have a call tunnel starting now and going 4 hours) | 12:59 |
| lool | 4.5 actually | 12:59 |
| longsleep | no problem | 12:59 |
| lool | but I'm reading IRC | 12:59 |
| longsleep | think about the entropy problem though | 12:59 |
| longsleep | that is more critical :) | 12:59 |
| longsleep | thanks for your time | 13:00 |
| lool | longsleep: so are STUN and TURN typically provided / deployed with spreed? | 13:07 |
| lool | are you saying the second IP is mandatory? | 13:07 |
| longsleep | no they are optional | 13:07 |
| longsleep | but you should have a STUN server somewhere | 13:07 |
| longsleep | and a TURN server too for firewalled users | 13:07 |
| lool | longsleep: ok; entropy... again super naive thought, but we do that in all our cloud images: they boot and get some entropy from linux to generate a SSH key (I guess /dev/random provides a limited amount thanks to entropy of network traffic?) | 13:08 |
| longsleep | eg on our deployments they are all installed and that requires 3 IP's even. But the spreed server works fine with one. | 13:08 |
| lool | longsleep: are the TURN/STUN bits typically provided with the spreed codebase? | 13:08 |
| longsleep | lool: no it is a separate software | 13:08 |
| lool | longsleep: are the TURN/STUN generally useful with non-spreed use cases? | 13:09 |
| longsleep | lool: cloud images are a little different, they have most likely network connection on first boot and load entropy from your entropy service. While i find that scary too at least the keys are fine assuming the entropy service is providing good random. | 13:09 |
| lool | (I know what kind of services these provide, just not sure if these are typically used outside of spreed in general) | 13:10 |
| longsleep | lool: yes sure, many services require / can use a STUN/TURN service | 13:10 |
| kyrofa | ogra_, since i2c isn't enabled on the rpi2, does that mean the GPIO works out of the box? | 13:10 |
| lool | longsleep: I can't really judge on this question product-wise, but I see two ways this could be done: either bundle all the software in a spreed snap, with 3 sets of services; second and third set of services would be disabled by default but could be enabled from a tunable | 13:11 |
| ogra_ | kyrofa, no | 13:11 |
| lool | longsleep: would also expose config to set IP address to use | 13:11 |
| longsleep | lool: yes - that is possible. No problems here - though i wanted to avoid problems when people have other snaps also binding port 443 (current example is the ownlcoud snap). | 13:12 |
| kyrofa | ogra_, can I get it to work, or is it in a similar situation to i2c? | 13:12 |
| ogra_ | you need to have the bootloaders load the overlay dtb files that are needed for this ... and it will onyl work with ppisati's new kernel which will only be in the next image | 13:13 |
| kyrofa | ogra_, alright, thanks for the info :) | 13:15 |
| === kickinz1 is now known as kickinz1|afk | ||
| ogra_ | mvo_, E: Build-Depends dependency for ubuntu-snappy cannot be satisfied because the package golang-uboot-go-dev cannot be found ... | 13:20 |
| ogra_ | anything to worry about ? | 13:20 |
| ogra_ | https://launchpadlibrarian.net/212301215/buildlog.txt.gz | 13:20 |
| mvo_ | ogra_: yeah, I coped the depenency but looks like it was only copied but not published | 13:20 |
| mvo_ | ogra_: I'm sitting here very impatiently | 13:20 |
| mvo_ | ogra_: fwiw, I started a wily image build now, that should have the real deal | 13:21 |
| ogra_ | ah, sweet | 13:21 |
| mvo_ | ogra_: and once the golang-uboot-go package is available on vivid we can test that too | 13:21 |
| ogra_ | yup | 13:21 |
| mvo_ | ogra_: yay, build! now once that is published we should have a 15.04 test image | 13:24 |
| ogra_ | cool .... i'll test after the call | 13:25 |
| ogra_ | (assuming it ever ends so dholbach can go back to comb his moustache ) | 13:25 |
| kyrofa | Has anyone tried doing something with apache or nginx on snappy? | 13:25 |
| * longsleep has tried nginx | 13:26 | |
| * ogra_ has done a few nodejs snaps | 13:26 | |
| kyrofa | longsleep, any luck? Did you make it a framework and make a website snap or something? | 13:26 |
| ogra_ | you should put it inside your snap | 13:26 |
| longsleep | kyrofa: did not make a framework - had it in a snap | 13:26 |
| kyrofa | ogra_, interesting. How would I install multiple website snaps that way? (i.e. a fight over ports 80 and 443) | 13:27 |
| * dholbach slaps ogra_ :) | 13:27 | |
| longsleep | kyrofa: yeah we just had that discussion. Nginx framework might be handy | 13:27 |
| * ogra_ hands dholbach https://vimeo.com/111123707 | 13:27 | |
| ogra_ | :) | 13:27 |
| kyrofa | longsleep, interesting, I wonder how tough that would be. I'll look into it if you think that such a framework is possible | 13:30 |
| * ogra_ doesnt think a webserver is actually suitable for frameworks ... but looks like lool disagrees above | 13:30 | |
| kyrofa | ogra_, how else to you get around the port fighting? | 13:31 |
| longsleep | kyrofa: well we will see how it goes | 13:31 |
| ogra_ | kyrofa, see backlog that was discussed above ... | 13:31 |
| ogra_ | most likely by providing a port controlling service inside snappy | 13:31 |
| kyrofa | ogra_, oh, you were _literally_ just discussing it! Okay :) | 13:31 |
| ogra_ | well lool told us his vision ... the discussion is still outstanding | 13:32 |
| ogra_ | mvo_, hmm, udf for 15.04 edge still gets me image 124 (the same i had yesterday) | 13:34 |
| mvo_ | ogra_: you are too quick, wily is still building and 15.04 is not even publised yet | 13:34 |
| ogra_ | oh, ok | 13:35 |
| mvo_ | ogra_: so once snappy is published I will trigger a build and let you know, ~30min at last | 13:35 |
| * ogra_ gets fresh coffee and a cigrarette | 13:35 | |
| ogra_ | yeah | 13:35 |
| mvo_ | yay, tea | 13:35 |
| * mvo_ jumps with joy | 13:35 | |
| * ogra_ jumps along | 13:35 | |
| * Chipaca starts getting "unusable private key" from gpg, and is sad | 13:36 | |
| mterry | elopio, even in your branch names, you like underscores ;) ~elopio/snapcraft/integration_coverage | 13:36 |
| Chipaca | ooh! it's key day! | 13:36 |
| === nyx_ is now known as moonwalk | ||
| Chipaca | mvo_: you got a bit? | 13:59 |
| mvo_ | Chipaca: sure | 14:02 |
| elopio | good morning. | 14:09 |
| elopio | mterry: we should pep8 also our branch urls :) | 14:09 |
| mterry | :) | 14:11 |
| elopio | zyga: is there a way to make less verbose the output of plainbox, in case all the tests pass? | 14:14 |
| zyga | elopio: hey | 14:16 |
| zyga | elopio: yes | 14:16 |
| zyga | lool: https://bugs.launchpad.net/snappy/+bug/1477178 (the stuff I mentioned today) | 14:16 |
| ubottu | Launchpad bug 1477178 in Snappy "Snappy prebuilt images have very non-unique filesystem identifiers" [Undecided,New] | 14:16 |
| lool | zyga: yup | 14:17 |
| zyga | elopio: you can provide a different UI, I can show you how to do that tomorrow after my chain of meetings | 14:17 |
| zyga | elopio: I suspect we could also use a more silent UI as an option, this is all related to using plainbox as a simple unit-test runner | 14:17 |
| zyga | elopio: can we work on that sometime tomorrow afternoon CET? | 14:17 |
| mvo_ | ogra_: both wily and 15.04 are build, we just wait for arm64, iirc the import will only start if all arches are build, but maybe (hopefully) I misremember that | 14:18 |
| * ogra_ taps foot | 14:18 | |
| ogra_ | i shoudl grow a moustache too so i could comb it while waiting | 14:18 |
| genii | Also good for straining your soup | 14:19 |
| ogra_ | yeah, and keep something for bad days | 14:19 |
| longsleep | for some reason a bunch of parameters to the kernel get lost from uboot to dmesg - someone seen that before? | 14:22 |
| === howefield is now known as howefield_afk | ||
| elopio | zyga: tomorrow around this time would be ok. Thanks. | 14:22 |
| elopio | mterry: can I move the snapcraft.dirs.setup_dirs() inside snapcraft.main.main() ? | 14:24 |
| elopio | I think main should do everything. | 14:24 |
| mterry | elopio, probably? No one calls main() without doing that, I assume? | 14:24 |
| kyrofa | seb128, just a heads up: I believe a newly built version of the snappy scope hit the NEW queue yesterday. The newest version of lintian caught some duplicate licenses in debian/changelog, so that's been fixed now | 14:24 |
| seb128 | kyrofa, k, great, I reviewed it yesterday and it looked good, let me NEW it | 14:25 |
| longsleep | ah - it was uEnv.txt seems it cannot handle lines like var=value # comment | 14:25 |
| ogra_ | longsleep, what kind of parameters ? | 14:26 |
| ogra_ | ah | 14:26 |
| ogra_ | yeah, i think they cant be on the same line | 14:26 |
| kyrofa | longsleep, how dare you comment your variables :P | 14:26 |
| longsleep | yes comments at end of lines get included in the variable value and then magically scripts handle the # and stop afterwards :D | 14:27 |
| ogra_ | sounds like a bug though | 14:27 |
| * longsleep will never comment variables again - not! | 14:27 | |
| kyrofa | longsleep, I bet that was tough to find | 14:27 |
| longsleep | not really - i am used to u-boot problems by now :) | 14:28 |
| elopio | fgimenez: I'll work on your comments for the rollback, so lets skip our meeting today. | 14:28 |
| elopio | let me know here if you want me to do something this evening. | 14:28 |
| longsleep | that explains why the kernel crashed before - i had variable values with hashes at the end | 14:30 |
| ogra_ | well, if you need the hash sign you should be able to use single quotes | 14:31 |
| longsleep | right, but it was just the comment | 14:31 |
| longsleep | moving the comments into extra lines works just fine | 14:31 |
| longsleep | stil the 4k monitor i got here does not even now then i changed to dvi mode :( | 14:32 |
| tedg | Uhg, three QML apps installed and ran out of space in my VM. | 14:34 |
| zyga | elopio: nice | 14:34 |
| fgimenez | elopio, fine, i'll continue with the integration tests job, hopefully i'll push something for you to try today | 14:36 |
| elopio | fgimenez: now we can talk about putting all the tests in the tests package. That would be merging the current cmd and failover dirs. | 14:37 |
| elopio | do you prefer to have them separated? | 14:38 |
| fgimenez | elopio, now it doesn't make too much sense, having them unified would simplify the filtering and would consolidate the output dir | 14:39 |
| elopio | fgimenez: ok, I'll get to that too. | 14:42 |
| fgimenez | elopio, ok thx | 14:45 |
| Chipaca | zyga: wrt uuids, have you tried rolling? we no longer use uuids in grub | 15:09 |
| Chipaca | zyga: in fact i thought that was already in 15.04 | 15:11 |
| Chipaca | but i'm not the bestest at tracking what we backported and what not | 15:11 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | (that would be mvo) | 15:11 |
| mvo_ | we never use uuids, did we? | 15:11 |
| mvo_ | not in 15.04 | 15:12 |
| Chipaca | mvo_: before i cleaned up update-grub, we got uuid cruft in there | 15:12 |
| Chipaca | mvo_: s/i/we/ | 15:12 |
| Chipaca | mvo_: this is wrt https://bugs.launchpad.net/snappy/+bug/1477178 | 15:14 |
| ubottu | Launchpad bug 1477178 in Snappy "Snappy prebuilt images have very non-unique filesystem identifiers" [Undecided,New] | 15:14 |
| ogra_ | Chipaca, does that even matter at all, since we fall back to the right thing anyway ? | 15:15 |
| Chipaca | ogra_: zyga seems to think it does :) | 15:18 |
| ogra_ | as long as we end up booting the right thing ... | 15:18 |
| zyga | Chipaca: I didn't but this should be fixed in stable as well | 15:25 |
| zyga | Chipaca: I'd love if you could look at my inception snap if you have a moment | 15:25 |
| zyga | Chipaca: and if you could tell me more about how /boot/grub/grub.cfg (as in 15.04 image) came to be | 15:25 |
| zyga | Chipaca: as IMHO it's broken in other ways | 15:25 |
| zyga | Chipaca: it looks like it was generated when /dev/sdb was snappy | 15:26 |
| zyga | Chipaca: all the identifiers there refer to hd1 | 15:26 |
| zyga | Chipaca: but if you inerrupt grub and go to grub console | 15:26 |
| Chipaca | zyga: http://pastebin.ubuntu.com/11920503/ | 15:26 |
| zyga | Chipaca: ls hd<tab><tab> will show you that snappy is actually on another disk | 15:26 |
| Chipaca | zyga: i have no idea what grub.cfg you're looking at; i don't think we've ever explicitly refered to hdX | 15:26 |
| zyga | Chipaca: is that rolling? | 15:26 |
| zyga | Chipaca: look at the one on ubuntu.com snappy website :) | 15:27 |
| zyga | Chipaca: I can pastebin that in a moment | 15:27 |
| ogra_ | smells a bit like something ran update-grub or some such | 15:27 |
| zyga | ogra_: yes | 15:27 |
| zyga | ogra_: likely | 15:27 |
| ogra_ | (which i think we ripped out completely by now) | 15:27 |
| ogra_ | (luckily) | 15:27 |
| zyga | ogra_: we should kill non-snappy /etc/grub.d/ bits | 15:27 |
| Chipaca | zyga: we no longer use update-grub at all | 15:28 |
| zyga | ogra_: that sounds good, so without that, and with uuids fixed, it should be better | 15:28 |
| zyga | Chipaca: btw, when you said you don't use uuids | 15:28 |
| Chipaca | but, again, dunno about 15.04 stable; checking 15.04 edge right now | 15:28 |
| zyga | Chipaca: does that mean they are changed on first boot | 15:28 |
| zyga | Chipaca: because if not you will still get mess while booting | 15:28 |
| Chipaca | zyga: not as far as i know | 15:28 |
| Chipaca | zyga: why will we get a mess? | 15:28 |
| zyga | Chipaca: e.g. you boot with labels and labels are terribly nonunqie | 15:28 |
| zyga | Chipaca: boot snappy preinstalled with snappy usb | 15:28 |
| zyga | Chipaca: you boot to ... usb | 15:28 |
| ogra_ | but non-unique is exactly what we want | 15:29 |
| zyga | ogra_: why? | 15:29 |
| zyga | Chipaca: btw, what is /prefix there | 15:30 |
| ogra_ | zyga, today i can boot from SD, plug in a USB key, make a partition and label it "wrtitable" ... move the content from the SD writable partition and delete it there .... and snap my writable space on the RPi is 1TB | 15:30 |
| zyga | ogra_: yes, that's all fine | 15:30 |
| ogra_ | same goes for a and b | 15:30 |
| zyga | ogra_: but it break if you have two snappy-like partitions around | 15:30 |
| ogra_ | yes, you shouldnt | 15:30 |
| zyga | ogra_: that's unreliable, it should not break just beacuse I happen to have snappy dual boot | 15:30 |
| zyga | ogra_: no, the system should keep working | 15:30 |
| Chipaca | 15.04 edge is an update-grub--generated file, but no mention of hdX | 15:30 |
| zyga | ogra_: and the right way to do that is to use unique partition IDs | 15:31 |
| ogra_ | zyga, well, the whole setup is still totally in flux | 15:31 |
| ogra_ | zyga, we might end up with only two partitions for everything | 15:31 |
| zyga | ogra_: and the use case you want is a developer feature, I'm sure you can hack your boot conf to mount those by label | 15:31 |
| zyga | ogra_: oh, nice | 15:31 |
| ogra_ | /boot and writable | 15:31 |
| zyga | ogra_: what's the intended layout? | 15:31 |
| zyga | brb | 15:31 |
| Chipaca | zyga: “GRUB’s normal start-up procedure involves setting the ‘prefix’ environment variable to a value set in the core image by grub-install, setting the ‘root’ variable to match, loading the ‘normal’ module from the prefix, and running the ‘normal’ command (see normal). This command is responsible for reading /boot/grub/grub.cfg, running the menu, and doing all the useful things GRUB is supposed to do.” | 15:32 |
| Chipaca | zyga: IOW, $prefix is set by grub on startup; it points to the grub directory (whatever holds grub.cfg) | 15:33 |
| Chipaca | zyga: https://www.gnu.org/software/grub/manual/html_node/GRUB-only-offers-a-rescue-shell.html | 15:33 |
| zyga | Chipaca: thanks | 15:33 |
| zyga | Chipaca: I spent ~10 hours in grub this week :D | 15:34 |
| zyga | Chipaca: found lots of goodies | 15:34 |
| zyga | Chipaca: and learned a lot | 15:34 |
| ogra_ | zyga, moving the a and b readonly partitons to be squashfs images ion /boot instead of partitions | 15:34 |
| zyga | ogra_: oh, great | 15:34 |
| zyga | ogra_: that's even more interesting | 15:34 |
| ogra_ | :) | 15:35 |
| zyga | ogra_: so they are mounted from squashfs | 15:35 |
| Chipaca | zyga: i spent a little bit of time on it to pare grub.cfg down to what i pastebin'ed; i'm sure it's missing stuff (e.g., does it work on xen?), but it's at least a sane starting point | 15:35 |
| ogra_ | zyga, right | 15:35 |
| zyga | ogra_: will that follow to .snaps? | 15:35 |
| zyga | how can I get rolling? | 15:35 |
| zyga | I'd like to try that | 15:35 |
| ogra_ | zyga, sergiusens and mvo are currently researching that setup | 15:35 |
| Chipaca | o ubuntu-device-flash core rolling --oem=generic-amd64 --channel edge -o wily.img --developer-mode | 15:35 |
| Chipaca | zyga: ^ | 15:35 |
| zyga | Chipaca: do I need to be on willy? | 15:35 |
| zyga | wily | 15:35 |
| Chipaca | zyga: s/^o/sudo/ :) | 15:36 |
| zyga | (I always want to say willy) | 15:36 |
| zyga | :D | 15:36 |
| Chipaca | zyga: there's a ppa for legacy releases like utopic | 15:36 |
| Chipaca | :) | 15:36 |
| Chipaca | zyga: the "tools" ppa | 15:36 |
| zyga | Chipaca: i'm on vivid | 15:36 |
| zyga | and I have ... | 15:37 |
| zyga | deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu vivid main | 15:37 |
| Chipaca | zyga: should work, then | 15:37 |
| zyga | nice, I'll try that | 15:37 |
| zyga | I have a dedicated snappy test box | 15:38 |
| zyga | to try various cert magic on | 15:38 |
| elopio | mterry: I don't fully understand the current behaviour of log. Your idea was to use print from plugins and snapcraft.common.log from snapcraft itself? | 15:38 |
| Chipaca | zyga: on first boot you might not get ethernet; a reboot should fix it | 15:38 |
| Chipaca | zyga: also note "rolling" is code for "we break it all the time" | 15:39 |
| zyga | Chipaca: I though that was "rawhide" ;-) | 15:40 |
| ogra_ | dude ! | 15:40 |
| Chipaca | zyga: "rawhide" is code for "*they* break it all the time" | 15:40 |
| ogra_ | wrong distro | 15:40 |
| zyga | ogra_: I know that | 15:40 |
| ogra_ | :) | 15:40 |
| mvo_ | mterry: given that we have no python3-fixtures on tarmac right now I wonder if we should just merge manually right now. sucks but sucks to be blocked by tarmac too | 15:40 |
| zyga | Chipaca: I'm woring on a solution for automatic testing machines that don't do netbooting | 15:40 |
| zyga | Chipaca: e.g. xps13 over wifi | 15:40 |
| zyga | Chipaca: I _may_ have some suggestions for boot parts as I go | 15:41 |
| zyga | Chipaca: where can I target that as patches? | 15:41 |
| zyga | Chipaca: (though x86 only atm) | 15:41 |
| Chipaca | zyga: um, depends on the patch i guess? asking here is a good place to start | 15:43 |
| zyga | Chipaca: where does grub part live? | 15:43 |
| Chipaca | ogra_: we should rename 'stable' to 'rawhide', to see if they're paying attention | 15:43 |
| zyga | Chipaca: I'm only interested in that for now | 15:43 |
| ogra_ | lol | 15:43 |
| Chipaca | zyga: split between u-d-f and the generic-amd64 part, afaik | 15:44 |
| ogra_ | "rawhide tumbleweed" then | 15:44 |
| zyga | ogra_: no, no | 15:44 |
| zyga | ogra_: rawhide tumbleweed 10 X | 15:44 |
| zyga | then it'll work | 15:44 |
| zyga | Chipaca: where do they live? | 15:44 |
| Chipaca | zyga: lp:~snappy-dev/snappy-hub/snappy-systems | 15:45 |
| Chipaca | zyga: or lp:goget-ubuntu-touch for u-d-f | 15:45 |
| zyga | thanks | 15:45 |
| zyga | I got the first one, getting the second | 15:46 |
| zyga | (and my boot beagle patch is merged now ^_^) | 15:46 |
| Chipaca | I'm not sure we don't have logic in livecd still; sergio would know but he's away doing critical feature work | 15:46 |
| zyga | Chipaca: aka putting the big fire out ;) ? | 15:46 |
| Chipaca | zyga: aka having a kid | 15:46 |
| zyga | Chipaca: how does livecd fit into place? | 15:46 |
| zyga | ah | 15:46 |
| Chipaca | :) | 15:46 |
| zyga | yeah, that takes a while | 15:46 |
| zyga | like 30 years ... | 15:47 |
| Chipaca | *sigh* | 15:47 |
| * Chipaca is 10 into that | 15:47 | |
| zyga | :D | 15:47 |
| zyga | Chipaca: I'm 8 | 15:47 |
| ogra_ | and i always thought you looked older | 15:48 |
| Chipaca | zyga: i'm not *sure*, but i think we use livecd-rootfs to create the rootfs | 15:48 |
| zyga | mmm | 15:48 |
| ogra_ | we do | 15:48 |
| Chipaca | ogra_: it's the beard | 15:48 |
| ogra_ | yeah :) | 15:48 |
| Chipaca | but that's descending into handwavy "sergio and ogra get a room, and magic happens, and we get an image" territory | 15:49 |
| zyga | :DD | 15:49 |
| ogra_ | mvo_, damn ... i just found out the image doesnt boot .... if you dont plug the SD into the slot ... | 15:50 |
| Chipaca | ogra_: the image that is on the SD? | 15:50 |
| ogra_ | Chipaca, yeah | 15:50 |
| Chipaca | ogra_: stop the line! that's a critical bug | 15:50 |
| zyga | ogra_: ;-) | 15:50 |
| Chipaca | :) | 15:50 |
| zyga | ogra_: use the force | 15:50 |
| zyga | ogra_: make it boot | 15:50 |
| ogra_ | looks fine if i pluig it in though :) | 15:50 |
| mvo_ | ogra_: I'm still waiting for the dd to finish, godd tells me 2m:50s | 15:51 |
| mvo_ | but I think its lying | 15:51 |
| zyga | ogra_: do you remember that weird remote SD card from linaro? | 15:52 |
| zyga | ogra_: I hear you can get some | 15:53 |
| zyga | ogra_: if you ask the right person | 15:53 |
| zyga | ogra_: if you are tired with waving that SD card around all the time | 15:53 |
| kyrofa | Chipaca, sergio is having a kid? | 15:54 |
| ogra_ | mvo_, so whats the command to change the uboot vars now, how did you call the final binary ? | 15:54 |
| kyrofa | Chipaca, that's awesome! | 15:54 |
| zyga | ogra_: | 15:54 |
| ogra_ | kyrofa, he already had ... now he is having insomnia | 15:54 |
| zyga | er... | 15:54 |
| zyga | tab up mess | 15:54 |
| kyrofa | ogra_, yeah, I know how that goes. I have a 1-year-old myself | 15:54 |
| mvo_ | ogra_: there is no command (but fw_printenv, fw_setenv will work). its all part of the library that is used from inside snappy | 15:55 |
| ogra_ | mvo_, hmm, i dont see the config in /etc | 15:59 |
| ogra_ | (note i'm on 15.04 edge) | 15:59 |
| mvo_ | meh, right, its only in edge. do you "just" need it for debugging? | 16:00 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ ls /etc/fw* | 16:01 |
| ogra_ | ls: cannot access /etc/fw*: No such file or directory | 16:01 |
| ogra_ | (BeagleBoneBlack)ubuntu@localhost:~$ sudo fw_printenv | 16:01 |
| ogra_ | Cannot parse config file: No such file or directory | 16:01 |
| mvo_ | I need to add it for 15.04 to livecd rootfs too if we need it | 16:01 |
| ogra_ | well, i need to set the boot to "try" no ? | 16:01 |
| ogra_ | i'll do it from the uboot prompt | 16:01 |
| mvo_ | ok | 16:01 |
| ogra_ | yawn ... cloud-init ... | 16:03 |
| ogra_ | mvo_, hmm, so booting with "try" still boots from a/ | 16:05 |
| ogra_ | shouldnt it have switched to b ? | 16:06 |
| mvo_ | ogra_: did you also set snappy_ab=b ? | 16:06 |
| ogra_ | no, just try | 16:06 |
| mvo_ | ogra_: both need to be set | 16:06 |
| ogra_ | oops | 16:06 |
| * ogra_ retries | 16:06 | |
| mvo_ | ogra_: no worries, try is actually more logical | 16:07 |
| ogra_ | at least i havent managed to trash it yet | 16:07 |
| mvo_ | I mean, its more logical that you set it to try and it automatically toggles | 16:07 |
| ogra_ | in 5 boots | 16:07 |
| mvo_ | a good sign! | 16:07 |
| ogra_ | and i always find snappy_mode=regular when i reset the board | 16:08 |
| ogra_ | so snappy updates the var properly | 16:08 |
| ogra_ | hmpf | 16:09 |
| ogra_ | still boots from a/ | 16:09 |
| ogra_ | even with both set | 16:09 |
| ogra_ | but still no corruption at least | 16:09 |
| ogra_ | ubuntu | 16:10 |
| ogra_ | bah ! | 16:10 |
| mvo_ | ogra_: same here on wily, boots from "a" | 16:10 |
| mvo_ | ogra_: cloud-init is soooooo slow | 16:10 |
| mvo_ | but snappy_ab is set to b hmmmm | 16:11 |
| ogra_ | yeah, cloud-init is a pain | 16:11 |
| ogra_ | really wastes my time | 16:11 |
| mvo_ | hm, snappy_trial_boot may also needs to be set to 1 | 16:11 |
| ogra_ | my snappy_ab is properly re-set to a | 16:11 |
| * mvo_ tests | 16:11 | |
| longsleep | mvo_: do i can try a new image too now? 15.04 edge? | 16:11 |
| mvo_ | longsleep: yes | 16:12 |
| ogra_ | oh ! | 16:12 |
| longsleep | mvo_: ok great | 16:12 |
| ogra_ | shouldnt it set snappy_trial_boot ? | 16:12 |
| mvo_ | longsleep: or rolling for now, the fw_setenv/printenv is not working yet on 15.04 | 16:12 |
| ogra_ | i dont see that here | 16:12 |
| mvo_ | ogra_: ups, silly me | 16:12 |
| mvo_ | of course | 16:12 |
| ogra_ | is that snappys fault or uboots | 16:12 |
| ogra_ | oh, i see ... snappys | 16:13 |
| mvo_ | oh? | 16:13 |
| ogra_ | well, snappy needs to set it to 1 | 16:14 |
| mvo_ | set what to 1? | 16:14 |
| ogra_ | if test ${snappy_trial_boot} = 1; then | 16:14 |
| longsleep | ogra_: what channel should i use for rolling? | 16:14 |
| ogra_ | that wraps around the ab logic | 16:14 |
| mvo_ | ogra_: the bootloader sets this, snappy just resets it | 16:14 |
| mvo_ | ogra_: thats how its done in grub at least | 16:14 |
| ogra_ | oh, ok | 16:14 |
| mvo_ | ogra_: and its doing this, no? in the else setenv part? | 16:15 |
| ogra_ | setenv snappy_trial_boot 1 | 16:15 |
| ogra_ | bah | 16:15 |
| ogra_ | efocus | 16:15 |
| ogra_ | U-Boot# setenv snappy_trial_boot 1 | 16:16 |
| ogra_ | U-Boot# setenv snappy_mode try | 16:16 |
| ogra_ | U-Boot# setenv snappy_ab b | 16:16 |
| ogra_ | U-Boot# saveenv | 16:16 |
| ogra_ | lets see | 16:16 |
| ogra_ | sigh ... still a/ | 16:16 |
| longsleep | this logic is in uboot only / independent from the booted system isnt it? | 16:17 |
| mvo_ | hm, thats confing indeed "printenv snappy_ab | 16:17 |
| mvo_ | snappy_ab=b | 16:17 |
| mvo_ | " | 16:17 |
| mvo_ | but on boot it runs from a/ | 16:17 |
| ogra_ | longsleep, no, snappy adjusts the values after boot | 16:17 |
| longsleep | mhm i got an error when building the image - it failed to extract my oem snap. | 16:19 |
| mvo_ | ogra_: could it (uboot) read stuff from snappy-system.txt still? that has snappy_ab=a in there | 16:19 |
| ogra_ | mvo_, must be snappy that resets it ... snappy_trial_boot is actually completely gone from uboot.env after i booted ... | 16:19 |
| longsleep | snap failed to install unpack failed with exit status 1 | 16:20 |
| mvo_ | ogra_: yes, thats part of the firstboot job to unset it | 16:20 |
| ogra_ | while a saveenv on the uboot prompt (even witrhj a reset afterwards) has the var | 16:20 |
| ogra_ | mvo_, unset or set it to 0 ? | 16:20 |
| mvo_ | unset | 16:20 |
| mvo_ | remove | 16:20 |
| ogra_ | not good i think | 16:20 |
| mvo_ | I could change it so that it sets it to zero | 16:20 |
| mvo_ | why? | 16:20 |
| ogra_ | i think we need a boolean here | 16:21 |
| mvo_ | oh, ok | 16:21 |
| ogra_ | so we at least know the corruption is gone | 16:21 |
| ogra_ | i did like 20 boots now ... and each time uboot.env was modified | 16:21 |
| mvo_ | ogra_: easy to fix, but it does not explain why it boots a/ instead of b/ if you set it in the uboot prompt manually - or does it? | 16:21 |
| ogra_ | nope | 16:22 |
| mvo_ | ogra_: yay! corruption free booting | 16:22 |
| ogra_ | i wonder if its a quoting issue | 16:22 |
| ogra_ | U-Boot# setenv snappy_boot if test "${snappy_mode}" = "try"; then if test "${snappy_trial_boot}" = 1; then if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; else setenv snappy_ab "a"; fi; else setenv snappy_trial_boot 1; saveenv; fi; fi; run loadfiles; setenv mmcroot /dev/disk/by-label/system-${snappy_ab} ${snappy_cmdline}; run mmcargs; bootz ${loadaddr} ${initrd_addr}:${initrd_size} ${fdtaddr} | 16:23 |
| ogra_ | syntax error | 16:23 |
| ogra_ | wow | 16:23 |
| longsleep | put single quotes around the value | 16:24 |
| kyrofa | seb128, I'm making an MP to get unity-scope-snappy into the Personal seed (thanks for pushing that through!) | 16:24 |
| seb128 | kyrofa, yw! | 16:24 |
| kyrofa | seb128, but as I mentioned previously, it does depend upon WebDM | 16:24 |
| seb128 | did it work out of the box? I didn't try yet | 16:24 |
| kyrofa | seb128, which is only a snap | 16:24 |
| longsleep | mvo_: so - when i try to build the image with rolling it gives me an error that my oem snap fails to install. Any idea? | 16:25 |
| seb128 | so if you snappy install webdm it should work? | 16:25 |
| ogra_ | not a quoting issue then ... still boots from a ... :/ | 16:25 |
| longsleep | mvo_: 15.04 creates image fine with the same oem snap | 16:25 |
| kyrofa | seb128, normally yes, but webdm isn't in the Personal channel, so you have to sideload it. But then, yes :P | 16:25 |
| mvo_ | longsleep: are you on trusty ? latest tools from the ppa:snappy-dev/tools ? | 16:25 |
| seb128 | kyrofa, can you get it in the personal channel? | 16:25 |
| longsleep | mvo_: i am on vivid - let me check if there are updates | 16:25 |
| seb128 | unsure how to do that | 16:25 |
| mvo_ | longsleep: oh, ok. maybe its a issue with rolling then, I'm not aware of one though | 16:25 |
| * mvo_ needs to get some dinner, bbiab | 16:26 | |
| kyrofa | seb128, I pinged sergiusens about it last week, but apparently he just had a baby | 16:26 |
| kyrofa | Maybe rsalveti can help us here | 16:26 |
| seb128 | oh, ok | 16:26 |
| seb128 | sergiusens, congrats ;-) | 16:26 |
| mvo_ | longsleep: aha, I think its a race or something, I had this too | 16:26 |
| mvo_ | longsleep: no, meh, I think its something else | 16:27 |
| kyrofa | seb128, so let's pretend it's in the Personal channel. Can I modify something else in this branch to make sure it's included, or is it something special we're going to have to add to the u-d-f incantation every time we make an image? | 16:28 |
| seb128 | kyrofa, no idea, that's an udf/sergiusens question | 16:28 |
| kyrofa | seb128, alright, so you're not preloading any snaps at the moment then? | 16:29 |
| longsleep | mvo_: http://paste.ubuntu.com/11920858/ that shows both outputs | 16:29 |
| mvo_ | longsleep: yeah, I think its "failed to find user uid/gid" thats the culprit | 16:30 |
| kyrofa | seb128, alright, I should probably hold off on adding this to the seed until it works out of the box, yes? | 16:30 |
| longsleep | mvo_: ok - is that something i could change in my snap? | 16:30 |
| mvo_ | unfortunately not, let me build you a new 15.04 image for now until this issue is fixed | 16:31 |
| longsleep | mvo_: that would be awesome | 16:31 |
| * longsleep wonders how ogra_ did it | 16:31 | |
| kyrofa | seb128, perhaps I'll make an MP, but make a note of the prerequisite? | 16:31 |
| longsleep | mvo_: do you want me to add the issue to the tracker? | 16:32 |
| mvo_ | longsleep: yes, set it to critical please, I think its because we renamed the snap user from clickpkg to snappypkg in rolling | 16:32 |
| longsleep | mvo_: ok | 16:32 |
| ogra_ | longsleep, i'm testing 15.04 rolling here | 16:33 |
| mvo_ | longsleep: but I need to double check, I have a vague memory of fixing it but maybe the fix was not promoted from ppa:snappy-dev/tools-proposed to tools, you might check if tools-proposed has a update for ubuntu-device-flash | 16:33 |
| mvo_ | but in any case, image build with /etc/fw_env.config triggered | 16:33 |
| mvo_ | and dinner! | 16:33 |
| * ogra_ doesnt care much about wily atm ... | 16:33 | |
| ogra_ | i just want that stable image done | 16:33 |
| longsleep | sure - so why did i test wily then? Set channel to rolling and release to 15.04 should give me all the new stuff? | 16:34 |
| seb128 | kyrofa, that image is experimental, we can document that webdm should be installed and how... | 16:34 |
| kyrofa | seb128, perfect, making the MP | 16:34 |
| seb128 | kyrofa, no, we are not proloading any snap atm, I don't know how to do that/didn't look at it | 16:34 |
| seb128 | kyrofa, thanks | 16:35 |
| ogra_ | longsleep, yes ... we need to test wily too though + | 16:35 |
| ogra_ | but for now i want that stable image out first | 16:35 |
| longsleep | rolling not found on server. | 16:35 |
| ogra_ | and i didnt really plan to do a late shift today, damned | 16:35 |
| ogra_ | sudo ubuntu-device-flash core --channel=edge --oem beagleblack_1.9_all.snap --developer-mode -o bbb.img 15.04 | 16:36 |
| ogra_ | longsleep, ^^^ edge ... sorry | 16:36 |
| longsleep | ah edge | 16:36 |
| longsleep | :D | 16:36 |
| ogra_ | U-Boot# setenv snappy_ab b | 16:37 |
| ogra_ | U-Boot# run loadfiles | 16:37 |
| ogra_ | reading b/vmlinuz | 16:37 |
| ogra_ | GRRRR | 16:37 |
| ogra_ | why does that work | 16:37 |
| ogra_ | (and why doesnt it if snappy_boot calls the same) | 16:37 |
| longsleep | mvo_: i just added bug 1477224 - but i do not seem to be able to set to critical | 16:39 |
| ubottu | bug 1477224 in Snappy "OEM snap does not install when building image for rolling" [Undecided,New] https://launchpad.net/bugs/1477224 | 16:39 |
| longsleep | ogra_: ok i got an image edge version 125. That looks good? | 16:39 |
| ogra_ | yup | 16:40 |
| ogra_ | thats what i use here | 16:40 |
| mterry | mvo_, sorry, was out for lunch. About fixtures and tarmac... That would involve not just a manual merge, but turning off tarmac altogether, as other merges would be blocked too, if trunk required fixtures | 16:40 |
| ogra_ | hmm, so manually setzting snappy_ab to b and snappy_trial_boot to 1 and then running run snappy_boot works fine | 16:42 |
| ogra_ | it properly boots from b | 16:42 |
| ogra_ | i dont get that | 16:42 |
| longsleep | maybe its an order thing | 16:42 |
| ogra_ | why would it work on the uboot prompt then ? | 16:42 |
| longsleep | mhm | 16:42 |
| longsleep | no idea :) | 16:42 |
| ogra_ | (and why did it work before when we tested it) | 16:42 |
| ogra_ | U-Boot# setenv snappy_trial_boot 1 | 16:44 |
| ogra_ | U-Boot# if test "${snappy_trial_boot}" = 1; then echo foo; fi | 16:44 |
| ogra_ | foo | 16:44 |
| ogra_ | works just fine too | 16:44 |
| longsleep | what about env print snappy_trial_boot | 16:45 |
| longsleep | does that show 1 ? | 16:45 |
| ogra_ | not by default | 16:45 |
| ogra_ | but yes, if i set it | 16:45 |
| longsleep | so what is the problem? | 16:46 |
| ogra_ | U-Boot# printenv snappy_ab | 16:46 |
| ogra_ | snappy_ab=a | 16:46 |
| longsleep | i just finished fusing - so lets see if i can reproduce | 16:46 |
| ogra_ | U-Boot# if test "${snappy_ab}" = "a"; then setenv snappy_ab "b"; fi | 16:46 |
| ogra_ | U-Boot# printenv snappy_ab | 16:46 |
| ogra_ | snappy_ab=b | 16:46 |
| ogra_ | grmbl | 16:46 |
| ogra_ | so that bit is ok as well | 16:46 |
| ogra_ | longsleep, the prob is that no matter what i set, it always boots from a | 16:47 |
| longsleep | ok so mine booted just fine - what should i try? | 16:47 |
| longsleep | ah | 16:47 |
| longsleep | ok | 16:47 |
| ogra_ | unless i do it manually | 16:47 |
| ogra_ | by calling run snappy_boot after setting the vars | 16:47 |
| longsleep | how do you set something not manually? | 16:48 |
| longsleep | mine now is booted from a | 16:48 |
| ogra_ | i set it, call saveenv and call reset | 16:48 |
| longsleep | ah ok | 16:48 |
| longsleep | let me try that | 16:48 |
| ogra_ | or i set it and run snappy_boot | 16:48 |
| ogra_ | the latter works | 16:48 |
| ogra_ | the former doesnt | 16:48 |
| longsleep | what should i set? snappy_mode to try? | 16:49 |
| ogra_ | snappy_mode try ... snappy_ab b .... and snappy_trial_boot 1 | 16:49 |
| longsleep | right - booted from a for me too | 16:50 |
| ogra_ | yeah | 16:50 |
| ogra_ | oh, wait | 16:50 |
| ogra_ | do we actually need to set snappy_ab at all ? | 16:50 |
| longsleep | well depends what you want | 16:51 |
| * ogra_ tries without it ... | 16:51 | |
| longsleep | it changes to the other at some point | 16:51 |
| ogra_ | i dont think we touch that var normally | 16:51 |
| longsleep | dependend on the other vars | 16:51 |
| ogra_ | exactly | 16:51 |
| ogra_ | only snappy_trial_boot and snappy_mode | 16:51 |
| * ogra_ taps foot waiting for cloud init | 16:51 | |
| longsleep | it fast on the odroid | 16:52 |
| longsleep | rather fast | 16:52 |
| ogra_ | \o/ | 16:52 |
| longsleep | i can confirm that the system did set snappy_mode to regular and it sems to have removed snappy_trial_boot | 16:53 |
| ogra_ | me has it booting from b with only the two vars touched | 16:53 |
| longsleep | yes works here too | 16:53 |
| longsleep | if i only change those two it boots from b | 16:53 |
| ogra_ | which is indeed logical :) | 16:53 |
| ogra_ | right | 16:54 |
| ogra_ | and if you change them again it shoudl switch back | 16:54 |
| ogra_ | and so it does !° | 16:54 |
| ogra_ | yay | 16:55 |
| ogra_ | and still no corruption | 16:55 |
| slangasek | ogra_: g-* was meant to happen overnight, but apparently I didn't hit the right key before going to bed :P | 16:55 |
| ogra_ | i guess we can call that a success | 16:55 |
| longsleep | yes - changing back works here too | 16:55 |
| longsleep | great | 16:55 |
| * ogra_ needs to wait for mvo to return to confirm snappy itself doesnt tinker with snappy_ab | 16:56 | |
| ogra_ | but yay ... we have grub and uboot unified !!! | 16:56 |
| longsleep | very nice indeed! | 16:56 |
| ogra_ | now we just need to convince both upstreams to also merge theior code :) | 16:57 |
| ogra_ | slangasek, lol | 16:57 |
| ogra_ | i actually had to look up what i had said to trigger your answer :) | 16:58 |
| ogra_ | rsalveti, so confirmed that there is no fat corruption anymore ... i just need one final confirmation from mvo and we are good | 16:59 |
| longsleep | ogra_: https://github.com/longsleep/snappy-odroidc/tree/uboot-env-support branch has all the gear to build oem and device for ODRODIC using the new .env file - if you want to give it a try see how my uEnv.txt and .env.in look now. | 17:00 |
| rsalveti | ogra_: that's great, can you promote latest edge to alpha so we can test the update/rollback a bit more in there? | 17:00 |
| ogra_ | rsalveti, one thing missing in the current rootfs, mvo has triggered a build with a fix | 17:00 |
| rsalveti | want to give it a shot in a few | 17:00 |
| ogra_ | waiting for that | 17:00 |
| rsalveti | ogra_: oh, great | 17:00 |
| ogra_ | (fw_setenv/printenv config was missing in 15.04 --- so you cant tinker with the config from the runnng system) | 17:01 |
| longsleep | it is there in the image i just built | 17:01 |
| ogra_ | oh, so the rootfs is already there ? | 17:01 |
| longsleep | ah the config | 17:01 |
| longsleep | sorry | 17:01 |
| * ogra_ tries | 17:01 | |
| longsleep | no - i thought you mean the commands | 17:02 |
| ogra_ | yeah /etc/fw_something | 17:02 |
| longsleep | yes that still is missing | 17:02 |
| longsleep | sorry | 17:02 |
| ogra_ | the commands dont work at all without that | 17:02 |
| longsleep | yeah - thats one reason why the go tool would be nicer | 17:02 |
| === retrack is now known as Guest25941 | ||
| ogra_ | (though i would have preferred to just includethe uboot-go tool instead ... the fw_ stuff is so fragile) | 17:02 |
| longsleep | +1 | 17:03 |
| rsalveti | kyrofa: to include webdm by default I'd assume we need to change the oem itself | 17:15 |
| rsalveti | since it's a snap package | 17:16 |
| kyrofa | rsalveti, ah, good to know. But I think we need it in the Personal channel first, right? | 17:16 |
| kyrofa | rsalveti, last I checked, it was only in Core | 17:16 |
| rsalveti | do we have another channel dedicated just for personal? | 17:23 |
| rsalveti | never used personal | 17:23 |
| ogra_ | a whole image | 17:24 |
| * ogra_ forgot what he did to build personal | 17:24 | |
| ogra_ | but you need the u-d-f that suports the "personal" keyword | 17:24 |
| ogra_ | ubuntu | 17:25 |
| ogra_ | grrr !!!! | 17:25 |
| * ogra_ wants FFB (focus follow brain) | 17:25 | |
| mterry | rsalveti, is sergiusens away? | 17:29 |
| ogra_ | ubuntu | 17:29 |
| ogra_ | ubuntu+ | 17:29 |
| ogra_ | GODDAMNED ! | 17:30 |
| mterry | ogra_, :) | 17:30 |
| ogra_ | mterry, he had a kid (and now he has insomnia) | 17:30 |
| mterry | ogra_, oh right! the child! | 17:30 |
| ogra_ | back next week (perhaps ...) | 17:30 |
| rsalveti | mterry: yeah, back on monday | 17:30 |
| * mterry has amnesia himself | 17:30 | |
| mterry | mvo_, maybe we better manually merge snapcraft indeed for a couple days | 17:31 |
| mterry | mvo_, just involves me running tests instead of tarmac, not that different | 17:31 |
| jobot | Hi, I have owncloud installed on snappy (beaglebone black). I would like to point the storage to a usb drive. I have manually mounted the drive. and did a chown ubuntu:ubuntu. But, when I mount usb to the folder (as root because I have too?), the ownership changes, and becomes unwritable. Ownloud gives this: Can't create or write into the data directory /home/ubuntu/owncloud. Any advice appreciated. Thanks | 17:32 |
| ogra_ | jobot, format the dirve ... create a label on it "writable" ... then copy the content from the writable partition on the SD to that ... and delete the writable partition of the SD (or just remove the label) | 17:33 |
| rsalveti | if blocked by tarmac might just be easier to merge by hand | 17:33 |
| rsalveti | until we have our own tarmac that elopio and federico are working on | 17:33 |
| jobot | @ogra_ , thanks. Does that mean I need to recreate any symlinks to the usb or does that get detected automatically? | 17:35 |
| nothal | jobot: No such command! | 17:35 |
| elopio | rsalveti: I can put a tarmac in canonistack now, but I would have to create a new tarmac-snappy user as I don't have the credentials for the existing one. | 17:35 |
| elopio | I'd prefer to wait and use the same one. | 17:35 |
| rsalveti | yeah, no need to rush | 17:35 |
| ogra_ | jobot, the USB disk simply takes over the writable bits of the SD then yu dont need any symlinks or anything with that method | 17:35 |
| ogra_ | rsalveti, a and b contents are identical on the BBB image, right ? | 17:36 |
| ogra_ | if i didnt upgrade anything i mean | 17:36 |
| jobot | ogra_, thank you. I will give it a go. | 17:36 |
| rsalveti | ogra_: after flashing, yes | 17:37 |
| ogra_ | well, indeed | 17:37 |
| ogra_ | funny then | 17:37 |
| ogra_ | i reliably get "[ 20.580754] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517" 8 times in the log when booting from b | 17:38 |
| ogra_ | it never shows when booting from a | 17:38 |
| jobot | Second question: is it possible to have the usb encrypted and mountable easily? | 17:39 |
| ogra_ | not yet ... | 17:39 |
| ogra_ | (it is definitely planned to support all kinds of disk encryption, but not implemented yet) | 17:39 |
| jobot | ok cool thanks | 17:40 |
| ogra_ | mvo_, livecd-rootfs seems to have promoted, i trigered a new 15.04 image build now | 17:43 |
| ogra_ | +g | 17:44 |
| mterry | tedg, poke about the questions you had in focused-assemble, got a sec? | 17:59 |
| rsalveti | jobot: just remember that after you migrate the writable content you'd need to keep the usb stick around | 18:04 |
| rsalveti | we definitely need a better way to handle usb storage devices | 18:05 |
| jobot | rsalveti: good point. thanks ! | 18:05 |
| ogra_ | rsalveti, well, i think moving writable to USB stick is a valid workaround for the moment :) | 18:08 |
| ogra_ | (or even tio the 3TB external rotary USB disk) | 18:09 |
| ogra_ | thats the beauty of using labels :) | 18:09 |
| rsalveti | sure | 18:12 |
| ogra_ | the new image weems to be up ... (at least udf downloads something) | 18:12 |
| ogra_ | *seems ... | 18:13 |
| * ogra_ will need a break shortly | 18:13 | |
| mvo_ | ogra_: snappy itself does not tinker with snappy_ab - well, the code does but it has no affect, on bootsuccess snappy_ab=a it sets it to … "a" :P which is silly as its already set to a (and values that are already set to the same value are not written) | 18:48 |
| mvo_ | ogra_, longsleep: I'm happy to add the uboot-go binary, its just so huge (~2mb or so) :/ | 18:49 |
| mvo_ | mterry: yeah, maybe we do it manually, I have access to tarmac but can not install stuff on the tarmac instance. and sergio is using unattended-upgrades so I can't help myself with the root access either :/ | 18:50 |
| mterry | mvo_, I merged one thing automatically already, but hit a snag with one of yours -- commented on it | 18:50 |
| mvo_ | elopio: I have access to the tarmac instance, I can get the creds I think | 18:50 |
| mvo_ | ogra_: \o/ | 18:51 |
| mvo_ | mterry: oh, I have a look, thanks | 18:51 |
| * mvo_ has finished reading backlog | 18:51 | |
| mvo_ | longsleep: does it mean the uboot.env stuff is working now ? what was the issue that ogra was seeing, do you know? | 18:51 |
| ogra_ | mvo_, all working :D | 18:53 |
| * ogra_ is just playing with image 126 here | 18:53 | |
| ogra_ | http://paste.ubuntu.com/11921381/ properly switches back and forth between a and b | 18:53 |
| ogra_ | oh | 18:55 |
| ogra_ | crap | 18:55 |
| ogra_ | no, it doesnt anymore | 18:55 |
| ogra_ | damned | 18:56 |
| ogra_ | reading uboot.env | 18:56 |
| ogra_ | ERROR: Cannot import environment: errno = 22 | 18:56 |
| ogra_ | mvo_, :((( | 18:56 |
| ogra_ | at ../common/env_common.c:221/env_import() | 18:57 |
| ogra_ | *** Warning - import failed, using default environment | 18:57 |
| ogra_ | mvo_, i had it working by manually adding the config to image 125 ... now it completely broke in 126 ... and i have not the slightest idea why | 18:58 |
| rsalveti | ouch | 18:58 |
| rsalveti | can you check the vfat partition? | 18:58 |
| ogra_ | fatls lists everything fine ... | 18:59 |
| ogra_ | it also looks different from the corruption errors | 18:59 |
| ogra_ | (and i really cant focus anymore ... i need to stop soon) | 18:59 |
| ogra_ | i suspect it has somethign to do with the way the config is created ... thats the only difference we have | 19:00 |
| ogra_ | (the fw_setenv config) | 19:01 |
| elopio | mvo_: great, please send them to me. Also if you can copy the tarmac config, that would be handy. | 19:03 |
| mvo_ | ogra_: hm, errno 22 is invalid argument in linux at least, wonder if uboot is the same. not more infos? | 19:13 |
| mvo_ | ogra_: aha, nevermind, take a break :) | 19:13 |
| mvo_ | elopio: sure thing, or if you have a instance just add my ssh key and I scp everything over | 19:14 |
| mvo_ | elopio: and turn the other tarmac off | 19:14 |
| elopio | mvo_: your keys are imported, 10.55.32.109. | 19:25 |
| tedg | mterry, Just got back (long story) are you around now? | 19:26 |
| mterry | tedg, heyo | 19:57 |
| mterry | tedg, sorry, had a contractor come by to look at some winter damage | 19:57 |
| mterry | tedg, so I replied to you in merge comments, but wanted to drop to IRC to fully understand the issues in #2 (how snappy handles paths) | 19:58 |
| tedg | mterry, Hmm, I don't see the reply. Let me check LP. | 20:00 |
| tedg | mterry, So I guess that the snappy build does do that, but I'm not sure how I'd reference something in the path then. | 20:02 |
| mterry | tedg, I don't think you do, not at the snappy-command level | 20:03 |
| tedg | mterry, The QML plugin is setting up the PATH to include qmlscene | 20:03 |
| tedg | mterry, I don't want the project to care where qmlscene is installed | 20:03 |
| mterry | tedg, your plugin can install a thin wrapper that is basically "#!/bin/sh; qmlscene $*" or hardcode the qml there too if you know it | 20:04 |
| mterry | tedg, i.e. drop to shell in order to use PATH | 20:04 |
| mterry | And then have the user put your wrapper at the exec line | 20:04 |
| tedg | Sure, trying to avoid having everyone build a shell script | 20:04 |
| mterry | tedg, i.e. bin/qmlplugin myqmlfile.qml | 20:04 |
| mterry | tedg, well the user wouldn't do it | 20:05 |
| tedg | ? | 20:05 |
| mterry | tedg, or you could basically just have the plugin install a symlink | 20:05 |
| mterry | tedg, I'm trying to think of ways for you to have users not care about where your plugin puts qmlscene | 20:05 |
| mterry | tedg, so I'm saying your plugin can put a symlink (or thin wrapper) somewhere in a place that you "own" and would tell users to run | 20:05 |
| tedg | mterry, They have to define the exec statement | 20:06 |
| mterry | tedg, so maybe that's a toplevel "runqml" symlink | 20:06 |
| mterry | tedg, or "bin/runqml" that users of your plugin put in the exec statement | 20:06 |
| mterry | tedg, (or you could just tell users to put usr/bin/qmlscene there) | 20:06 |
| tedg | I guess I don't understand why it has to be different than running it on my development system. | 20:06 |
| tedg | qmlscene foo.qml | 20:06 |
| mterry | tedg, snappy is a whole different thing man | 20:06 |
| mterry | tedg, that's just not how exec lines work | 20:06 |
| mterry | tedg, (unless you put a qmlscene symlink at the toplevel) | 20:07 |
| mterry | but at that point, you're just faking it so it looks like it's a PATH references | 20:07 |
| tedg | Snapcraft could fix that :-) | 20:07 |
| mterry | tedg, I mean, we basically do for everything *AFTER* that entry point | 20:07 |
| tedg | If you're pulling things in with teh Ubuntu plugin, you probably want them to be in the PATH (they are) so I think it makes sense to use them as such. | 20:07 |
| mterry | tedg, but that entry point itself is a snappy thing, and is a relative path | 20:08 |
| tedg | So I'm saying that the snapcraft wrapper should allow using the PATH that is already in that same wrapper. | 20:08 |
| tedg | (which if you're using Ubuntu, it is) | 20:08 |
| mterry | tedg, ... so you want in your case of 'qmlscene', you want snapcraft to make a 'qmlscene.wrapper' file at, I dunno, the toplevel, which which assumes that the exec line was not in fact a standard snappy exec line but actually a PATH reference. I'm leery of doing that as a matter of course. And it feels silly to have an option for that | 20:10 |
| mterry | tedg, maybe if we detect that the file doesn't exist | 20:10 |
| mterry | tedg, and we could check all the PATH locations.... | 20:11 |
| mterry | tedg, find it, and stuff that into the exec line instead | 20:11 |
| mterry | tedg, that's awfully magic | 20:11 |
| mterry | tedg, just to avoid people learning a tiny bit about how snappy works :) | 20:11 |
| mterry | tedg, but it seems like a harmless feature to add | 20:11 |
| mterry | tedg, but I'm comfortable making that a separate branch :) | 20:12 |
| tedg | mterry, Heh, okay. | 20:12 |
| tedg | mterry, I'm not sure if we need to search the PATH, I think we can just assume the path if it doesn't exist. | 20:12 |
| mterry | tedg, it is a decent way to avoid what may be a common problem for people unused to snappy, indeed. I'll file a bug | 20:13 |
| mterry | tedg, well, someone may have legitimately made a typo or not understood something. We know what the PATH will be at that point, so it's harmless to check | 20:13 |
| mterry | tedg, though maybe it will be hard to know what is in Core vs the snap, if the first command is a Core exec | 20:13 |
| tedg | mterry, We'd have to run it through a shell, we're not actually evaluating the PATH. | 20:13 |
| tedg | I think the point of Snappy is "assume nothing is core" right? ;-) | 20:14 |
| mterry | tedg, we can parse all the env vars that are PATH= that the plugins give us into the snap | 20:14 |
| mterry | tedg, yeah but what if the first exec fragment is "env" | 20:14 |
| mterry | tedg, maybe that's just not allowed (it wouldn't be by base snappy I don't think) | 20:14 |
| tedg | mterry, Heh, then right now you'll rewrite it as "$SNAP_APP_PATH/env" ;-) | 20:15 |
| mterry | tedg, which is what snappy itself would do. I don't think that's a bug in the current instance | 20:15 |
| mterry | tedg, I was just seeing if we could be more magic there for the user. But I don't think we want to in that case | 20:15 |
| mterry | tedg, how about https://bugs.launchpad.net/snapcraft/+bug/1477286 ? | 20:20 |
| ubottu | Launchpad bug 1477286 in Snapcraft "Support PATH-resolved commands in exec lines" [Undecided,New] | 20:20 |
| mterry | tedg, and credited you in a comment :) | 20:21 |
| tedg | mterry, Heh, that works. | 20:21 |
| mterry | tedg, I also have a bunch of source-option branches if you're feeling review-y | 20:24 |
| tedg | mterry, Sure, source-options, more-source-options? | 20:26 |
| mterry | tedg, and source-tarball | 20:26 |
| elopio | mterry: did you need any other package installed in tarmac, in addition to python3-fixtures? | 20:26 |
| mterry | elopio, I will also probably need git, bzr, and xz-utils (if they aren't already there) | 20:27 |
| mterry | tedg, source-* options may change in further spec discussions too. I just wanted something in place to not block people and other work. All yaml is changeable :) | 20:42 |
| mterry | tedg, and I admit that git isn't my first language. I just did something I found would work. I miss bzr's easy to understand revnos | 20:43 |
| tedg | mterry, Yeah, at least Linus admitting not having them was a mistake :-) | 20:47 |
| tedg | Cool, let me get qml updated for trunk. (and see if it still works :-) ) | 20:51 |
| mterry | tedg, you're right... I'll make a little unit test for isurl | 20:53 |
| mvo_ | ogra_: for tomorrow, one data point with r126 and the corruption is that I see is that there is a "=b" entry in printenv. I can get that by typing "setenv "" b; saveenv" in the u-boot prompt and I wonder if somehow something in our bootscript sets a empty var to b. something like "setenv $some_var_that_is_not_defined b; saveenv" or something. once there is a empty key in the uboot env it seems it can no longer load the file. but looking at uboot | 20:53 |
| mvo_ | .env.in I don't see anything like this | 20:53 |
| mvo_ | ogra_: so manybe/probably a wrong theory | 20:53 |
| ogra_ | mvo_, i noticed that i have an 8 byte header on the unreadable file | 20:54 |
| mvo_ | ogra_: could you pastebin the hexdump -C uboot.env |head output please? | 20:55 |
| ogra_ | mvo_, i'll check the quoting tomorrow, it isnt consistent in snappy_boot ... | 20:55 |
| ogra_ | mvo_, http://paste.ubuntu.com/11922519/ | 20:55 |
| mvo_ | ogra_: the "=1" is a key=value, the key is just empty, should not happen of course and I wonder what is triggering it | 20:56 |
| ogra_ | mvo_, then i'm sure it is the quoting in snappy_boot ... i changed some bits in 125 when i tested it | 20:57 |
| mvo_ | ogra_: it could be, yeah, I managed to corrupt my file in a similar way with setenv "" x ; saveenv in the uboot prompt | 20:58 |
| ogra_ | (because i couldnt use fw_setenv initially) | 20:58 |
| mvo_ | ogra_: there is something funny with the fw_setenv in 15.04 | 20:58 |
| mvo_ | ogra_: I have strange issues here too | 20:58 |
| ogra_ | well, it worked for at least 50 boots for me with 125 | 20:58 |
| ogra_ | i didnt have any comments in my config ... thats the only difference on that layer | 20:59 |
| mterry | tedg, thanks for the reviews! | 20:59 |
| mvo_ | ogra_: hm, hm, if it worked in 125 and no longer in 126 its probably something else | 20:59 |
| ogra_ | (i actually wonder if fw_*'s config handling is comment safe :=) | 20:59 |
| mvo_ | ogra_: haha | 20:59 |
| ogra_ | well, I#ll re-work tezh snappy_boot command tomorrow morning i know it can work for 50 boots without any issue | 21:00 |
| mvo_ | ta, lets check it out tomorrow and I let you kow if I notice anything | 21:00 |
| ogra_ | now it breaks reliably the third boot | 21:01 |
| mvo_ | ogra_: and I remove the comments | 21:01 |
| ogra_ | heh, i wasnt actually serious :) | 21:01 |
| mvo_ | I know | 21:01 |
| mvo_ | but I am ;) | 21:01 |
| mvo_ | every 3 boots you say? | 21:01 |
| ogra_ | i'm pretty sure its snappy_boot that breaks us | 21:01 |
| ogra_ | well, when switching back from b to a | 21:01 |
| mvo_ | snappy_boot in snappy-go ? or in the bootloader itself? | 21:02 |
| ogra_ | in uboot.env | 21:02 |
| ogra_ | its a var | 21:02 |
| mvo_ | aha | 21:02 |
| ogra_ | the thing that carries the a/b logic | 21:02 |
| ogra_ | i already noticed the quoting is pretty inconsistent, that needs fixing anyway | 21:02 |
| mvo_ | ogra_: ok, lets hope that its that and I will get some rest :) | 21:03 |
| ogra_ | http://paste.ubuntu.com/11922551/ | 21:03 |
| ogra_ | oh man | 21:04 |
| ogra_ | i see whats wrong ... after the setenv snappy_ab "a" and snappy_ab "b" there needs to be a saveenv indeed | 21:04 |
| mvo_ | ogra_: nice, hope its that. here is what I see when its broken: | 21:06 |
| mvo_ | fw_printenv|cut -f1 -d=|sort|head | 21:06 |
| mvo_ | arch | 21:06 |
| mvo_ | meh, http://paste.ubuntu.com/11922579/ is better. a empty key in the first line | 21:07 |
| ogra_ | wow | 21:07 |
| ogra_ | perhaps we should really take uboot-go instead | 21:07 |
| ogra_ | even if it costs 2M | 21:08 |
| mvo_ | might be me corrupting it, I just don't know right now :/ | 21:08 |
| mvo_ | ogra_: this is what I did: http://paste.ubuntu.com/11922587/ | 21:09 |
| ogra_ | well, thats wrong | 21:09 |
| ogra_ | though it shouldnt break anything | 21:09 |
| ogra_ | you want to set snappy_trial_boot 1 ... not snappy_ab b | 21:10 |
| ogra_ | setting snappy_ab happens inside the bootloader later | 21:10 |
| mvo_ | ogra_: snappy_trial_boot is what the bootloader sets itself, snappy just cleans that | 21:10 |
| mvo_ | ogra_: at least thats how grub is doing it | 21:11 |
| ogra_ | well, see the snappy_boot command i pasted above | 21:11 |
| ogra_ | it checks for that being set | 21:11 |
| mvo_ | yeah, it uses that to detect that the boot failed, i.e. if its in "try" mode and it has not booted successfully (trial boot is set) it will revert back to the previous partition | 21:12 |
| ogra_ | hmpf, then i tested wrong | 21:13 |
| mvo_ | so when the bootloader sees try it will set trial_boot=1 and then booted OS is expected to clean that | 21:13 |
| mvo_ | its confusing :/ | 21:13 |
| ogra_ | i did set snappy_trial_boot to 1 and snappy_mode to try | 21:13 |
| mvo_ | that should be ok, that simulates the fallback to the other patition | 21:14 |
| ogra_ | ok | 21:14 |
| mvo_ | with that it should simpliy toggle | 21:14 |
| mvo_ | or flip-flop :) | 21:14 |
| mvo_ | meh, I whish it would boot faster | 21:16 |
| ogra_ | cloud-init is a pain | 21:17 |
| ogra_ | and something still hangs with th NIC startup | 21:17 |
| mvo_ | ogra_: ok, the bug is on my turf, I just ran "snappy booted" manually and managed to trigger it without rebooting | 21:18 |
| mvo_ | ogra_: so its not uboot | 21:18 |
| ogra_ | P H E W ! | 21:19 |
| mvo_ | :) | 21:19 |
| mvo_ | oh, wait | 21:19 |
| mvo_ | :( | 21:19 |
| ogra_ | mvo_, i still dont get how it worked in 125 and stopped working in 126 | 21:22 |
| ogra_ | did you do a snappy upload alongside the livecd-rootfs one ? | 21:23 |
| * ogra_ thoguht adding the config was the only change | 21:24 | |
| Chipaca | mvo_: ogra_: you guys are up way past your bedtime | 21:28 |
| ogra_ | Chipaca, you not ? | 21:28 |
| Chipaca | I'm 1h behind you | 21:28 |
| Chipaca | and my eod is always late :) | 21:29 |
| ogra_ | (definitely hours before my bedtime though ... but far past my EOD time :) ) | 21:29 |
| Chipaca | also feeling a little bit guilty that the biggest problem i'm wrangling is around naming, and you guys are fighting uboot | 21:30 |
| Chipaca | but the feeling will pass i'm sure | 21:30 |
| ogra_ | hah, i like bootloader wrangling :) | 21:30 |
| mvo_ | ogra_: I can not find a way to trigger it reliable | 21:39 |
| ogra_ | hmpf | 21:40 |
| mvo_ | ogra_: I guess my best option for now is rest | 21:40 |
| ogra_ | yeah, same here ... we'll nail it tomorrow ... | 21:40 |
| * mvo_ waves | 21:40 | |
| mvo_ | indeed | 21:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!