[04:52] jdstrand: noted, thank you for explanation. === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:56] good morning [08:04] good morning [08:21] hi, good afternoon for Asia :p [08:25] i'm wondering why doesn't snapcraft delete the generated snap while `snapcraft clean` is executed ? [09:11] Good morning snappy [09:12] Did anyone ever try to run u-d-f in a Docker container? Miserably fails - i am tempted to give up and run it in Vagrant instead or does anyhone have a suggestion? [09:15] longsleep: how does it fail? [09:20] Chipaca: it seems to be related to udev [09:20] Chipaca: http://paste.ubuntu.com/13214725/ [09:20] i cannot make much sense of it .. [09:21] and i am running it with --cap-add=ALL --privileged=true [09:21] would be nice if that would work === joc|away is now known as joc_ [09:21] longsleep: in docker, does kpartx work? [09:21] Chipaca: let me try [09:21] longsleep: e.g. scp an img in, kpartx -av the.img [09:24] Chipaca: yeah that works [09:24] add map loop0p1 (252:3): 0 131072 linear /dev/loop0 8192 [09:24] add map loop0p2 (252:4): 0 2097152 linear /dev/loop0 139264 [09:24] add map loop0p3 (252:5): 0 2097152 linear /dev/loop0 2236416 [09:24] add map loop0p4 (252:6): 0 3280896 linear /dev/loop0 4333568 [09:25] removing it works as well .. loop deleted : /dev/loop0 [09:27] well, that's good in one sense [09:27] because it means the thing i thought wouldn't work, works [09:28] Well, from the trace it tries to connect(3, {sa_family=AF_LOCAL, sun_path="/run/udev/control"}, 19) = -1 ENOENT (No such file or directory) [09:28] which fails as there is no udev in the container [09:28] and then exit 2 [09:28] what i do not get, is why it wants to connect to udev [09:30] me neither, offhand [09:32] unless i'm missing something it shouldn't need udev at build time [09:32] Chipaca: yeah, there is no udev stuff in the code what i could find [09:32] question for sergio, then [09:32] longsleep: the udev stuff will be from snappy [09:33] but they shouldn't get called at build time [09:34] Chipaca: ok, let me check what i find there [09:34] starting udev is not an option though [09:34] * udev does not support containers, not started [09:38] elopio: I'll check out those templates in a sec [10:03] so how does snappy play with docker ? [10:04] Good morning all; happy Tuesday, and happy Area Code Day! 😃 [11:00] Chipaca: found the problem why u-d-f tries to connect to Docker .. http://git.intranet.struktur.de/debian/ubuntu-snappy/blob/ubuntu/trusty/snappy/oem.go#L241 [11:00] I think this should not be called when snappy is used from u-d-f [11:01] i don't think intranet links will work :) [11:01] err [11:01] sorry [11:01] nm, got it [11:02] Chipaca: correct link is https://github.com/ubuntu-core/snappy/blob/master/snappy/oem.go#L242 [11:02] Chipaca: It reloads udev rules when processing oem snaps [11:03] yes, but it shouldn't run if inhibitHooks is there [11:03] let me grab sergio [11:03] Chipaca: its called from here: https://github.com/ubuntu-core/snappy/blob/master/snappy/snapp.go#L812 [11:04] yeo [11:04] it should, i think, instead be called from run-hooks [11:04] or firstboot? [11:04] well it needs to run when a new snap is installed [11:05] on boot i thin udev will load all rules automatically [11:05] =k [11:06] longsleep: so [11:06] longsleep: easy workaround for you for now [11:06] longsleep: ln -s /bin/true /usr/local/bin/udevadm [11:07] longsleep: in the container [11:07] Chipaca: yep [11:07] Chipaca: lets see if i can get it running in the container then [11:08] it's unclear to me atm whether the installOemHardwareUdevRules itself should be skipped, or just the reload, when calling it from u-d-f; sergio would know more but he's off for now [11:09] Chipaca: yeah almost there i think [11:09] xz: Cannot exec: No such file or directory [11:09] :/ [11:10] there seems to be a dependency missing [11:10] i install u-d-f with apt [11:11] Chipaca: woot - it worked [11:11] New image complete [11:11] Summary: Output: test.img Architecture: amd64 Channel: stable Version: 9 [11:12] (patched version though, let me try the symlink hack) [11:14] Chipaca: still struggle with dependencies .. "sc-filtergen": executable file not found in $PATH [11:14] $ dpkg -S `which sc-filtergen` [11:14] ubuntu-core-security-utils: /usr/bin/sc-filtergen [11:14] yeah [11:15] that package is a beast - pulls in perl and python [11:15] :-( [11:16] having a large docker container is better than none [11:16] i wonder about the perl [11:16] Chipaca: including like 50 perl module packages :) [11:18] so can snappy run on other distros that are not ubuntu based? [11:19] Shibe: probably [11:19] okay [11:19] Chipaca: and with snappy we can have bleeding edge applications without breakage right? [11:20] gah [11:20] ? [11:20] longsleep: libssl -> debconf -> perl-base [11:20] also can snappy install things such as drivers? [11:21] or would we still use apt for that? [11:21] what libssl requires debconf? [11:21] longsleep: http://people.canonical.com/~john/deps.svg [11:22] Chipaca: oh my [11:22] longsleep: apt-rdepends -d ubuntu-core-security-utils | neato -Gsplines -Goverlap=scale -Tsvg > /tmp/deps.svg [11:23] what about storage? would snappy apps take up more space than regular apps? [11:26] Chipaca: well, u-d-f now fails with exit 1 when installing one of the preinstalled snaps from the oem definition .. so more debugging [11:27] Shibe: drivers would be included in the kernel snap (which is a 16.04 thing) [11:27] Shibe: there is no apt in a snappy system [11:27] Chipaca: so there will be no apt in ubuntu 16.04 or what? [11:28] Shibe: which ubuntu 16.04? [11:28] wait [11:28] wont snappy become like the primary package manager in newer versions of ubuntu? [11:29] or is it only for mobile devices and servers? [11:29] Shibe: no, it won't become the primary package manager in newer versions of ubuntu [11:30] Shibe: and no, it is not only for mobile devices and servers [11:30] so there will be a seperate ubuntu called snappy ubuntu? [11:30] Shibe: there already is [11:30] yeah [11:30] Shibe: snappy ubuntu core [11:30] i was thinking that it was more of an experimental version of ubuntu before snappy becomes the default [11:31] I wouldn't describe it that way [11:31] okay [11:31] Shibe: https://developer.ubuntu.com/en/snappy/ [11:32] Chipaca: but will the snappy ubuntu core ever become the default? [11:32] *core* won't ever become the default, no [11:32] Chipaca: SeccompFilterGenException: \"Invalid template 'default'\ - any idea about this one? [11:32] ok [11:32] Shibe: there might at some point be a snappy ubuntu desktop [11:33] Shibe: but I can't see that far into the future [11:33] okay [11:33] well, i would assume that core might stay the default on all snappy installs [11:33] Chipaca: happens when /usr/bin/sc-filtergen is called [11:33] with icn on top for a snappy desktop or a snappy server [11:33] *icing [11:34] but nobody can really see far into the future on that level as Chipaca said :) [11:34] ogra_: possibly, but we'd probably not call the resulting system a "snappy ubuntu core" system [11:34] yeah [11:35] longsleep: you're missing ubuntu-core-security-seccomp [11:35] Chipaca: yeah - just found this package, lets see [11:37] Chipaca: yeah that was the last one, works now unpatched version, just symlink udevadm and install a bunch of debs [11:37] huzzah [11:37] Chipaca: so green light for u-d-f in Docker - yay! [13:09] Chipaca: btw, not sure if i told you already, but changing run-hooks to run before firstboot fixes bug #1511435 and the booted system applies the provided oem config an all. [13:09] bug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Critical,In progress] https://launchpad.net/bugs/1511435 [13:13] longsleep: https://github.com/ubuntu-core/snappy/pull/72 [13:13] longsleep: and https://github.com/ubuntu-core/snappy/pull/71 [13:14] Chipaca: nice yay \o/ [13:44] beuno, JamesTait, is there a field in the store API that contains a human-readable name for a snap that we could use to show a list of snaps such as the one in https://developer.ubuntu.com/en/snappy/guides/gadget-snaps? [13:44] e.g. "BeagleBone Board" instead of "beagle.gumstix" [13:47] dpm, you want the title field. [13:47] JamesTait, but is that available from the API? I seem to remember dholbach mentioned we don't have access to such a field [13:48] I might be doing it wrong :) [13:48] dpm https://search.apps.ubuntu.com/api/v1/search?q=download_url%3A%2A.snap&fields=name%2Ctitle%2Cdownload_url&page=1 [13:49] I think that's what you want: "name": "com.ubuntu.snappy.docker", "title": "The docker app deployment mechanism" [13:52] davidcalle, dholbach ^ [13:52] dpm, they're generally not looking prettier :-/ [13:52] "title": "odroidc-community" [13:52] "title": "generic-i386" [13:52] yeah, I just saw that too [13:53] "title": "beagle" [13:53] so I'm not sure it's worth changing right now [13:55] JamesTait, is the title field editable by people who upload apps to myapps? [13:55] and what is it called? :) [13:55] i think it is called Title in the store form [13:56] dholbach: dpm: "title" is what you want [13:57] dholbach: dpm: people might not be using it right, but that's where you're supposed to be putting the human-readable one [13:57] there's id_name and id_tagline [13:57] id_description [13:58] bah [13:58] something might be wrong :) [13:58] for snappy, the title is the first line of the readme [13:58] yeah, I'm trying to piece it together [14:00] so that's the "description" field in the store [14:00] but only the first line fo it [14:00] maybe [14:00] i guess this is one of the things that the store does not get from the package? [14:00] Chipaca: so, do you want to hear about another service ordering poblem with firstboot and modules-load.d ? [14:01] Chipaca, it might be [14:01] because for example, curl has a title in the manifest, that is not in the store data [14:01] longsleep: yes, yes i would [14:02] Chipaca: thanks for your feedback on #67, is there some sort of roadmap available so I don't try to provide our changes upstream if they will be deprecated soon anyway ;-) [14:02] Chipaca: so, when an oem snap wants to load kernel modules, with config: ubuntu-core: load-kernel-modules, then this fails for the very first boot, because snappy firstboot runs after systemd-modules-load.service [14:03] JamesTait, do you know where the data for .title comes from? [14:03] Chipaca: second boot works fine, as the created modules-load.d file is there then [14:04] longsleep: can you confirm adding systemd-modules-load.service to firstboot's Before: fixes it? [14:04] longsleep: (as opposed to creating a cycle) [14:04] Chipaca: Let me try, i am still new to systemd and its ways [14:05] longsleep: it's got a bunch of things on the Before: line, you can just append [14:05] or add another Before: line [14:05] both work [14:05] fancycode: I don't think we have a roadmap per se, sorry [14:08] Chipaca: hmm, ok thanks [14:13] Chipaca: That results in an order cycle and systemd deleted it [14:14] longsleep: feared as much [14:14] longsleep: can you pastebin the bit of the log about the cycle? [14:14] Chipaca: sure / hold on [14:15] Chipaca: http://paste.ubuntu.com/13216046/ [14:20] mvo: just so we are in sync> I'll be pulling your changes into my branch later today, but don't push it yet-- there are still a few things to implement (see the card) and a lot I want to test [14:21] mvo: and a bit to discuss :) [14:21] but not atm [14:22] jdstrand: ok. thanks. it seems like everything left is review-tools? except for apparmor_parser -p but I send a question about this :) [14:22] jdstrand: and testing of course [14:22] jdstrand: if you point me towards what else is missing I'm happy to have a look at it [14:26] mvo: the card has a few things [14:26] longsleep: on first boot, can you confirm whether "systemctl reload systemd-modules-load.service" loads the modules just added by firstboot? (once you removed systemd-modules-load.service from the Before of firstboot) [14:26] Chipaca: let me check [14:26] longsleep: thanks! [14:27] longsleep: i'm being lazy relying on you to test stuff, hope you don't mind too much [14:28] Chipaca: no problem, i just takes around 70 seconds to write a new image to the sdcard [14:28] wow [14:28] ok [14:28] your sd writer is 5x faster than mine [14:28] mvo: in terms of snappy code there are two things: 1. "remove 'apparmor' and 'seccomp' keys from security-override and just have 'read-paths, syscalls, etc all directly under 'security-override'" [14:28] Chipaca: you have USB3? [14:28] mvo: and 2. "regenerate-all should only regenerate svc/bin policy, not all policy within a snap" [14:29] 3899999744 Bytes (3,9 GB) kopiert, 73,5622 s, 53,0 MB/s [14:29] longsleep: usb2 only for me [14:30] Chipaca: yeah well, that explains why you get only around 10MB/s [14:30] although the sd card according to lshw is hung off of pci directly [14:31] but, yeah, oldish laptop [14:31] sandybridge iirc [14:32] Chipaca: Job type reload is not applicaple for unit systemd-modules-load.service [14:32] longsleep: restart, then? [14:32] and just checked, it's an arrandale, not sandybridge [14:33] Chipaca: ok, confirmed after restart the modules are loaded [14:34] longsleep: that is 'systemctl restart systemd-modules-load.service', not a reboot, yes? :) [14:35] Chipaca: yes [14:35] mvo: so '1' is probably pretty easy-- squash SecurityOverride into one thing rather than two [14:36] Chipaca: http://www.amazon.com/Transcend-Information-Card-Reader-TS-RDF5K/dp/B009D79VH4/ref=sr_1_2?ie=UTF8&qid=1447166144&sr=8-2&keywords=transcend+usb3+card+reader, connected into Dell USB3 hub integrated inside monitor :) [14:36] $6.95 [14:36] mvo: '2' maybe requires some explanation. right now, click-apparmor will only recompile policy for the services/binaries that are affected. snappy currently will regenerate all the policy if any are affected [14:37] longsleep: :) [14:38] mvo: for a few snaps, this isn't a big deal, but on personal where many snaps will ship both a scope and an app, we could halve the compile time for these snaps (eg, if the scope template changes, we don't have to regenerate things that use the app template) [14:41] mvo: and that is an important optimization [14:42] jdstrand: aha, thanks for explaining (2). but certainly not a blocker, right? I mean not a blocker for inclusion even if that lands later this week? [14:43] mvo: and it would be felt on core too-- imagine something like the nm framework that ships some 10 binaries and a couple services. if only one of those needed to be updated, it would be wasteful to regenerate the other 11 [14:43] mvo: that wouldn't be a blocker-- it could land later [14:44] mvo: but '1' is. we want to move straight to the cleaner/clearer yaml for security-override [14:44] mvo: also, ubuntu-core-launcher needs an update for hwaccess [14:45] mvo: and a systemd unit for regeneration [14:45] mvo: and apparmor update for /var/lib/snappy/apparmor/profiles [14:45] I'll handle that last one [14:45] feel free to do any of the others [14:46] jdstrand: what updated does u-core-launcher needs? [14:46] jdstrand: I will try to look into (1) next [14:46] mvo: if you recall, it is looking at the .json.additional file in /var/lib/apparmor/clicks [14:47] ok, I have a meeting in a few minutes and I need to step away [14:49] jdstrand: I did not, but now I do [14:49] jdstrand: thank you! [14:49] np [14:50] mvo: there is one last thing that won't block this merge> click-apparmor has the concept of .override files. with them, you can add to or remove from the caps/security-override === chihchun is now known as chihchun_afk [14:51] mvo: you can think of them as the user replacing security-template, caps and security-override from the package.yaml with their own [14:52] mvo: what click-apparmor does doesn't translate to this new world exactly, but this feature was important for Touch since users could, for example, remove the 'networking' policy group from the security perms [14:53] mvo: we'll want to design how this works. I mention it, cause I imagine it would be a 3rd file to merge into overrides. alternatively, the current hwassign file format could be keyed to handle both hwassign and user overrides [14:54] mvo: funny how redoing policy generation seemed like an easy task, no? (there is a lot of thought that went into how we did things before-- it is good that we can reuse what makes sense and refine/redo what doesn't) [14:54] jdstrand: thanks this makes sense. I slightly prefer that hw-assign does that, but have not put much thought into it yet [14:55] mvo, ogra_, hey, https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 seems to be stalled in the sponsoring queue, could you have a look if that's still relevant or if it should be rejected? [14:55] dholbach, the title field in the metadata comes from the title field in the manifest for click packages. It sounds like that's not the case for snaps, though, so I'll have to check, [14:55] mvo: well, the good thing is, whatever we come up with is not a user visible change (in terms of packaging yaml). and since no one is doing user overrides on snappy yet, we have some time [14:56] thanks JamesTait [14:56] mvo: but I mention it because if you had a strong preference on one file or two, you could go with it and adjust the launcher once [14:56] ok, gotta run for real [14:56] longsleep: could you file a bug for the modules thing? [14:56] jdstrand: thanks for your input [15:03] Chipaca: yes sure [15:15] dholbach, Chipaca: do you have an example where the package title that's in CPI clearly isn't obtained from the package? [15:15] JamesTait: curl.tetor [15:16] Thanks, Chipaca. [15:25] jdstrand: thanks, I implemented the flat "security-overrides" in my branch now [15:35] dholbach, in answer to your previous question, yes, developers can override the values from the package metadata in the upload form - if they provide Application Name, I believe the package manifest is ignored for the title. [15:36] JamesTait, so "Application Name" gets mapped to .title? [15:36] I'm just uploading a package to staging to verify this. [15:36] * dholbach hugs JamesTait [15:36] thanks a bunch! [15:39] Chipaca: modules bug added as #1514890 [15:39] Chipaca: bug 1514890 [15:39] bug 1514890 in Snappy "Kernel modules from oem snap not loaded on first boot" [Undecided,New] https://launchpad.net/bugs/1514890 [15:40] taw [15:46] fgimenez: please check if you like how I'm ignoring test messages, and if you like it I'll do the same for setup and tear down: [15:46] https://github.com/ubuntu-core/snappy/pull/70 [15:47] elopio, sure, on it [15:50] dholbach, http://people.canonical.com/~jtait/sample-snap.png is what I see if I fill in the Application Name, Tagline and Description fields in the form. [15:51] JamesTait, right... I was just wondering which of the fields is later on used in .title? [15:53] That would be Application Name. [16:01] elopio, nice, it would be great to express the regexp to know if we have to ignore in terms of the format constants, but it's fine as it is [16:01] fgimenez: yeah, that's harder. Any tips? I didn't know how to escape the *. [16:08] elopio, there's https://golang.org/pkg/regexp/#QuoteMeta, haven't tried it though [16:09] let me try. [16:14] fgimenez: should those constants be in the reporter package? or maybe in the base_test [16:17] elopio, not sure, they are going to be used by the component that handles the reboot, whatever it is after the disection of common, and by the reporter pkg, maybe the data pkg as we have been doing so far for shared constants? [16:18] mvo: thanks! so, one thing I've been a bit concerned about is upgrades. I think the systemd unit will handle nearly everything, but for hardware assignment, need to migrate .json.additional to /var/lib/snappy/apparmor/additional? [16:19] mvo: also, security-override changes the yaml. I don't expect there to be anything that is using the current security-override (or at least nearly nothing) === beowulf_ is now known as beowulf [16:19] jdstrand: yeah, I think you are spot on, we need to migrate .json.additional. security.md needs an update indeed [16:19] mvo: yeah, I'll do the security.md part [16:20] mvo: but I was worried about existing snaps or sideloading [16:20] mvo: well, worried, I'm not sure how I feel [16:20] jdstrand: its rolling, its ok to break stuff I think [16:20] mvo: ie, what happens if I sideload or snappy build with different versions of snappy [16:21] mvo: yes-- I was thinking that, but I don't think you can have snaps in the store with one version that targets rolling and another stable, can you? [16:21] I guess this is literally all the same questions as moving to squashfs [16:22] mvo: would it make sense to have a nicer error if the user specifies 'apparmor' and/or 'seccomp' in the security-override? [16:23] mvo: eg, if they do, then suggest using 'read-paths', 'write-paths' or 'syscalls' instead? [16:23] jdstrand: we can do that too [16:23] jdstrand: fine with me [16:24] I think that would ease my mind. that gets quite a bit easier now that you flattened it [16:24] ok [16:24] or at least-- it keeps the implementation cleaner (I think) [16:25] what's the status of booting with a 32bit uefi? is that working? [16:28] https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 is in the sponsoring queue since april [16:28] and James isn't around anymore [16:29] could somebody have a look and say if that should be rejected or what? === dpm_ is now known as dpm [17:10] * ogra_ wonders what keeps the arm builders so busy [17:11] ogra_: wrestling tournament? [17:11] arm wrestling? get it? get it? [17:11] *badumtssssss* [17:11] hah, yeah ... [17:11] so funny ! [17:11] :) [17:22] ogra_: Hey, has there been any development regarding update of the bootparts of the oem snap, plans for that? [17:22] update in what way ? [17:23] i'm still owing documentation for the uboot setup ... beyond that nothing is planned atm [17:23] ogra_: eg. write new u-boot or .env when the oem snap updates or when the system image is updating [17:23] as far as my understanding goes, the boot stuff is only written once and currently never updated - is that correct? [17:23] yep [17:24] ok - so i might have to work on this a bit soon [17:24] that might change when we go for "everything is a snap" [17:25] yeah - though that is tricky to make a safe operation, how does the user know that now would be bad to unplug power [17:26] right [17:26] at least he odroid does not have a backup location for alternate u-boot if the update screws it up or something [17:26] so i think the operation should be manual in any case so the user can be told, not to turn off the device [17:27] sudo snappy update-oem ? [17:27] yeah something like that [17:27] or rather "update-gadget" in future speak [17:27] (not sure the bootloader will stay in oem) [17:27] i think the snappy tool would be the correct place to put it [17:27] right [17:28] for now i might create something simple inside an unconfined snap - but i think this needs to be handled by snappy base software in the future [17:29] well, like the kernel, rootfs and whatever else snaps [17:31] yes - there could be a hook similar to the config hook which can be provided by the oem snap or by whatever snap owns the bootloader to precheck and generate a yaml for snappy to read the assets from [17:31] Exploring snappy for first time, struggling to change an applications apparmor config to "read a file" here is the log: audit: type=1400 audit(1447176418.849:1694): apparmor="DENIED" operation="open" profile="system-status.victor_system-status_1.0.10" name="/etc/ubuntu-build" pid=4741 comm="cat" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [17:33] you cant read stuff outside of your confined area [17:39] thank you, can I change the confined area? [17:44] probably not enough to read that file ... [18:09] longsleep: https://github.com/ubuntu-core/snappy/pull/76 and .../77 for the 15.04 cherry-pick [19:09] ogra_, you still around? [19:09] only partially [19:09] whats up ? [19:10] ogra_, quick snappy spec question: snappy/doc/meta.md implies that the description key is only for services. Is that true? Not for binaries? [19:11] uh, i dont know ... Chipaca might though [19:11] hey all, I'm trying to use fswebcam in a snap on my rpi2, any ideas why I might get these errors: http://pastebin.ubuntu.com/13218060/ [19:11] but i guess it would be rather useless for binaries [19:12] rickspencer3, you need to use hw-assign to enable the device access for the video device [19:12] ogra_, did that [19:12] in two ways [19:12] hmm [19:12] weird [19:13] the last line is even weirder [19:13] Ah, sergiusens is around. Do you know the answer to my question ^^ ? [19:13] sudo snappy hw-assign rest-cam.sideload /dev/video0 [19:13] kyrofa, let me get back to you in a bit [19:13] then, out of desperation: [19:14] sudo snappy hw-assign rest-cam.sideload /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/input/input1 [19:14] kyrofa, where would that description be shown ? i mean ... systemctl will sjow you a description for a service ... i dont see where you would show such a description for some random binary [19:15] ogra_, I would assume that for a binary, the description would be shown in the store [19:15] rickspencer3, only the package description [19:16] rickspencer3, where exactly ? the store doesnt show any content of a snap [19:16] ogra_, you're right, right now it wouldn't be used. But it will in the future (in GUIs etc.) [19:16] sorry, I thought that was what you referred to [19:16] kyrofa, so you expect guis that show snap content in the future ? [19:22] grrrr ... why does launchpad always lie to me about publishing status [19:50] \o/ [19:50] https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/42931 [19:51] kyrofa, hey, so what was your question? I don't have enought scrollback [19:51] raspi2 device tarballs now automatically from the normal rootfs build [19:51] sergiusens, got the answer from the code-- ignore me! :) [19:52] kyrofa, are you working on scopes still? [19:52] sergiusens, man, I'm working on _everything_ :P [19:52] kyrofa, it is sometimes like that ;-) [19:53] kyrofa, to test that box you tick on job summaries "self manage multiple tasks" :-P [19:53] sergiusens, hahaha :) . I love it though-- everything from kernel patches to scopes to the in-app purchase API [19:54] sergiusens, what are you up to these days? [19:54] Enjoying fatherhood? [19:55] kyrofa, that and snapcrafting :-P [19:55] Ahh, right, snapcraft. I knew you were on that [19:56] sergiusens, I think you gave me your cold, by the way [19:57] kyrofa, I didn't get a cold ;-) [19:57] so it couldn't have been me :-) [19:57] sergiusens, oh. Must have been my son's snotty kisses then [19:57] thats the proper opensource way ... share ! [19:57] lol [19:58] I don't want to share what I had, it is rather painful ;-) [20:12] hey [20:32] sergiusens, mvo: can one of you take a look at my snapcraft.yaml at git://kernel.ubuntu.com/rtg/kernel-snap.git and tell my why I can't seem to get files copied from stage into snap ? [20:33] p.s. - this is early work in progress [20:34] rtg, why do you use plugin: make ? [20:34] if you only want the binary debs [20:34] ogra_, 'cause it is what I know [20:35] rtg, i'd just (ab)use the copy plugin [20:35] http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/files [20:36] ogra_, you haven't looked at the Makefile, there is more to it then just copying [20:36] ah [20:36] yeah, i havent [20:38] ogra_, can you point me at the code that sergiusens uses to build a device tarball ? I'd like to hijack the initrd bits. [20:39] i didnt know sergiusens builds device tarballs :) [20:39] ogra_, well, somebody does. I thought he did the platform image creation code [20:40] rtg, for the fun of it, i replaced the whole code for building device tarballs today :) http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1227 [20:40] you want the changes in live-build/auto/build there [20:40] rtg, we use livecdrootfs today [20:40] thats exactly the code creating the device tarballs [20:41] * sergiusens git clones [20:41] hmm, seems like there ought to be a way to do this without having to chroot. [20:42] on the buildd ? [20:43]