[05:54] <orby> what is the correct way to configure the ip address of a snappy ubuntu-core?
[05:55] <orby> in the same vein is there any special procedure for replacing the ubuntu account with a different admin user? or is it the same process as normal ubuntu?
[05:56] <orby> not really sure how configs live on with the imaging system
[10:16] <sergiusens> asac`, ogra_, hey, so the kernel plugin now seems to work; I am just getting "Cannot load shared library libudev.so.1" on boot; I know you were looking into that and I'm working from a cached version, so is it working now?
[10:16] <ogra_> sergiusens, yeah, i'm working on that
[10:16] <sergiusens> getting end to end working would be awesome :-)
[10:16] <sergiusens> ogra_, kudos to you for being great :-)
[10:16] <ogra_> there are bugs in fakechroot that i'm currently trying to hack around
[10:16] <sergiusens> the pieces are comming together
[10:17] <sergiusens> ogra_, this affects all arches, right? I'm trying on amd64 due to convenience
[10:17] <ogra_> yeah, it does
[10:17] <sergiusens> I guess I won't be able to try out the procedure on  a dragonboard until I get to linaro connect
[10:18] <ogra_> on arm64 the linker wasnt copied in at all, sorry, i did care for that first yesterday, should have done it the other way round :)
[10:18] <sergiusens> heh, no worries you never know what will break next until it breaks
[10:19] <sergiusens> and getting things out of the way is a good thing ;-)
[10:20] <sergiusens> ogra_, do you know out of hand if to get a nice kernel build from git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git I can go with kdefconfig on its own?
[10:20] <sergiusens> I'm afraid debian/rules does a lot of massaging in between, but maybe just to get a deb
[10:21] <ogra_> i dont thijk you can ... the config usually lives in the debian ir debian.$arch dir in ubuntu
[10:21] <ogra_> s/ir/or/
[10:21]  * sergiusens tries
[10:22] <ogra_> assembled by scripts (ande checked for required parameters) during build
[10:25] <sergiusens> ogra_, heh, the assembled by scripts means it is not there initially in a clone/checkout though :-)
[10:25] <ogra_> it is there, but in parts
[10:26] <ogra_> sergiusens, i though asac had asked the kernel team for their check scripts and included them in the kernel plugin
[10:27] <ogra_> after all we need to make sure that the required options are all set (systemd reqs., cgroups, squashfs etc etc)
[10:29] <sergiusens> ogra_, you mean this http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/debian/scripts/config-check ?
[10:29] <ogra_> sergiusens, yeah, there is another one though
[10:30] <sergiusens> ogra_, well we don't have that yet, but nothing says we can't force enable some features (to make it transparent)
[10:30] <ogra_> ah, mightr just be an input file
[10:30] <sergiusens> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/debian/scripts/misc/kernelconfig
[10:30] <ogra_> debian.$arch/config/annotations has the required options
[10:31] <ogra_> not sure which script exactly consumes it though
[10:31] <sergiusens> ogra_, that's a generated file though, not here http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/debian
[10:31] <ogra_> (these scriptrs are a maze of perl code )
[10:31] <sergiusens> yup
[10:41] <ogra_> sergiusens, ok, 0.7.32 should ship with libudev now
[10:42] <ogra_> oh, but i havent disabled the resize script yet, that might cause havoc on second boot
[10:42] <ogra_> (on the dragonboard only)
[11:24] <sergiusens> ogra_, heh; so I just need to create an os image now; I hope my bandwidth is good enough
[11:25] <sergiusens> ogra_, can you remind me mvo's branch for creating those?
[11:44] <ogra_> sergiusens, http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files
[11:45] <ogra_> sergiusens, but that means you need a fresh tarball too
[11:46] <ogra_> (which will take some time, the package is still in -proposed
[11:46] <ogra_> )
[11:51] <ogra_> i'll trigger a tarball build once it migrated
[11:51] <ogra_> heh, and having said that, it just did
[11:52] <sergiusens> ogra_, oh, ok; I'll wait for the rootfs build
[11:52] <ogra_> triggered
[11:52]  * sergiusens is still cloning from kernel.ubuntu.com
[11:53] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/
[11:53] <ogra_> (if you want to watch it)
[12:06] <sergiusens> ogra_, what else can I do :-P
[12:25] <sergiusens> ogra_, Receiving objects: 100% (4489986/4489986), 999.75 MiB | 119.00 KiB/s, done.
[12:25] <ogra_> all done
[12:25] <sergiusens> ubuntu kernel
[12:25] <sergiusens> wow
[12:25] <sergiusens> a shallow clone
[12:25] <ogra_> heh
[12:26] <sergiusens> ogra_, builders during the weekend are a joy!
[12:26] <ogra_> yeah :)
[12:29] <ogra_> so now i need to fix the resize script ... and i think we should have a script included in the initrd package that makes injecting modules and firmware an easy task
[12:29] <ogra_> (doing all the nasty depmod stuff for you etc)
[12:30] <longsleep> ogra_: _that_ would be awesome :)
[12:30] <sergiusens> ogra_, by mounting /lib/modules?
[12:31] <sergiusens> ogra_, oh, now I see
[12:31] <ogra_> sergiusens, just something like "inject-modules.sh /path/to/initrd.img /path/to/modules/dir"
[12:31] <ogra_> it would unpack, push the needed modules in, run depmod and re-pack
[12:31] <ogra_> since thats quite fiddly
[12:32] <sergiusens> ogra_, to replace https://github.com/sergiusens/snapcraft/blob/feature/1552168/kernel-plugin/snapcraft/plugins/kernel.py#L154
[12:32]  * ogra_ looks
[12:32] <sergiusens> ogra_, yeah, basically what is done there, maybe cleaner
[12:32] <ogra_> sergiusens, i see it uses modules.dep ... where would that come from ?
[12:32] <sergiusens> ogra_, so infinity talked about writing a "copy_module" thingie which would take care of copying the correct firmware
[12:32] <ogra_> (our kernel packages only run depmod from the postinst)
[12:33] <sergiusens> ogra_, the kernel build
[12:33] <ogra_> ah, i see. it is a source build
[12:33] <sergiusens> yeah, this is all source
[12:33] <sergiusens> using the upstream ubuntu kernel deb comes later
[12:34] <ogra_> well, that is the bit i need on the builders
[12:34] <ogra_> where we use packaged kernels
[12:35] <ogra_> hmm, do i see that right that you actually include *all* modules ?
[12:35] <ogra_> that will give you quite a bloated initrd in the end ...
[12:35] <sergiusens> ogra_, no just the modules listed
[12:36] <ogra_> after all you only want squashfs and vfat/nls as mandatory modules
[12:36] <sergiusens> ogra_, it only does a --show-depends for self.options.kernel_initrd_mods
[12:36] <sergiusens> which is in snapcraft.yaml
[12:36] <ogra_> ah, k
[12:37] <sergiusens> and I guess we can add mandatory modules here as an improvement; unless `show-depends` returns `builtin`
[12:37] <ogra_> yeah
[12:37] <ogra_> (i still think we shold just enforce squashfs to be builtin on all non distro kernels though)
[12:38] <ogra_> that way you wouldnt even need to re-pack the initrd at all :)
[12:38] <sergiusens> ogra_, heh, I'd say the same for fat
[12:38] <sergiusens> why create a module for something will always load
[12:38] <sergiusens> *that will
[12:39] <longsleep> sometimes it might not even be possible to build a kernel - but in my configs i include all the modules required for snappy directly in vmlinux - so should be good
[12:39] <ogra_> vfat is builtin in your distro kernel
[12:39] <ogra_> but the nls modules arent
[12:39] <longsleep> ah
[12:39] <ogra_> s/your/our/
[12:40] <longsleep> i am currently working on the Pine64 kernel config, i got nls,vfat and squashfs
[12:40] <ogra_> yeah, thats good
[12:40] <sergiusens> don't forget apparmor
[12:40] <ogra_> right, and the right cgroups options
[12:40] <longsleep> yeah - i did not backport that yet .. its crappy Kernel 3.10 again :)
[12:41] <ogra_> fun
[12:41] <longsleep> if you are interested - https://github.com/longsleep/linux-pine64/blob/pine64-hacks-1.2/arch/arm64/configs/sun50iw1p1smp_linux_defconfig
[12:41] <longsleep> no snappy yet, but i got a fully functional xenial image
[12:41] <ogra_> would be interesting to see if it works with the new snapcraft plugin;)
[12:42] <longsleep> will try it soon - an probably for odroid c2 as well if not somebody else will have done it when i find the time
[12:43] <longsleep> (c2 has Kernel 3.14 which is not much better ..)
[12:45] <sergiusens> ogra_, longsleep I am still missing dtb integration
[12:46] <sergiusens> going to work on that during my 12 flight that's just around the corner
[12:46] <ogra_> where are you atm ?
[12:46] <sergiusens> I hope I have everything ready to work offline though :-)
[12:46] <sergiusens> ogra_, Chile
[12:46] <ogra_> oh, not changed the continent yet
[12:46] <sergiusens> ogra_, bad connections, 12 hour layover here as well
[12:46] <ogra_> woah
[12:46] <sergiusens> ogra_, the flght leaving last night was fully booked
[12:46] <longsleep> sergiusens: dtb just needs to be copied to /boot or /media/boot for pine64,c1 and c2
[12:47] <sergiusens> so total travel time is 43 hours
[12:47] <longsleep> oh my
[12:47] <ogra_> woah
[12:47] <sergiusens> return is only 246 :-)
[12:47] <sergiusens> woops
[12:47] <sergiusens> 26
[12:47] <sergiusens> ogra_, it's fine, they have beds here; I
[12:47] <ogra_> heh
[12:47] <longsleep> i hope you can bring a battery to the cabin - last time they took mine away before boarding "too high capacity" ..
[12:48] <sergiusens> I'm only worried that I will arrive Monday 00:30 so no time to adapt to a new timezone and only 6 hours or less of sleep to get ready for a packed Monday
[12:48] <sergiusens> longsleep, I got upgraded to business ;-)
[12:48] <sergiusens> most planes here have plugs for long haul flights in economy though
[12:49] <longsleep> right if they work :)
[12:49] <sergiusens> heh, you have to checkout the awesome planes we have here :-)
[12:50] <sergiusens> in any case it is 12 hours to Sidney then 8 more to Bangkok
[12:50] <longsleep> well in business that should be ok :)
[12:50] <longsleep> did you get upgraded for both flights?
[12:50] <sergiusens> the first 12 are business
[12:51] <sergiusens> the remaining 8 are something else
[12:51] <longsleep> so when you land snapcraft has learned to build a perfectly fine device snap (or whatever it is called)?
[12:52] <sergiusens> kernel snap
[12:52] <sergiusens> longsleep, it already seems to be building correctly for amd64 except for that initrd thing ogra just uploaded
[12:53] <longsleep> sergiusens: thats good, i will finish up to build a classix xenial image for Pine64 this weekend amd then go snappy next week - i guess that will help a lot
[12:53] <sergiusens> nothing glamorous about this, but what the heck http://paste.ubuntu.com/15291572/
[12:54] <longsleep> what about building stuff for u-boots which do not support initrd.img or vmlinuz?
[12:55] <ogra_> not supported anymore
[12:55] <longsleep> i did not look into arm64 booting on snappy yet, but at least the kernel cannot be named vmlinuz can it?
[12:55] <ogra_> people need to use the u-boot patches for raw files and need to use the patches for the .env file
[12:56] <ogra_> we use the same patches on the dragonboard ... kernel is vmlinuz, initrd is initrd.img
[12:56] <longsleep> ok i see - i have some research to do then
[12:56] <longsleep> how do you build vmlinuz for arm64? Or is it just Image gzip compressed there?
[12:56] <ogra_> its like five lines in the build config to change usually
[12:56] <ogra_> mak zImage
[12:56] <ogra_> ?
[12:57] <ogra_> *make
[12:57] <longsleep> i was under the impression that is not supported on arm64 - probably got that wrong
[12:57] <ogra_> works fine on the dragonboard ...
[12:57] <ogra_> but i guess it is a matter of the u-boot implementation
[12:58] <ogra_> (and on what u-boot release you base initially)
[12:58] <longsleep> that too, but i thought that there is no self extractor code in the kernel on arm64
[12:59] <ogra_> http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/uboot.patch
[12:59] <longsleep> but i can already tell that it will be some work to get devices boot vmlinuz and initrd instead of uImage and uInitrd
[13:00] <longsleep> what is the u-boot command you boot with on dragonboard?
[13:00] <longsleep> bootz?
[13:00] <ogra_> booti i think
[13:01] <longsleep> ok thats good, but what i do not get is how booti works with vmlinuz but thats probably something i missed
[13:01] <ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/dragonboard/uboot.env.in
[13:01] <ogra_> thats our current dragonboard env
[13:02] <ogra_> booti ${linux_addr} ${ramdisk_addr}:${initrd_size} ${fdt_addr}
[13:02] <longsleep> thanks, looks good and pretty compatible to mainline u-boot
[13:03] <longsleep> though, i am far away from mainline on the pine64 at the moment :/
[13:03] <ogra_> yeah, thanks to the 96boards guys ...
[13:03] <ogra_> i think their stuff is already flowing upstream even
[13:04] <longsleep> right now, i need to use boota on pine64 and thus also do not have a vmlinuz nor a initrd.im, its all inside a android wrapped kernel.img
[13:04] <ogra_> oh ?
[13:04] <longsleep> i want to backport booti to the old u-boot eventually, might even be a requirement to get snappy running
[13:04] <ogra_> why dont you make u-boot that kernel.img then ?
[13:05] <ogra_> and just use the u-boot features
[13:05] <ogra_> thats what i do on the dragonboard
[13:05] <longsleep> sure, but regarding snapcraft support that will not work right
[13:05] <ogra_> http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files
[13:05] <ogra_> thats my basic boot setup (independent from snappy)
[13:05] <ogra_> (see the README for details)
[13:06] <longsleep> yes, i got a similar thing https://github.com/longsleep/build-pine64-image/tree/master/u-boot-postprocess
[13:06] <ogra_> the dragonboard also only supports android style booting by default
[13:06] <ogra_> lk -> kernel.img usually
[13:07] <ogra_> i just trun it into lk -> u-boot.img
[13:07] <longsleep> ok, but their u-boot supports booti already
[13:07] <ogra_> by pretending the u-boot.img is a kernel one
[13:07] <ogra_> yeah, indeed
[13:07] <ogra_> and you have neither booti nor bootz ?
[13:08] <longsleep> well bootz will not work with the Kernel i have as it does not have an extractor for gz, i have only the uncompressed image and put that into the android format
[13:09] <longsleep> it has bootz, but the bootz code does not have the hack to switch to 64-bit mode
[13:09] <ogra_> isnt that just a kconfig thing ?
[13:09] <longsleep> yes and no, there is just no aarch64 code for it in the kernel
[13:09] <ogra_> bah
[13:10] <longsleep> ogra_: thats the u-boot config i currently use btw https://github.com/longsleep/u-boot-pine64/blob/pine64-hacks/include/configs/sun50iw1p1.h
[13:11] <longsleep> everything should work out somehow, i was planning to backport booti from mainline u-boot including the world hack anyways to get rid of the android boot stuff
[13:12] <ogra_> sounds good
[13:12] <longsleep> longsleep@mose2:/media/longsleep/Storage/Pine64/build-pine64-image/linux-pine64$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION=-longsleep -j4 zImage
[13:12] <longsleep> make: *** No rule to make target 'zImage'.  Stop.
[13:12] <longsleep> :)
[13:12] <ogra_> oh my
[13:13] <longsleep> i did not even know that mainline Kernels now have a self extractor for aarch64
[13:13] <longsleep> because i did not look that is :)
[13:16] <longsleep> so for now, i would prefer if snappy/snapcraft would not be fixated to require vmlinuz or initrd.img or be fixed to those file names
[13:16] <longsleep> could make it much easier for platform adopters
[13:17] <ogra_> well, as long as you support uboot.env you should still be free to do what you want after all
[13:17] <longsleep> yeah, thats good then
[13:17] <ogra_> uboot.env is definitely essential though since snappy modifies it
[13:17] <longsleep> i alread added all the stuff for the env file including the redundant thing we figured out ages ago. I hope it did not change :)
[13:17] <ogra_> from userspace
[13:18] <ogra_> see the dragonboard patch ;)
[13:18] <ogra_> didnt change
[13:18] <ogra_> (and the option still has the typo upstream ;) )
[13:18] <longsleep> hehe ok great - then i think all is well
[13:31] <longsleep> ogra_: btw, do you know the reason why in Xenial the serial getty service starts after rc-local service? Seems wrong and is annoying.
[13:32] <longsleep> /lib/systemd/system/serial-getty@.service has After=rc-local.service
[13:38] <ogra_> nope, no idea
[13:39] <ogra_> but thats a getty ... you actually want all boot scripts to have run before you allow logins
[13:39] <ogra_> it's a bit weird to tie it to that specific service though
[13:41]  * ogra_ goes afk a bit 
[14:50] <sergiusens> ubottu, am I here?
[15:16] <sergiusens> ogra_, asac` http://paste.ubuntu.com/15293021/
[15:16] <sergiusens> it is alive!
[15:16]  * sergiusens prepares for boarding
[15:18] <zyga> sergiusens: congrats
[15:18] <zyga> sergiusens: have a safe trip
[15:19] <sergiusens> zyga, thanks, I just need it working on a dragon board now