=== zenlot_away is now known as zenlot [02:07] kgunn, kyrofa, snap is the new client, that just talks to the rest api; we're moving commands over to it [02:08] as they get feature-complete(ish) the old one is removed from snappy [04:27] Can anyone help with a question about snapcraft and "build packages" [04:28] I want to create a snap with lsusb and lspci. I think I would use "build packages" with snapcraft but I keet getting a "parts" error [04:29] btw I have not defined a "parts" section because I have no clue how to do that when all I want are packages [04:29] rather deb packages [04:33] I also read about using "stage-packages" but that makes even less sense to me given that I still have to have a "parts" section. [04:54] more clarification - I want to add the functionality of lsusb and lspci to snappy as its not installed. With that in mind, I am trying to build a snap that will install the two deb packages (and dependences) into the system so that I can run them from the command line [07:45] good morning [07:48] hey dholbach [08:10] salut didrocks === willcooke_ is now known as willcooke [09:12] morning [09:41] jdstrand, hey, if you have a chance to look at, it would be great https://github.com/ubuntu-core/snapcraft/pull/360/files [09:42] it is in nagging mode so most commands run (except 2) will nag [09:42] this is where my creativity ends [10:39] ppisati: hey [10:39] ppisati: do you have a moment to talk about the raspberry pi kernel [10:41] zyga: what's that [10:42] ppisati: I was trying to use video core specific modules and I found that we don't have them in our kernel [10:42] ppisati: specifically I was trying to use bits required to use the camera interface [10:42] zyga, which ones specifically ? [10:42] the camera ones should be there with the latest image [10:43] ogra_: oh? yesterday they were not [10:43] hmm [10:43] ogra_: vcsm [10:43] except .... [10:43] ogra_: and the lot [10:43] ogra_: I can make a proper list in a moment, just got my network back [10:43] zyga, the modules are in the kernel, but there was a bump of the bootloader required to make them used ... [10:43] i'm just wondering, i think i only updated it for 15.04 [10:43] ogra_: ohhh, can you do it for 16.04 as well [10:44] i'll try to find some time, no promises for today though [10:44] zyga: how do you use the camera? [10:44] zyga: because [10:44] ogra_: everything that is needed for this: https://github.com/raspberrypi/firmware/tree/master/hardfp/opt/vc [10:44] zyga: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1532217 [10:44] Launchpad bug 1532217 in linux-raspi2 (Ubuntu) "Can't modprobe bcm2835-v4l2 to use RPi2 camera module" [Undecided,New] [10:44] ppisati: not v4l2 [10:44] bug 1500755 [10:44] bug 1500755 in Snappy "bootloader firmware needs update to get vchiq working with 4.2" [High,Fix committed] https://launchpad.net/bugs/1500755 [10:44] ppisati: through the videocore apis [10:44] ppisati: the same way that raspian has this [10:45] zyga: someone alreaby opened a bug for it, and it was just a matter of modifying config.txt etc [10:45] ppisati, no, there was more [10:45] ppisati: using official rpi foundation libs (python wrappers for libbcm_host.so) [10:45] my fault, i only updated the 15.04 oem snap [10:45] ogra_,ppisati: I'd argue that for a complete system we should also ship all those binary libs in our kernel snap [10:45] on 16.04 the firmware is outdated [10:45] or each snap will need them as well [10:46] I haven't checked, maybe that part is actually open source so we can also build it [10:46] zyga, i'm about to trigger a discussion on the ML foir that today [10:46] ogra_: fantastic, I'll chime in [10:46] i'm not familiar with the videocore api [10:46] (more about graphics drivers, but that should include these libs too) [10:46] ogra_: I'm trying to get all the pi2 specific hardware to work with interfaces [10:46] zyga: what's the userland bin that you use to take picture? [10:46] zyga: raspistill? [10:47] ppisati, ogra_: it's actually very closely related, lots of OpenMAX libs [10:47] ppisati: no, I was using the library directly, but it's all the same, raspistill is a good test for this [10:47] zyga: ok then, can you take a look at this bug? [10:47] ppisati, we will need the videocore bits (the opensource graphics driver) to actually have graphical output on the pi [10:47] ppisati: (through https://picamera.readthedocs.org/en/release-1.10/) [10:47] zyga: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1532217 [10:47] Launchpad bug 1532217 in linux-raspi2 (Ubuntu) "Can't modprobe bcm2835-v4l2 to use RPi2 camera module" [Undecided,New] [10:47] it is for display as much as for video decoding and camera [10:48] ogra_: uh ok, is that part of the rpi kernel or it is a separate repo? [10:48] ogra_: the display is my next item, as soon as the camera is working [10:48] ppisati, i think the open one entered in 4.4 [10:48] ogra_: cool [10:49] ppisati, ogra_: is there anything actionable for me now? [10:49] id libraspberrypi-bin (from your bug above) in the archive ? [10:49] *is [10:50] ogra_: not in xenial [10:50] ogra_: looks like a raspbian package [10:51] ogra_: we should make this guy push all his packages into the archive [10:51] +1 [10:51] https://launchpad.net/~fo0bar/+archive/ubuntu/rpi2/ [10:51] ogra_: ^ [10:51] yeah, thats what a serch got me [10:51] *search [10:52] he's not here :( [10:52] in #ubuntu-devel perhaps ? [10:52] oh, ok, US, he's still sleeping... :) [10:52] i know that nickname, so he is here occasionally i'm sure [10:52] ok [10:53] FSVO "here" .... perhaps not actually in #snappy [10:53] not sure how easy/hard it is to push to the archive licensing wise though [10:53] ogra_: can we use the same bits that raspbian has? [10:54] ogra_: good point, the license... [10:54] ogra_: broadcom licensing seems to say that it is okay to resistribute for broadcom hardware [10:54] right, but it might have to go to restricted [10:54] (which is a bit weird but if they (raspbian) can then perhaps we can too) [10:54] or multiverse [10:54] not sure if there are binary bits in it [10:55] zyga, we should ... but they need to work with our kernel and bootloader [10:55] i.e. that needs QA [10:56] ogra_: can we ship the same kernel as the raspberry pi foundation? [10:56] ogra_: after all, isn't that what's snappy is all about? [10:56] (modulo ubuntu extra modules) [10:58] how can I get the core dump for a segfault on ubuntu snappy? [10:59] make /proc/sys/kernel/core_pattern point to a file [10:59] ubuntu@localhost:~$ cat /proc/sys/kernel/core_pattern [10:59] |/bin/false [11:00] you want to pipe to /tmp/core or some such ... [11:00] instead of /bin/false [11:00] (just make sure there is enough space for a whole RAM dump ;) ) [11:00] hehe [11:00] ok I don't know what I messed up, but now it does not say "core dumped" any more [11:01] damn, you fixed it :P [11:01] ahah no [11:02] it says "segmentation fault", but without the "(core dumped)" [11:03] afk lunch! [11:06] ppisati, ogra_: is there anything actionable for me now? [11:58] Good morning [12:09] kyrofa: hey [12:09] zyga, hey :) [12:58] * ogra_ grumbles about slow SD cards [13:16] dpm: hi, you will need to do a small tweak to your snaps: https://lists.ubuntu.com/archives/snappy-devel/2016-March/001516.html [13:16] "hello-world failed to install: snappy package not found" while taking a tour. Known problem? [13:16] dpm: will probably land today [13:16] ciastek: the store has a problem right now [13:17] ciastek: should be fixed soon, people are working on it [13:17] mvo: thank you! will try later. [13:17] mvo, thanks for the heads up, I had seen the e-mail, but wasn't sure the changes had landed. So I should basically change the snaps and re-upload them now? [13:18] ciastek: yeah, sorry, but we will try to fix it ASAP, its affecting our integration tests as well [13:18] dpm: not just yet, I'm waiting for our integration tests to work again (store issue) but I expect that I will land this today [13:18] mvo: thank again :) [13:18] thanks mvo [13:19] dpm: I can ping you once it is uploaded [13:19] mvo, that'd be awesome, thanks! [13:46] mvo: I guess a pet project to build a functional version of apt repository tools where each change yields a new URL but all the old URLs contain the old state [13:46] mvo: do you know of anyone doing something like that? [13:51] dduffey, ping [13:52] Hi guys do someone know how to install the webdm on the rolling versions? [13:53] zyga: sounds like snapshots.debian.net [13:53] noizer: snap install webdm/edge perhaps [13:53] * zyga cannot remember the right syntax for channels) [13:53] zyga: ups, http://snapshot.debian.org/ [13:53] just webdm.canonical shoudl work [13:54] noizer: alias in the store is broken right now [13:54] people are investigating [13:54] mvo: looks kind of like what we want, do you know how that is implemented? [13:55] mvo: is that a cron job doing snapshots [13:55] mvo: or just a very smart archive that does this internally [13:55] mvo: and is never inconsistent [13:55] hmm [13:56] zyga: I don't know the detials, sorry [13:56] mvo: thanks [13:56] zyga: I suspect more than a cron job though [13:56] as soon as I change /proc/sys/kernel/core_pattern from |/bin/false to something else , I don't get the "core dumped" message anymore [13:56] for instance now I've set it to /tmp/dumps/core.%e.%p.%h.%t [13:57] Hey mvo, zyga: I'd like to talk about Snappy data. Both unversioned data and how we should solve the problem of storing data on a separate HD [13:57] kyrofa: hmm [13:57] (for 16.04) [13:58] kyrofa: (in a meeting now) [13:58] mvo: for new os snap please land pull 565 (go-flags sync) [13:59] zyga, ah no problem [14:00] mvo, zyga I just want to make sure we solve those issues before 16.04 comes out [14:06] kyrofa: I'm not very familiar with snap data and update changes [14:07] kyrofa: I'm interested in the 2nd hdd problem [14:07] kyrofa: can you tell me more [14:07] zyga, I saw some ML posts a while back about that, and there were some good ideas. I figured you'd be interest in that second one ;) [14:08] zyga, ownCloud has a specific use-case. They want to ship a device that is essentially a rpi2 with a western-digital HD for ownCloud data [14:08] mvo zyga So it is normal that the webdm not works now on 16.04 [14:08] noizer, "not works" ? [14:09] can you be a bit more specific ? [14:09] kyrofa: I think the "easy" approach is to have an interface for a given /mnt/foo data and let owncloud just use that [14:09] zyga, but with a default partition layout it's not possible to even use that HD. You'd need to put the entire writable partition there [14:09] kyrofa: I suspect it's something post 16.04 though [14:09] when im surfing to it. it keeps loading [14:09] kyrofa, we would first need support for that on the system level anyway [14:09] ogra_, what do you mean? [14:10] kyrofa, some fstab entry to have a fixed mountpoint for example [14:10] (one that you can use the "interfaces" system on) [14:11] ogra_, ah, okay [14:11] ogra_: you said they moved the dtb in memory (latest rpi2 firmware), so what's the new location? [14:11] you dont really want someone to be able to just re-plug a usb key on some mission critical device to steal data etc [14:11] ppisati, no, that was dragonboard stuff :) [14:11] rpi is fine and stayed where it was [14:12] 0x100 should still work [14:12] ogra_: uhm [14:12] ogra_, well... no way around that if you're using an external device-- at least owncloud supports encryption [14:12] (i think ... my rpi is still in a suitcase, i'll have to check) [14:12] ogra_: http://pastebin.ubuntu.com/15266835/ [14:13] kyrofa, well, i would like my device to actually alert me and to not accept another device witgh a different UUID for example [14:13] ogra_, can't UUIDs be set, though? [14:13] as a low level security measure [14:13] not atm [14:14] mounting all happens by labels, the fstab is generated from the initrd [14:14] thats fine for the internal filesystems ... but for externals i'd like some snappy config option where you can set a UUID to have it added to fstab with a specific mountpoint [14:15] if you then replace the USB stick the app wont just start writing critical data to it [14:15] ogra_: you can just use the same uuid (clone it) and then booting is somewhat unreliable as far as being sure where you boot from [14:15] ogra_: but I totally agree about doing this with some more insinght as to how external media should be exposed [14:15] zyga, sure, its just another stop gap [14:16] indeed you can clone it ... and indeed it shoudl be encrypted :) [14:16] but encryption isnt supported yet either [14:16] ogra_: and here I'd say that we should treat external media as something gadget snap can influence (down the line) [14:16] so i dont think this is a topic for 16.04 release ... [14:16] ogra_: agreed [14:17] it is a topic for 16.04 SRUs for sure though :) [14:17] and we shoudl start planning for it after release day [14:19] ogra_, okay. So our recommended way of doing that is placing the writable label on the external? [14:19] for now, yeah [14:19] which essentially means you fully run from external in eth all-snaps world [14:19] hmm weird, if I sleep 20 & then kill -s SIGSEGV %1 , it creates a core dump, but not when I run my hello world which segfaults [14:19] (the readonly snaps live on 7writable nowadays) [14:20] *on /writable [14:20] ysionneau, are you still running under qemu ? [14:20] yes [14:20] ogra_, would that be possible to automate in any way? [14:20] might be a vm issue [14:20] the thing is, I trigger a kernel issue with my hello world [14:21] kyrofa, not easily ... you could have a script that calls kpartx to pull the content from /writable and push it to a USB disk indeed [14:21] ogra_, zyga mvo if the external HD is a post-16.04 support issue, I guess we're just left with the unversioned data. That sounds a bit easier to solve, perhaps? [14:21] ogra_: http://pastebin.com/QNu0G3w4 [14:22] ogra_, yeah I'll need to figure something out-- tough to have a shippable device when every device requires manual work [14:23] ogra_, I may be pinging you on that later, if that's okay [14:23] sure [14:29] ogra_ got this error: "Error: cannot list snaps: cannot communicate with server: Get http://localhost/2.0/snaps?sources=local: dial unix /run/snapd.socket: connect: no such file or directory" when he did this call: http://192.168.0.105:4200/api/v2/packages/?installed_only=true [14:30] noizer, is that 16.04 ? [14:30] (works here ) [14:30] ogra_ yes [14:33] so on your 16.4 it works ogra_ [14:33] Chipaca, you seemed to have some thoughts on the unversioned data stuff on the ML. Do you still think we can get that for 16.04? [14:33] noizer, only tried on arm64, but yes, there it works [14:33] (or at least did a few days ago, but there was no new webdm since) [14:33] hmm ok [14:34] ppisati, hmm... there seems to be an issue on the dragonboard with /dev/urandom [14:34] ubuntu@localhost:~/xenial-chroot$ lsb_release -cs [14:34] Fatal Python error: Failed to read bytes from /dev/urandom [14:34] Segmentation fault (core dumped) [14:35] i can read from it a few times but then it doesnt work anymore and i have to reboot [14:35] ogra_: /dev/urandom? [14:36] ppisati, yeah, see the error [14:36] ogra_: ah, i didn't see that [14:36] lsb_release -cs works for a while after fresh boot [14:36] but at some point i start getting python errors like the above [14:37] feels like there are only a few random bytes and once i used them up it starts failing ;) [14:37] ogra_: what if you do a 'dd if=/dev/urandom of=/dev/null'? [14:38] ubuntu@localhost:~$ dd if=/dev/urandom of=/dev/null [14:38] 0+0 records in [14:38] 0+0 records out [14:38] 0 bytes (0 B) copied, 0.000768486 s, 0.0 kB/s [14:38] nothing [14:39] dpm: hey-- I'd like to try your calculator snap on a unity7 desktop. are there instructions for what needs to be installed? [14:39] maybe that is a question for mvo ^ [14:41] I feel like there was an email but I can't seem to find it [14:41] jdstrand, at the end of the the doc. Once snappy is enabled, then just 'sudo snappy install ubuntu-calculator-app' [14:41] ah, maybe that was it [14:41] ok, thanks [14:41] I can also paste the instructions when I'm off the phone [14:41] I'm there [14:41] cool [14:41] dpm: thanks! [14:42] ah, I grabbed ubuntu-snappy-cli but not ubuntu-snappy [14:42] yow [14:42] http://paste.ubuntu.com/15267034/ [14:43] I'm glad I'm in a vm, I don't want my laptop's grub migrated :) [14:43] mvo: fyi, ^ [14:43] (apt-get install ubuntu-snappy) [14:43] jdstrand, added some notes to the doc to install the calc and clock apps [14:46] heh [14:46] man, a 144M clock [14:47] I thought we were going to have a thick os snap... [14:47] anyhoo [14:47] thanks! [14:48] thats just a prototype :) [14:48] i'm actually surprised it is *only* 144M [14:49] given it pulls in the whole of sdk-libs [14:49] well, with the calculator, there is another 141 ;) [14:49] diskspace is cheap :P [14:49] apparently that is what people say :P [14:49] heheh [14:49] (we should add that underneath the "linux for human beings" to the logo now ;) ) [14:49] :) [14:50] pfft [14:50] I was wondering how it launched with no denials [14:50] unconfined template [14:50] shiny eh ? [14:50] :P [14:50] well, I was wondering who did the work for me :) [14:51] and now I know [14:53] * zyga solitcits reviews of https://github.com/ubuntu-core/snappy/pull/559 [14:55] zyga, niemeyer: we need to have a chat so we can nail down what needs to be done wrt old-security, moving to native interfaces and existing security interface names. can we scedule a hangout sometime this week? [14:55] * jdstrand adds several more items to trello card wrt snappy on classic [14:56] jdstrand: yep, let's do it [14:56] jdstrand: I started to implement old-security natively but gustavo asked me to postpone that till the full interface core is working [14:56] jdstrand: as for the hangout, just propose one [14:57] jdstrand: Yes, please! [14:58] zyga: Yes, there's little meaning in "porting" logic to a non-working mechanism :) [14:58] oh, and snaps on unity7 interfaces [14:58] ok, let me see if I can find something [14:58] jdstrand: We also need to decide whether we need a sprint in a few weeks or not [14:59] Imminently [15:00] jdstrand, and it's ~600MB when installed (clock or calc), but probably some trimming down can be done already [15:01] jdstrand: thanks, its a known bug [15:02] jdstrand: it won't actually do anything, grub-migrate is dead [15:11] mvo, so the initrd build error is actually an issue with mkinitramfs ... seems it tries to copy the linker to a non-existing /lib64 dir [15:12] i wonder where that comes from [15:12] (no code that would do that in any of the initrd build scripts) [15:12] * davmor2 instantly blames that ogra_ bloke bound to be him ;) [15:13] ogra_: see that driveby blaming there ;) [15:22] mvo, so if i add set -x to the last initramfs hook that gets called i get this output ... http://paste.ubuntu.com/15267323/ ... note how it expands to searching for /lib64/ld-linux-aarch64.so.1 at the end before it exists non-zero [15:23] i'm not sure where that lib64 comes from :( [15:23] ogra_: in a meeting [15:23] ok [15:23] ogra_: will look after that [15:23] i think we need infinity but he is out today [15:25] ogra_: no you don't need infinity it'll just keep searching if you do that [15:25] davmor2, canadian infinity is different [15:34] hmm [15:34] ubuntu@localhost:~/xenial-chroot$ ls /usr/share/initramfs-tools/hooks/|grep klibc [15:34] klibc-utils [15:34] klibc^i-t [15:34] apw, ^^ any idea whats up with that klibc hook ? [15:34] (update-initramfs complains about it) [15:35] /usr/share/initramfs-tools/hooks/klibc^i-t ignored: not alphanumeric or '_' file [15:35] looks like someone typoed somewhere [15:36] jdstrand, does either security-override read-paths or write-paths encompass execution, by any chance? [15:36] yeah that it looks like there is a junk file in hooks [15:36] is there a file with a tab in the name in there ? [15:36] ubuntu@localhost:~/xenial-chroot$ ls /usr/share/initramfs-tools/hooks/ [15:36] busybox fixrtc fsck klibc^i-t resize thermal udev [15:36] compcache framebuffer klibc-utils kmod resume ubuntu-core-rootfs zz-busybox-initramfs [15:37] dosnt look like it [15:37] all other files look normal [15:37] kyrofa: no [15:38] jdstrand, didn't think so. I have some software that wants to shell out to /sbin/ip [15:38] iirc, you need the network-admin cap [15:38] jdstrand, oh! That's covered by that eh? Nice [15:38] hmm, funny ... in the source of initramfs-tools the klibc hook looks correct [15:39] the arm64 binary definitely has it though [15:40] apw, aha, klibc-utils adds a diversion ... i guess the typo is in there [15:42] there we go [15:42] https://launchpadlibrarian.net/237842216/klibc_2.0.4-7_2.0.4-8.diff.gz [15:44] apw, seems like a debian bug we actually inherit [15:45] (introduced by bwh) [15:45] nice [15:46] to bad that wont help with my issue though ... i just stumbled over it trying to get arm64 to behave when building initrds :/ [15:51] dholbach, anything to discuss today ? [15:52] ogra_, sorry, in a separate meeting right now [15:52] and no :-/ [15:53] lets skip then [15:58] kgunn, the beard! It's gone! [15:58] O M G ! [16:02] :) [16:03] wife didn't like it [16:03] mvo: do you have a moment now? [16:03] kgunn, aww, too bad [16:04] jdstrand: yes, HO? just send me the link via /msg === FourDollars_ is now known as FourDollars [16:17] grmbl [16:21] kgunn: wise man say when wife happy home is happy too :) [16:25] jdstrand: you asked about unshare() in ubuntu-core-launcher, we do use unshare(CLONE_NEWNS) when setting up the slave mount namespace (main.c:301). will this potentially cause issues with apparmor? [16:27] How can i use the snappy ubuntu core REST API on the rolling version? [16:35] noizer: look at docs/rest.md [16:35] noizer: you just make http requests to an unix socket (not tcp/ip socket [16:35] noizer: for starters, cmd/snap is doing exactly that [16:36] mvo: can you please land https://github.com/ubuntu-core/snappy/pull/559 if you have a moment [16:37] zyga: *if* [16:45] mvo: yeah, I know what kind of day it is for you today [16:56] Hey ogra_ I know you disabled the resize for dragon, but I just flashed an rpi and it didn't resize on boot either [17:04] kyrofa, oh ? [17:05] anything in /dev/.initramfs ? [17:05] there shoudl be logs [17:05] ogra_, no, that doesn't exist [17:05] is there a history server somewhere - I asked a Q last night but then I closed the chat app and cannot see if there was a responce [17:07] wiggleworm, http://irclogs.ubuntu.com/2016/ [17:08] kyrofa, last night I copied over the build ... and I could see better what was happening [17:09] thanks kyrofa [17:09] mvo: mount namespaces are not a problem. it is a file namespace that is the issue [17:09] the old yaml was including dependencies like libglog the new yaml didn't [17:09] jdstrand: great, we are good then [17:10] dduffey, I think it all working now, but it seems the system is down? [17:10] mvo: we should be, yes. I'll be poking at this and I'll come to you if I notice anything issues [17:10] let me check [17:12] Can anyone help with a question about snapcraft and "build packages"? I want to create a snap with lsusb and lspci. I want to add the functionality of lsusb and lspci to snappy as its not installed. With that in mind, I am trying to build a snap that will install the two deb packages (and dependences) into the system so that I can run them from the command line. I think I would use "build packages" with [17:12] snapcraft but I keet getting a "parts" error. I have not defined a "parts" section because I have no clue how to do that when all I want are the deb packages. I also read about using "stage-packages" but that makes even less sense to me given that I still have to have a "parts" section. [17:12] kyrofa, you first have to ssh into 192.168.122.188 from the jumphost [17:13] and then ssh into 192.168.10.35 [17:13] jdstrand: thanks [17:13] Ahh, I misunderstood [17:13] * mvo -> dinner [17:14] kyrofa, oh, sorry ... that should be /run/initramfs/resize-writable.log [17:14] the /dev/.initramfs is what we used in the past [17:15] dduffey, all good here! I'll be testing for a bit now. Sorry about that, I just though "MAAS? Why do I care about MAAS? Okay, SSHing into snappy..." :P [17:17] kyrofa, no problem ... I will be stepping in/out over the next hour and then I'll be out the rest of the day [17:17] dduffey, good deal, I just wanted in there, I'm set now [17:28] ogra_, the only thing in there is fsck-writable, and it contains http://pastebin.ubuntu.com/15268551/ [17:59] sergiusens, you're killing the examples tests man. 6? [18:01] kyrofa, I didn't change anything that would trigger this failure though [18:04] sergiusens, haha, "Everything passed[...]marked build as failure" [18:06] good afternoon. Anyone got a moment for a frustrated newbie? [18:08] I'm trying to get snappy-core running in VMware workstation using the OVA. It boots fine and I've created the basic cloud-init iso - that works. However, as soon as I try and modify user-data to add a user, or just add ssh-keys, it breaks and I can't log in on boot. [18:24] mwb, I'm sorry, I'm not sure there's much experience around here with OVA [18:24] mwb, kvm, virtualbox, we gotcha [18:27] sergiusens, https://launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-core/0.7.23 ... cross your fingers :) [18:32] YIPIIIIEEE !!! it built [18:33] * ogra_ waits for armhf now [18:35] ogra_, is it just me or is xenial dramatically faster than trusty on the rpi2? [18:43] kyrofa, well, i guess the squashfs really helps for devices with slow SD cards [18:44] ogra_, no that's not it. Just compiling speed seems to be faster. Though it may have been the image I was using previously [18:44] ah [18:50] heh, so the generic initrd is 2.3MB big ... [18:51] vs [18:51] ubuntu@localhost:~$ ls -lh /boot/uboot/canonical-dragon-linux.canonical_4.2.0-2014-generic-dragon410c.snap/|grep initrd [18:51] -rwxr-xr-x 1 root root 8.7M Feb 19 17:40 initrd.img [18:54] * ogra_ calls it a day ... [19:06] ogra_, nice! Now I need to get my hands dirty :-P [19:25]