[14:49] <dholbach> slangasek, do you know who's running the node.js/libv8 session?
[14:55] <dholbach> slangasek, ping?
[14:55] <dholbach> alecu, do you maybe know who's running the next session?
[14:58] <alecu> dholbach: it says "Created by: Matthias Klose"
[14:58] <dholbach> ok... but he's not online
[14:58] <dholbach> slangasek, ^
[14:59] <dholbach> I can set the session up
[14:59] <dholbach> but I'm not sure what to say.................
[15:00] <ogra_> you could show a slideshow of nice V8 cars :P
[15:01] <alecu> dholbach: I guess somebody from distro and the people in security team that are marked as attending the session need to be in that
[15:01] <dholbach> setting it up now
[15:01] <alecu> dholbach: I'm joining because we are using node.js and v8 for the new scope bindings.
[15:01] <dholbach> ok, give me another sec or two
[15:02] <tyhicks> can chrisccoulson and I join the hangout?
[15:02] <dholbach> sure
[15:02] <dholbach> https://plus.google.com/hangouts/_/hoaevent/AP36tYeYeH42x7l09uefcnXCEwsjsCdU5h69oxDhB-7mgeYodV05bA
[15:02] <alecu> great
[15:03] <slangasek> dholbach: sorry, was working on getting it set up; I'll join that one
[15:04] <dholbach> we'll start in a minute
[15:07] <dholbach> Notes are up here: http://pad.ubuntu.com/uos-1511-nodejs-and-libv8-for-1604
[15:12] <marcustomlinson> yes node embeds v8 it does not depend on a shared v8
[15:14] <marcustomlinson> we are embedding node into our own binary
[15:14] <marcustomlinson> as it is not available in universe or main
[15:15] <marcustomlinson> our executable embeds node and is shipped within a scope click
[15:16] <marcustomlinson> we take on the responsibility of keeping the node we embed up to date
[15:18] <marcustomlinson> we update node, we fix our internals, and our API/ABI to remain stable
[15:18] <dholbach> marcustomlinson, if you want to join the hangout, let me know
[15:19] <marcustomlinson> (sorry I have bronchitis, voice is broken)
[15:19] <dholbach> ok, no worries
[15:19] <dholbach> I relayed your comment
[15:27] <marcustomlinson> yes, v8 code is litterally part of the node source tree
[15:28] <marcustomlinson> https://github.com/nodejs/node/tree/master/deps/v8
[15:28] <marcustomlinson> they pull it in statically, no dynamic linking
[15:28] <tyhicks> get to feeling better, marcustomlinson :)
[15:29] <marcustomlinson> tyhicks: will do
[15:29] <marcustomlinson> :)
[15:29] <dholbach> yeah, all the best!
[15:50] <dholbach> doko, do you know if barry is running the next session?
[15:51] <doko> dholbach, we will be both there, he created https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
[15:51] <dholbach> ok... is anyone of you setting up and running the session?
[15:51] <dholbach> https://wiki.ubuntu.com/UDS/Sessions
[15:52] <dholbach> hey barry
[15:52] <dholbach> are you setting up and running the session?
[15:52] <barry> dholbach: hi
[15:52] <dholbach> https://wiki.ubuntu.com/UDS/Sessions
[15:52] <barry> yeah, i guess i should go to the other room now (we're sprinting
[15:53] <dholbach> ok cool
[15:53] <dholbach> let me know if you need help
[15:55] <barry> dholbach: technically it's doko's session :)
[15:55] <dholbach> ok...
[15:56] <dholbach> I asked doko earlier
[15:56] <dholbach> I wasn't quite sure who was running it
[15:58] <slangasek> https://plus.google.com/hangouts/_/hoaevent/AP36tYdzlG929T3_3v8ifrDi3Hp2h0Tz8wZVRcdk07fcQA61nJdA6g?hl=en&authuser=0
[15:58] <dholbach> I think the time of the session was set wrong
[15:59] <dholbach> the video currently says 9:00:45
[15:59] <slangasek> barry: ^^
[15:59] <dholbach> but maybe it doesn't matter and you can just hit start and it'll just work
[15:59] <slangasek> dholbach: hmmm I said 'starting now' :)
[15:59] <dholbach> I don't know <3
[15:59] <dholbach> oh ok
[15:59] <dholbach> that's on http://summit.ubuntu.com/uos-1511/meeting/22568/python3-only-on-the-images/?
[16:00] <dholbach> 8:59:50 now
[16:00] <slangasek> dholbach: when creating the hangout
[16:00] <slangasek> so anyway, I don't know
[16:01] <dholbach> maybe just start the hangout and see if it works
[16:02] <doko> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3
[16:02] <barry> https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
[16:02] <dholbach> ok, seems to be working :)
[16:03] <dholbach> yes
[16:03] <dholbach> can hear you
[16:03] <dholbach> go go go
[16:03] <dholbach> :)
[16:03] <dholbach> https://docs.google.com/spreadsheets/d/1PnPLZRM2hu7ucv1yuq7Fd5hjNw_DYupHIYZpoP4-xHk/edit?pli=1#gid=1918227221
[16:05] <smadden_landscap> landscape-client-ui-install can be purged.  It is unsupported today
[16:05] <slangasek> smadden_landscap: oh great :)
[16:06] <slangasek> smadden_landscap: did you want to join us on the hangout, or are you just delivering the good news?
[16:06] <smadden_landscap> sure, I'd like to join
[16:06] <slangasek> smadden_landscap: //plus.google.com/hangouts/_/hoaevent/AP36tYdzlG929T3_3v8ifrDi3Hp2h0Tz8wZVRcdk07fcQA61nJdA6g?hl=en&authuser=0
[16:06] <willcooke> Trevinho, any ideas on what Python2 is needed by U7?
[16:08] <Trevinho> willcooke: it's needed by Autopilot, but not by unity itself I think
[16:08] <Trevinho> let me check whether the unity script needs, it but  I don't think so
[16:08] <Trevinho> or the migration scripts..
[16:08] <barry> willcooke: tools/unity.cmake
[16:09] <jrjrtgerg> the unity scope depends on software-center in my testing (or at least apt daemon)
[16:09] <barry> willcooke: LP: #1512909
[16:09] <barry> (there's a patch for that but it doesn't build yet for unrelated reasons i think)
[16:10] <willcooke> Trevinho, ^^
[16:13] <demmot> you can authenticate to the rnr server and or the store without using the ubuntu-sso-client fairly easily
[16:13] <demmot> it's a few oauth calls
[16:14] <demmot> unity scope applications gets its data from the software-center database though..
[16:15] <willcooke> thanks demmot
[16:15] <willcooke> seb128, I'll speak to robert_ancell about that ^^
[16:15] <seb128> willcooke, k, thanks
[16:22] <smoser> rdepends also shows python-apt
[16:22] <Laney> hi
[16:22] <Laney> yes I think that g-s uses xapian
[16:23] <Laney> via libappstream
[16:23] <Laney> you can see they are linked
[16:23] <Laney> seb128: slangasek
[16:23] <slangasek> Laney: thanks
[16:25] <seb128> Laney, thanks
[16:26] <dholbach> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781913
[16:27] <dholbach> ?
[16:27] <doko> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781913
[16:34] <slangasek> barry, doko: we seem to have skipped over system-config-printer on the desktop?
[16:34] <slangasek> sorry, my hangouts connection failed, so the broadcast will have been interrupted
[16:36] <zyga> hey
[16:36] <smoser> oh.. to come back to it.
[16:36] <smoser> cloud images were free of python2.7
[16:36] <zyga> about checkbox
[16:36] <smoser> but not libpython2.7
[16:36] <zyga> python2 is only needed by one test
[16:36] <smoser> there was a vim bug /dep on libpython2.7
[16:36] <zyga> we can drop that test from the desktop
[16:36] <zyga> it's OpenCV related AFAIR
[16:37] <seb128> https://bugs.launchpad.net/bugs/1512642
[16:37] <willcooke> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1512641
[16:37] <zyga> we can easily separate that as checkbox and the tests are separate packages
[16:37] <willcooke> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1512642
[16:37] <zyga> checkbox and plainbox are pure python3
[16:37] <seb128> https://bugs.launchpad.net/bugs/1512641
[16:37] <doko> smoser, we could just build vim with python3 bindings
[16:37] <smoser> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729924
[16:37] <zyga> we requested the removal of the checkbox package to replace it with a new stack that uses SDK apis
[16:37] <smoser> infinity had some comments on that (vim and python3)
[16:37] <zyga> so please stay reassured that checkbox will by python3 clean :)
[16:38] <barry> zyga: thanks
[16:39] <zyga> :-)
[16:39] <doko> https://bugs.launchpad.net/ubuntu/+source/libpeas/+bug/1440504
[16:40] <yofel> Well, from a kubuntu side we can look at things ourselves, but we're also affected by stuff like apt-xapian-index or ubuntu-sso-client, so some coordination place would be nice
[16:42] <dholbach> barry, there's delay
[16:43] <smoser> (i've verified and updated etherpad. 15.10 server install with default ends up with only libpython2.7-*, and that is rdpended on only by vim)
[16:43] <smoser>  http://paste.ubuntu.com/13102639/
[16:43] <smoser> cloud image now has lxd -> lxc -> cloud-image-utils . and smoser will drop/fix cloud-image-utils need of python2
[16:46] <jrjrtgerg> plan is to drop ubuntu software center really soon?
[16:47] <yofel> nah, the bugs are probably enough
[16:47] <yofel> we can just mark those as affecting it
[16:47] <barry> yofel: cool thanks
[16:47] <yofel> *affecting us
[16:47] <jrjrtgerg> lubuntu bug - https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1465313
[16:48] <jrjrtgerg> samba and system-config-printer seem like the big ones that are cross flavor issues
[16:49] <smoser> https://gist.github.com/smoser/8904199bb8f00a90dd04
[16:52] <slangasek> are you familiar with this technique? http://paste.ubuntu.com/13102740/
[16:53] <slangasek> (we may have talked about this before, smoser ?)
[16:53] <smoser> i did see that.
[16:53] <smoser> slangasek, yeah.
[16:53] <smoser> its interesting.
[16:53] <smoser> curtin has a solution too
[17:04] <barry> >
[17:59] <cyphermox> http://youtu.be/I4ci-GeJIQw
[17:59] <cyphermox> ^ for anyone who wants to follow, we'll watch questions on IRC too of course
[17:59] <cyphermox> who is here for this session
[17:59] <cyphermox> ?
[18:00] <slangasek> cyphermox: can we share the hangout url here too for anyone else who wants to join the discussion?
[18:00] <cyphermox> yeah I was just grabbing that
[18:00] <cyphermox> https://plus.google.com/hangouts/_/qmal77cb6ezen6vpzuovvs3lkua
[18:00] <cyphermox> ^ the hangout URL
[18:01] <cyphermox> I won't make it broadcast unless we aren't the only ones here for the session though
[18:01] <slangasek> cmagina: hi, here to talk about capsule updates?
[18:01] <ogra_> nespresso !
[18:02] <cyphermox> ogra_: ?
[18:02] <ogra_> (no, wait , different capsules)
[18:02] <slangasek> heh, nespresso capsules
[18:02] <ogra_> :)
[18:02] <cyphermox> eep.
[18:02] <TJ-> I'm here :) but not on hangouts/whatever
[18:02] <cmagina> slangasek: curious about it :)
[18:02] <pjones> cyphermox: turns out I can't watch it anyway due to some video compat problem :P
[18:02] <slangasek> sorry this capsule is not signed with the right key
[18:02] <cyphermox> alright, let's give it a go then
[18:02] <ogra_> haha
[18:02] <slangasek> pjones: shoulda run Ubuntu
[18:02] <slangasek> ;)
[18:03] <TJ-> Interested in this since I've had some experience with capsule updates - painful
[18:03] <pjones> slangasek: oh yeah, that's probably the issue :P
[18:04] <cyphermox> http://pad.ubuntu.com/uos-1511-core-1511-efi-capsule-and-fallback
[18:05] <TJ-> I looked at the blueprint; i'd suggest the capsule path be /usr/share/uefi/capsule/ or similar, rather like /usr/share/misc/, rather than /opt/<vendor>/
[18:06] <cyphermox> https://blueprints.launchpad.net/ubuntu/+spec/core-1511-efi-capsule-and-fallback
[18:07] <cyphermox> https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-uefi-capsule-update
[18:09] <superm1> https://secure-lvfs.rhcloud.com/
[18:10] <superm1> is the URL
[18:10] <TJ-> Also, with the fwupdate tool, some easy-to-use mechanism to delegate the update work to a BIOS vendor's own tooling, such as H2O-FFT
[18:10] <superm1> fwupd puts it the appstream data in /var/cache
[18:11] <pjones> (also https://beta-lvfs.rhcloud.com/ may be more interesting)
[18:12] <superm1> and of course http://www.fwupd.org/ being most interesting
[18:14] <superm1> gnome-software
[18:14] <superm1> has support for fwupd
[18:14] <superm1> already
[18:14] <superm1> once fwupd clears NEW in debian we were planning to enable it in Debian with gnome-software too
[18:19] <superm1> the vendor specific tooling isn't supposed to be activated until UpdateCapsule() is called.  it's all a vendor specific implementation at that point
[18:22] <cyphermox> TJ-: do you have more questions?
[18:22] <cyphermox> quigley: and you?
[18:22] <TJ-> Idea rather than question: Being able to preload a portable image with many capsules and use it on multiple systems should be a use-case to cover. Enterprises may not want to risk their users handling/invoking a firmware update, but have it done either remotely, by PXE boot image, or USB mass-storage
[18:23] <superm1> mass storage is already supported
[18:23] <superm1> fwupdmgr install blah.cab
[18:23] <quigley> I don't see why that wouldn't just work
[18:23] <cyphermox> you could already do that, as long as the device loads the efi binary for fwupdate
[18:23] <pjones> TJ-: from an upstream perspective, we've been assuming the enterprise will have the ability to remotely schedule it without the user involved, but it still runs through the local userland software
[18:24] <TJ-> Good. just didn't see anything specific mentioning it
[18:24] <superm1> at least today most BIOS'es don't support PXE in UEFI mode
[18:25] <superm1> you have to load a CSM
[18:25] <pjones> (pxe booting it won't *quite* work yet; we need a local filesystem currently.  but it's on my todo without a lot more work to do on it.)
[18:25] <cyphermox> but it can be done
[18:25] <pjones> superm1: lots do support dhcp+tftp (as opposed to the bios "pxe" api), but yeah.
[18:25] <cyphermox> oh right, because we look locally for the firmware images?
[18:25] <pjones> cyphermox: right; right now we don't support network device paths
[18:25] <cyphermox> yeah
[18:25] <superm1> yeah, but that's also assuming a working network stack in the BIOS at that time too
[18:26] <pjones> I have like 80% of that in my local tree from this friday.
[18:26] <pjones> superm1: yes, it is.
[18:26] <TJ-> The only thing that occurs to me, based on the Whiteboard... is there a Process: Option 0 = a check-script that looks up the system ID against available updates and lets the user know... which would lead to Options 1/2
[18:27] <TJ-> in other words, prior to a download action by the user, to make them aware without them needing to initiate
[18:29] <cyphermox> TJ-: right now you need to run fwupdmgr refresh to look for updates, it could be cronned
[18:30] <cyphermox> but in the future we might want to get that done graphically/automatically some other way
[18:30] <pjones> I think if you're using gnome-software it'll do that for you?
[18:30] <cyphermox> ie. gnome-software that we mentioned earlier
[18:30] <slangasek> well, and in fact if this is going to be using the appstream service and using gnome-software, there will need to be integration for that
[18:30]  * pjones isn't really sure about that end of the stack
[18:30] <slangasek> today we use a cronjob + update-notifier to display the status of update availability
[18:30] <zyga> superm1: hey, I'm curious about pxe and uefi mode, why is that not supported?
[18:31] <cyphermox> slangasek: it's not like we couldn't do what software updates do already, look every once in a while and ask the user ifthey want to apply the new updates
[18:31] <slangasek> I don't know in the gnome-software world what polls for updates, but that would surely need to poll this service
[18:31] <pjones> zyga: many firmwares don't support it, and those that do typically only recognize the addressing if they've been configured to boot via the network
[18:32] <pjones> zyga: so even if they know about it, using the network to fetch the image without actually /booting/ from it won't work without a lot more code.
[18:32] <cyphermox> right
[18:32] <zyga> I see
[18:32] <pjones> zyga: so basically because hardware vendors believe netboot is a value add and don't support it on their low-end machines.
[18:32] <superm1> zyga: traditional PXE support as we all know and love comes from the CSM generally (legacy boot mode)
[18:33] <superm1> UEFI netboot operates a bit differently in what you'll actually be booting
[18:33] <zyga> I'm interested in using the UEFI network stack
[18:33] <zyga> to do $stuff
[18:34] <zyga> where stuff is related to replacing what I'm booting
[18:35] <pjones> zyga: at the risk of being too helpful to ubuntu people, https://fedoraproject.org/wiki/QA:Testcase_UEFI_pxeboot :)
[18:36] <pjones> except that was written for our hacked up grub 0.97 efi binary; substitute a grub.cfg for the obvious difference.
[18:36] <zyga> pjones: interesting, I was thinking about something slightly different but I will check it out to lear more about it
[18:36] <zyga> pjones: I was thinking about using the network stack to boot one or other local disk
[18:37] <zyga> pjones: not about complete netboot
[18:38] <TJ-> cron-job + update-notifier approach would be good especially for headless hardware, and to support non-gnome flavours
[18:39] <superm1> TJ-: yeah a script around fwupdmgr refresh and grep fwupdmgr get-updates would be sufficient for that.  when you want to do an update it's just fwupdmgr update
[18:40] <TJ-> longer-term, something like the debian/control Modaliases: might be useful too, to search archive packages using ubuntu-drivers
[18:42] <pjones> TJ-: superm1: if either of you wanted to help with that in fwupd , a "give me esrt info for this system" and a "look up info for this arbitrary ESRT dataset" call would let you split that up pretty nicely...
[18:42] <TJ-> Good to see the progress on this; seeing far too much firmware-bug induced user issues the past 12 months - that combined with ACPI firmware bugs
[18:42] <superm1> it would be easier to teach ubuntu-drivers to parse appstream data in my opinion
[18:43] <pjones> so you could connect to dbus with whatever remote agent you have and ask for details, and then grab stuff on a common server end.
[18:43] <superm1> than to repackage all the data into dummy debian packages
[18:43] <TJ-> superm1: right, just thinking about the common tool and how it currently works
[18:44] <pjones> Well, write what you like.  I just hope we can avoid too much unneeded duplication of effort.
[18:44] <superm1> Yeah agree
[18:59] <h4ck3r> secureboot sign for ubuntu EFI
[19:00] <h4ck3r> is there any method to implements signature for EFI with ubuntu EFI file?