=== ruchlos42 is now known as ruchlos
=== pesari_ is now known as pesari
=== xnox_ is now known as xnox
[14:50] <awe__> rtg ( or anyone else ), could you give me a hand with a snappy ripi2 kernel config question?
[14:50] <awe__> I'm trying to determine of if our latest rolling snappy image was built with a particular kernel option
[14:50] <apw> awe__, it is best to ask teh question, then we can poke people based on what the quesiton is
[14:50] <rtg> awe__, fire away
[14:51] <apw> awe__, installed kernels have a /boot/config-<version> with them
[14:51] <awe__> I have the source package downloaded, but am not sure how to figure out what config options were enabled when the binary package was built
[14:51] <awe__> on ripi2?
[14:51]  * awe__ looks again
[14:51] <rtg> awe__, we're talking raspi2, right ?
[14:51] <apw> all kernels we produce should ahve configs in the .deb
[14:51] <apw> awe__, but from the source tree you should be able to also "fakeroot debian/rules genconfigs"
[14:52] <awe__> yes, running our latest snappy rolling image
[14:52] <awe__> apw, cool that'll work!
[14:52] <apw> which will make the same config in CONFIGS/*
[14:52] <awe__> awesome
[14:52] <apw> but you need to be checked out at the right version obviously
[14:52] <awe__> I am
[14:52] <awe__> ;)-
[14:52] <apw> and it would still be better to get the one out of the binary .deb, as that _really_ _really_ was the one it used
[14:57] <awe__> not sure how I'd do that?
[14:57] <awe__> if it isn't in the binary deb?
[14:58] <awe__> by the way, generating worked great after I realized I needed to run it on a xenial image
[14:58] <awe__> thanks!
[15:01] <rtg> awe__, it is boot/config-4.3.0-1006-raspi2 in he binary deb
[15:01] <ogra_> apw, snappy doesnt support putting the config-$version into the snap ... which is why i enable on all arches the /proc/config.gz interface before giving my initial confiig to ppisati ... seems some script removes that again 
[15:01] <awe__> ok, and that's just not getting installed then?
[15:01] <ogra_> would be really helpful to keep that 
[15:01] <awe__> got it
[15:02] <awe__> sounds like something we should try to fix, but I'm good for now
[15:02] <awe__> just needed to verify a BT option
[15:02] <rtg> awe__, it is not 'cause these are intended for embedded systems
[15:02] <awe__> k
[15:03] <rtg> ogra_, same for config.gz, it just uses RAM
[15:03] <ogra_> a few bytes :) 
[15:05] <JanC> raspi2 has 1 GiB of RAM...
[15:06] <JanC> most Ubuntu desktop systems had no more (sometimes even less) in the early years...
[15:07] <JanC> :)
[15:08] <ogra_> yeah ... it is really neglectable 
[15:08] <ogra_> and common sense in the embedded world to have it 
[15:10] <JanC> alternatively, the used diskspace would not really be relevant either, I think?
[15:10] <JanC> especially if you would gzip it something
[15:11] <ogra_> yeah
=== arges_ is now known as arges
[15:53] <manjo> apw, PARTUUID works now 
[15:53] <manjo> apw, do you have a bug where I can post +1 ? 
=== bdmurray_ is now known as bdmurray
[16:26] <apw> manjo, your bug :)
[16:27] <manjo> apw, oh crap  yeah :) 
[16:28] <apw> manjo, and you can remind me of the number :)
[16:29] <manjo> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1531928
[16:29] <ubot5`> Launchpad bug 1531928 in initramfs-tools (Ubuntu) "[Xenial] root=PARTUUID=<partuuid> is not recognized as valid syntax." [High,In progress]
[16:35] <manjo> apw, added a note to that bug. Thanks aton! 
[16:45] <apw> manjo, thanks
[16:45] <ogra_> oh, why is that ? 
[16:45]  * ogra_ remebers adding code to udev in 14.10 or so to support PARTUUID
[16:46] <ogra_> (and in fact we rely on it heavily on phones)
[16:48]  * ogra_ wonders i9fr that never made it into the main distro .... if there is new/better code, the phone code should be replaced everywhere 
[17:32] <mauricfo> rtg, hey. if you have a chance.. on the xenial GA kernel.. will it ship as upstream tag v4.4 and no more, or it should include some more recent commits after v4.4 (e.g, up to a certain point in time) ?
[17:33] <rtg> mauricfo, it'll havea boatload of 4.5 backport commits as well as several stable updates
[17:36] <mauricfo> rtg, ok. so, if ppc64el cares about some specific commits, it'd be better to point them in the specific feature request/bugs now, just in case, or wait until some point to verify and then ask? (so not to generate noise on you guys)
[17:37] <rtg> mauricfo, I'd say do it sooner then later, especially if they are already in 4.5-rc
[17:37] <mauricfo> rtg, ok. thanks, tim!
=== sforshee` is now known as sforshee
=== cyphermox_ is now known as cyphermox
=== dannf` is now known as dannf