[07:55] good morning [08:15] good morning dholbach :) [08:15] salut didrocks [08:28] ogra_, hey do you know what vmlinuz-4.2.0-2014-generic-dragon410c is? [09:03] Good morning [09:22] morning ! [09:26] ricmm, http://paste.ubuntu.com/15319880/ [09:26] zyga-phone Hi is the update done for the interfaces etc? [09:27] zyga-phone Hi is the update done for the interfaces etc? [09:29] jdstrand: https://github.com/ubuntu-core/snappy/pull/591/files [09:29] noise][1: hey, no, we haven't released yet AFAIK, I will see what the state of the stack is and then we'll probably release [09:29] noise][1: but it is certainly on our plan today [09:30] zyga-phone: ok :D [09:40] ogra_: will you be able to test my new uploads of the os and kernel snaps for arm64? I uploaded to rolling/edge [09:41] ogra_: i.e. if it boots :) [09:41] * zyga-phone can test as well [09:41] mvo: on dragon [09:43] zyga-phone: yes, updating to them is enough, so sed /channel: stable/channel: edge/ might be the easiest way (in /var/lib/snappy/meta/*.manifest [09:43] k, one sec [09:44] zyga-phone: no problem, the review task is still running so its not published yet anyway [09:45] did the sed [09:45] rebooting to see if snappy picks it up [09:47] mvo: that didn't make snappy see any updates, am I missing something? [09:48] all the *.manifest files say channel: edge [09:49] canonical-dragon 2016-02-12 0.7.1 canonical [09:49] canonical-dragon-linux 2016-02-19 4.2.0-2014-generic-dragon410c canonical [09:49] mvo: ^^ [09:51] ppisati: hey [09:52] ricmm: hey [09:52] having some pain here [09:52] ricmm: ??? [09:52] ppisati: how do I fire off a build for your ubuntu kernel tree for 96b? [09:53] ricmm: hold on [09:54] zyga-phone: its now updated [09:55] mvo: still nothing? [09:55] ricmm: export ARCH=arm64; export $(dpkg-architecture -aarm64); export CROSS_COMPILE=aarch64-linux-gnu- [09:55] zyga-phone: in /edge ? [09:55] ricmm: if you are trying to build the 4.2.0 dragon410c branch: [09:55] mvo: I did the sed, in /var/lib/snappy/meta, anything else I should change? [09:55] (and I rebooted to reset snapd memory state) [09:55] ricmm: fdrc && debian/rules build && fdr binary-generic-dragon410c [09:56] ricmm: if you are trying to build the 4.4 snapdragon/96boards tree: [09:56] ricmm: fdrc && debian/rules build && fdr binary-[snapdragon|96boards] [09:56] zyga-phone: I investigate [09:56] ricmm: fdr = fakeroot debian/rules / fdc = fdr clean [10:01] ppisati: thanks [10:01] ppisati: just to confirm, for arm64 your scripts still copy to vmlinuz right [10:01] even tho its not really compressing [10:02] ricmm: yes, it creates the vmlinuz image file [10:02] ok [10:02] slightly misleading to have vmlinuz if its not compressed [10:02] but unrelated to today anyways [10:03] ppisati: how about getting the tree in a state where I can issue a final make command [10:03] as if it was a normal tree [10:03] as-in get the right config built, then CROSS_COMPILE, ARCH, make Image [10:03] can I do that starting with an ubuntu source package tree? [10:04] ricmm: when i need to do that, i issue: [10:05] ricmm: fdr prepare-[generirc-dragon410c|snapdragon|96boards]; cp debian/build/build-.../.config .; make ... [10:06] ricmm: what are you doing over there? why are you compiling kernels? [10:06] im with sergio, we are looking at the kernel plugin [10:06] ogra_: is your script to build the arm64 kernel snap somewhere? [10:06] mvo: last I asked him that question he said he uses your script [10:06] so probably you are the answer [10:08] ppisati: make: *** No rule to make target 'prepare-generic-96boards'. Stop. [10:08] ricmm: oh, that tree was renamed [10:08] ricmm: fdr prepare-96boards [10:08] im at the tip of your x-96boards branch [10:11] ricmm, hey [10:21] funny that snappy list tells me to reboot to use ubuntu-core-xxxx-13 but if I do ls -l /writable/system-data/snaps/ubuntu-core.canonical/ [10:21] then current already points to -13 and not -12 [10:23] ricmm: I wonder where he gets the kernel from, but I will talk to him once he is around [10:24] mvo: for which device? [10:24] short answer is ubuntu packages [10:24] ricmm: the dragonboard [10:24] paolo's ppa [10:26] ta [10:37] mvo, will test ... and what ricmm said, i use your script with a lot of manual dpkg -x'ing and a depmod call [10:37] i'll trun that into proper code (to merge it into livecd-rootfs) [10:37] ogra_: aha, ok. I had hoped to upload a new kernel, but there are manual steps I leave it to you :) [10:37] ok [10:38] ricmm, note that you need the patched devicetree file when usinh ppisati's build ... [10:39] there is one called -touch ... [10:39] err [10:39] sorry [10:39] -snappy [10:49] Hi, I have a question about daemons in snappy. Is it possible to set a variable so the daemon don't start at startup? [10:49] not at present; I don't think this is something you can do [10:49] noizer: what's the use case? [10:52] zyga-phone A service needed only running when they tabbing on something. But first i tought i will do that with starting an other snap(execute a wrapper from an other snap) but that isn't possible but starting a service is possible out of the REST API [10:53] Sorry for service but its a bacground app I mean [11:20] ogra_: about that manual depmod, did you have more info on that somewhere? [11:21] 2.6G of modules is intense ;) [11:21] zyga-phone So at this moment a daemon will always start at startup? [11:24] ppisati: lots of modules build automatically :( [11:25] ricmm: we build as many modules as possible [11:25] noizer: yes [11:26] hmmm ok [11:26] ppisati: sure, how do we then select which ones to package? [11:26] I'm assuming this is the depmod magic that ogra is talking about [11:26] depmod -ea -F unpack-19022016/boot/System.map-4.2.0-2014-generic-dragon410c -b xenial-chroot/snap/ 4.2.0-2014-generic-dragon410c [11:26] that's from my shell history [11:26] for the last build [11:28] -F is the part to System.map, -b is your target dir [11:29] s/part/path [11:29] instead of -a you can also give a list of .ko files [11:30] (at the end of the line then) [11:32] ogra_: thanks [11:32] ricmm, the depmod "magic" is only to create the modules.dep files, nothing more ... else modprobe wouldnt work [11:32] it doesnt make any selection about what gets installed [11:32] ok, and in your snap what are you making about the 2.6G of modules? [11:32] i dont have 2.6G of modules [11:32] :) [11:33] i use the binary deb and unpack it ... [11:33] right, so maybe a q for paolo [11:34] ppisati: I see 2.6G of modules if I build manually, but only 400MB in the package [11:34] linux-image-* is 52MB big (the deb( [11:35] unless ppisati invented an awesome new comoression method and will get very rich with that i guess you are building to much or counting it wrong :) [11:35] *compression [11:35] 400MB ? thats cerazy [11:36] ok, 200 [11:36] ;) [11:36] -rw-r--r-- 1 ppisati ppisati 55214720 Mar 1 10:18 linux-image-4.4.0-1012-96boards_4.4.0-1012.12_arm64.deb [11:36] mvo, i was wondering if we should not consider to mount the vfat not async anymore and instead make a few sync calls in the code that copies the kernel in place [11:36] mvo, my last dragonboard update took ages [11:37] from the uboot env POV we should be fine [11:37] and mounting sync wont gain us much for kernel and initrd copying [11:40] (weather it gets corrupt while doing a sync call with power loss or while syncing due to the mount option doesnt really matter( [11:44] ogra_: yeah, +1 [11:44] I try to make a socket but I gets always a permission error. this are my skill that I uses: uses: [11:44] listener: [11:44] type : migration-skill [11:44] caps: [11:44] - network-client [11:44] - network-listener [11:44] ogra_: just go ahead and change it [11:44] Somebody nows more about it? [11:45] mvo, great, will do [11:45] ta [11:46] ogra_: do you happen to have any idea why only two amd64 builders are online right now? [11:46] nops [11:47] i guess thats a colin/adam question [11:47] * ogra_ bets doko has eaten them ;) [11:47] I go and ask on #launchpad [11:47] thanks [11:59] mvo, hmm, what about the efi dir, that is currently also mounted with "sync" [12:00] (not sure if firmware requires that) [12:00] ogra_: its the same filesystem/partiton iirc . I don't think we actually write anything to it [12:00] ogra_: we just need it for the efi binaries [12:00] well, its a different code path, thats why i ask [12:00] * ogra_ switches it to "defaults" from "sync" as well [12:02] yeah, lets do it and see what breaks [12:02] noizer: s/type: migration-skill/interface: old-security/ [12:04] zyga-phone snapcraft doesn't support it for now so I wait for today so that i can have a new snapcraft [12:04] noizer: yeah, I know :-( [12:05] zyga-phone I want it so bad xD [12:05] noizer: we're working on a release, you just have to wait a little longer [12:06] zyga-phone what is a little longer? [12:07] noizer: we still plan to release today [12:07] noizer: no further ETA [12:07] zyga-phone owkay === morphis_ is now known as morphis [12:20] ricmm: if you want to put your kernel/modules on diet , turn off this option in the .config [12:20] mvo, hmm, i see you tried to upload a 4.4 dragonboard kernel to the store, where does that come from ? i see no deb anywhere for it [12:20] ricmm: CONFIG_DEBUG_INFO=y [12:20] ricmm: to # CONFIG_DEBUG_INFO is disabled [12:20] ogra_: its the generic arm64 kernel, but I removed that version from the publishing history [12:21] ricmm: this will greatly reduce the size of kernel / modules.ko [12:21] ah, k [12:21] mvo, what makes you think that would boot ? :) [12:21] ogra_: hopeless optimism ;) [12:21] haha [12:21] ogra_: but seriously, after uploading I remembered it would probably not work and immediately removed it from the channels [12:22] ppisati, do we have any newerr dragonboard kernel than your linux-dragon410c - 4.2.0-2014.14 yet ? [12:22] ogra_: I need to test the beaglebone though, that should work with the stock kernel [12:22] i know you were working on something 4.4ish [12:22] mvo, yeah [12:23] GRRRR ! [12:23] Installing ubuntu-core.canonical_16.04.0-9.arm64_arm64.snap [12:23] WARNING: could not unmap partitions [12:23] WARNING: unexpected issue: remove /tmp/diskimage493904108/system/apps: read-only file system [12:23] ... [12:23] i wish u-d-f would still work on trusty [12:23] * ogra_ goes and builds on a wily system [12:24] ppisati: well im basically trying to replicate the module list from your kernel package [12:25] Will Snappy Core support Raspberry PI 3? [12:26] Rinsan, at some point, yes [12:27] i was looking at that on the weekend, but it seems u-boot isnt fully there yet for the Pi3 ... and snappy needs u-boot [12:27] ogra_, Ok thanks for the quick reply! [12:27] if thats ready i'll surely try to integrate it [12:28] So it [12:28] Sorry... cat :) [12:29] ricmm: by default our config has the debug info built-in, and then we strip the symbols out for the vanilla linux-image deb package [12:30] ricmm: this way from the same config we build debug version and (after stripping) the non debug version [12:30] ricmm: so either you keep the config as is, and then strip out the symbols [12:31] ricmm: or disable that option [12:33] ppisati, while we talk about options ... can we trun off that scary kernel message on boot about trace_printk() ? http://paste.ubuntu.com/15320455/ [12:33] doesnt really seem appropriate for release [12:41] ogra_: i agree, last week i tried to disable that but i couldn't figure out [12:41] ah, k [12:41] ogra_: like, even turning off that debug option the message was still there [12:41] ogra_: but yeah, i'll turn it off [12:41] ogra_: about 4.4 [12:41] ogra_: i have two trees [12:42] but only one deb :) [12:42] ogra_: one is the qualcomm-only and the other is the merged qualcomm+hikey [12:42] ogra_: hold on [12:42] This means syscall number 289 has been called? http://pastebin.com/uE4tGQCA [12:42] ysionneau, exactly [12:42] not sure how to know which one it is [12:42] I'm browsing the kernel sources ... [12:43] ysionneau, scmp_sys_resolver 289 [12:43] ogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-4.4.0-1006-snapdragon_4.4.0-1006.6_arm64.deb [12:43] that prints the name [12:43] ogra_: it's a couple of weeks old, i'm waiting for qualcomm to announce their support period for that kernel this week @ connect [12:43] ppisati, ah, thanks ... do you think thats stable enough to switch to it ? [12:44] nice! it's send() [12:44] thx [12:44] ogra_: it's stable, but don't switcj until we hit the archive [12:44] ok [12:44] send is forbidden by default? [12:45] you need the network-client "capability^Wskill^Wslot^Wplug" [12:45] ahahah [12:45] or just "network" not sure ... try them out [12:45] the name bikeshedding is going crazy [12:45] there are a few [12:46] this really needs to be documented somewhere [12:47] it is in total flux ... but i think there are docs (dont as me where though) [12:48] I'll try what Michael Vogt sent on march the 1st "snap.yaml skill->interface change" [12:48] or maybe it's not yet effective [12:48] only half [12:48] slots and plugs have been flipped around [12:49] or was ist s/slots/sockets/ ? [12:49] "things" [12:49] :P [12:50] yes and followed by emails about changing the names again [12:50] thats what i mean [12:50] ysionneau: it's not released, just wait for the release [12:50] there is a pending os snap (in testing atm) that should have the final implementations [12:51] ysionneau: all the docs have been updated but the bit relase is in the making [12:51] if you have a link to all the security/caps/overrides stuff doc' :') [12:51] please do share :) [13:02] ysionneau: we'll release public docs soon [13:05] \o/ [13:15] lots of interesting documentation in here: https://github.com/ubuntu-core/snapcraft/blob/master/docs/debug.md === beowulf_ is now known as beowulf [13:21] don't know if you are aware of that but snappy-debug.security crashes: http://pastebin.com/ekxwPREL [13:23] mvo, new os snap boots on arm64 ... i still see it trying to run grub migration (and fail), beyond that it seems fine [13:23] ogra_: great, thanks! [13:23] mvo, any package in the sotre that i should try to make sure the changes work ? [13:23] *store [13:27] wow, gross ... so installing a package from the store succeeds, the services dont start though and there is no error message at all [13:28] Chipaca, ^^^ snappy install should really spill an error for that [13:29] (syslog is full of denials at least ... but there was no idication at all that anything failed when using snappy install) [13:32] mvo, i also still see bug 1543764 [13:32] bug 1543764 in Snappy "snappy classic must use officially supported lxd images from simplestream; not unsupported ones from linux-containers.org" [High,New] https://launchpad.net/bugs/1543764 [13:33] (i.e. no classic mode at all on arm64) [13:37] ogra_: I know :( [14:01] iahmad: I'm just seeing the meeting now. Are you guys still around? [14:09] does somebody used seccomp filters before in snappy? [14:16] any idea why I get this error message ? http://pastebin.com/LawTNuDi [14:16] I'm using latest commit from master of snapcraft (github) [14:22] zyga-phone: that's awesome [14:22] zyga-phone: (https://github.com/ubuntu-core/snappy/pull/591/files) [14:26] jdstrand: I'll fan out with more of those later today, they should be easy to maintain for anyone on the security team [14:27] zyga-phone: cool, thanks [14:29] jdstrand: I'll also move the base apparmor template [14:30] jdstrand: so that there's no dependency on the base security templates anywhere and it's all self-contained [14:32] zyga-phone: sure-- I thought of another case where all of it in the go code is painful but I understand why you are doing it this way. I look forward to working through this after 16.04 some time [14:34] jdstrand: with all the bits in snappy we can at least consistently push new test snapd over, I know it's not like editing files manually but they are on squashfs anyway now [14:34] jdstrand: do you know my devtools scripts? [14:42] elopio, I have rescheduled it for later today, let me know if that works for you? [14:43] iahmad: yes, it works. We can make it 30 minutes earlier also, so you don't stay so late. [14:44] elopio, ok, let me check with jibel [14:46] elopio, scheduled time is fine [14:46] alright. [15:58] hmm that does not sound right https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/common.py#L35 [15:58] what if you install by doing python3 setup.py develop --user [15:58] ? [15:58] then it will still try to fetch the schema from /usr/share/snapcraft [15:58] even though it should look in the source dir [16:00] mvo: http://bazaar.launchpad.net/~click-reviewers/click-reviewers-tools/trunk/view/head:/clickreviews/common.py#L39 [16:00] mvo: basically, the review tools, snapcraft (and now I learned) snappy build need to use the same options to mksquashfs otherwise the resquash test in the store will fail [16:01] * jdstrand didn't realize snappy build was still around (that's fine, it's just I would have communicated this ooner) [16:01] sooner* [16:02] jdstrand: cool, fixing now [16:02] thanks [16:07] sorry I missed that: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/dirs.py#L30 [16:08] so there is no issue :p [16:36] Hi is it possible to do some changes on the apparmor? in an app? [16:36] jdstrand: I pushed a branch for --no-xattrs [16:36] jdstrand: I can not do --all-root, this breaks the OS snap which has various files that are not owned by root [16:37] jdstrand: like /var/mail [16:49] mvo: can you do --all-root when 'type: app' or 'type: framework'? [16:50] mvo what are the possibilities of changing the apparmor of your snap? [16:55] jdstrand: yeah, that would be ok [16:56] jdstrand: essentially !os -> all-root [16:56] mvo: I think that sounds like a fine start [16:57] this does mean I'll probably not be able to do a resquash test for the os snap though [16:57] I think that is ok considering it will always come from a trusted source [17:45] is snapcraft already updated? [17:56] kyrofa, https://plus.google.com/+DrewFustini/posts/1Z5iPDsYaXy perhaps you might like to chime into the ROS discussion here [18:15] ogra_: hey [18:15] yo [18:16] ogra_: FYI, we're changing some stuff around ubuntu-core-launcher [18:16] ogra_: I'll simplify it to take less arguments and just be smarter as to what it is doing [18:16] hmm [18:16] ogra_: and I'm killing/changing some of the environment as well [18:16] ogra_: all TMP* bits are now gone from the generated wrapper (the launcher handles that) [18:16] i havent seen any snap yet that actually used the launcher directly [18:16] ogra_: I've dropped SNAP_FULLNAME [18:16] ogra_: none of them do, it's just FYI [18:17] ah [18:17] ogra_: and SNAP_ORIGIN becomes SNAP_DEVELOPER with actual developer bits inside [18:17] * ogra_ has never used either :) [18:18] thanks for the info though :) [18:53] kyrofa: hey there [18:53] kyrofa: sorry, been busy the last weeks [18:54] kyrofa: I felt confident in your work, it felt like I was only slowing things down :) === jkridner|work is now known as jkridner [19:14] kyrofa: anything I can help you with? [20:12] jdstrand: hey [20:12] jdstrand: aroudn? [20:36] zyga: hey, I have a little time before my next meeting [20:42] jdstrand: hey, I'm changing ubuntu-core-launcher a little [20:42] jdstrand: I'll make it take just 'snap.[app]' + command to execute as input [20:43] jdstrand: and derive all the security tokens from snap.[app] [20:43] jdstrand: this affects aa profile, seccomp and the udev tag [20:45] jdstrand: I wanted to let you know that this is happening [20:45] jdstrand: also the launcher will change the name of the executable but that's less important [20:45] jdstrand: (I mean that the launcher will be renamed, not that the launched application will think it got renamed) [20:45] zyga: so, you are going to be touching the privileged part of the code then. this will also need changes to the systemd unit generation and the scripts generation [20:47] zyga: how are you going to derive all security tokens from snap.[app]? [20:47] jdstrand: I know, I'll handle both changes [20:47] each command has a different profile and how will you determine the version? [20:47] jdstrand: I plan to rename the aa profile to snap-$snapName.$appName [20:47] jdstrand: we'll drop the version [20:47] these are big changes [20:48] jdstrand: various files will be hard-coded (location is /snappy/$snapName/current/ + $command [20:48] have they been discussed anywhere else? [20:48] jdstrand: we've just brainstormed this on telegram a little with niemeyer and Chipaca [20:48] I wish I was part of that conversation [20:49] jdstrand: Sorry, this has been talked about literally an hour ago [20:49] jdstrand: I can provide the full background to it [20:49] unfortunately this is a difficult day to participate in these conversations because I have a ton of meetings [20:50] jdstrand: and this is still a strawman, so please don't feel like we have decided without you.. chipaca and mvogt haven't even seen that conversation yet, so these changes are being made in an attempt to improve the status quo, if it passes through reviews [20:50] is there a doc or something I can look at/think about/respond to? [20:50] I see [20:50] it sounded more concrete a moment ago :) [20:50] jdstrand: No, but I can either: a) Explain here; or b) Write an email and send to the list [20:51] jdstrand: The proposal is concrete [20:51] I don't mind changing stuff, I just want to understand why we are changing and the changes themselves [20:51] jdstrand: But it's not done until we say so [20:51] jdstrand: Okay, do you prefer a or b? [20:52] To be clear, this is my proposal.. Chipaca hasn't seen it yet as it's too late there [20:52] I am not going to have time for 'a' today. I will have time for 'a' tomorrow. I could even do a hangout [20:52] if that doesn't work, 'b' [20:52] maybe a hangout with the 5 of us? [20:52] jdstrand: Ok, let me shoot an email to the list first then, since people will see the proposals earlier than that, and we can get together in a hangout to decide on ripples from that [20:52] tomorrow at 1500 UTC-ish [20:52] ok, that's fine too [20:53] +1, thanks everyone :) [20:53] Indeed, thanks to you both [20:54] np