[OE-core] OpenEmbedded TSC Meeting Minutes 2019-12-16

Tue Dec 17 15:05:32 UTC 2019

OpenEmbedded Technical Steering Committee (TSC) Meeting Minutes 2019-12-17
==========================================================================

Meeting was held in #oe-tsc on Freenode; channel access public.

Present:
- Richard Purdie (RP)
- Joshua Watt (JPEW)
- Martin Jansa (JaMa)
- Bruce Ashfield (zeddii)
- Paul Eggleton (bluelightning)

Summary:
- reproducible builds, hashequiv and security-flags will be enabled
  in default nodistro builds
- nobody really likes using new SPDX indentifiers in LICENSE variables
  but we still might be interested to do that

Full meeting log
----------------
16:33 < JPEW> Reminder: TSC meeting today at 10PM UTC
16:38 <+RP> JPEW: Paul won't be able to make it unfortunately
16:38 <+RP> JPEW: did we have agenda items?
16:38 < JPEW> RP: None on the wiki
23:00  * RP is here FWIW
23:01 <+RP> I actually rushed back as I've been without the computer for a few hours
23:01 < zeddii> I'm willing to dial in!
23:01 <+RP> zeddii: its irc based here isn't it?
23:02 < zeddii> oh.
23:02 < zeddii> right
23:02  * zeddii takes off his corporate hat
23:02 < JPEW> Is there anything to discuss?
23:02 <+RP> zeddii: I kind of prefer calls now but I can see the pros/cons
23:02 <+RP> I guess one topic is defaults for nodistro in OE-Core
23:03  * JaMa waves
23:03 <+RP> and there is the removal discussion re: the layer index. We don't have a specific proposal to consider
23:04 <+RP> Unfortunately Paul can't make it today due to holiday commitments :(
23:04 < zeddii> was the supported build host question more of a yocto discussion ?
23:04 <+RP> Since we have four of us, I would like to solcit opinions on reproducible builds by default for no distro and hash equiv by default
23:05 <+RP> zeddii: yes, although we could consider that from a general OE standpoint too
23:05 < JaMa> There was also OE-TSC mentioned in meta-python2 thread http://lists.openembedded.org/pipermail/openembedded-devel/2019-December/203383.html but the discussion stalled and it's not clear if we need to make some decision or not
23:06 <+RP> JaMa: From my memories of that thread I think its also unclear
23:07 <+RP> So, first question - should nodistro have reproducible builds enabled by default? Any strong opinions?
23:07 <+RP> I'd highlight that enabling it makes hashequiv more effective
23:07 < JPEW> RP: Ya, If we do hashequiv by default, that reproducible should also be by default
23:07 <+RP> and Poky is now doing this by default. In many ways I think it makes sense as a default for all users out the box
23:07 < JaMa> I think yes, we should enable as much "useful-to-have" options in nodistro config as possible
23:08 <+RP> It also reduces support load in some ways as we can assume that configuration on the most part
23:08 < zeddii> agreed
23:08 <+RP> ok, that sounds like we're all in agreement :)
23:08 <+RP> Second question - local hash equiv server on by default?
23:09 <+RP> I'd also propose yes. Its the future and we want people using it
23:09 < zeddii> I’d agree with that. to get mileage on it, it needs to be opt-out .. or things will linger forever.
23:09 <+RP> In local mode its fairly useful/stable now. We're seeing some issues on a 40 worker setup with a common server on the autobuilder which isn't a default use
23:10 <+RP> I'd really like to have a standard config we have people using so people use what we test
23:10 < JPEW> RP: Agreed
23:10 <+RP> Having it "in staging" in -next was half killing me
23:10 < JaMa> I've enabled it for most of my local builds last week and haven't seen any significant difference (for better or worse), I agree it's future and should be enabled by default (to get better test coverage by everybody)
23:11 <+RP> Obviously people can configure these things out, its the default we're talking about
23:11 < JPEW> Are the AB builds that khem does nodistro?
23:11 <+RP> That sounds like an agreement. I will look into patches and propose them. Its just helpful to have a general guidance for it
23:13 <+RP> JPEW: no, they use poky
23:13 <+RP> we do run a nodistro test build there
23:13 <+RP> but not for meta-oe
23:13 < JPEW> RP: OK
23:13 <+RP> How much of OE we can test on the autobuilder remains to be seen...
23:14 < JPEW> RP: Ya fair enough, I was just curious
23:14 <+RP> With SWAT disbanded and only a small number of people working on fixing the autobuilder issues that come up we have real challenges with the build failures we have
23:15 <+RP> Its a YP issue but ideas very welcome on how to improve things as it obviously affects OE too
23:15 -!- bluelightning [~paul at pdpc/supporter/professional/bluelightning] has joined #oe-tsc
23:15 <+RP> bluelightning: hi, I thought you weren't here!
23:16 < bluelightning> RP: people are still packing for our trip, I thought I'd check in :)
23:16 < JPEW> I forgot to ask, is anyone recording this?
23:16 <+RP> JPEW: I have logs
23:16 < JaMa> I have logs as well
23:16 < JPEW> Ok
23:16 <+RP> bluelightning: quick summary, we decided nodistro should default to hashequiv and repro builds
23:17 < bluelightning> RP: ok, sounds reasonable
23:17 <+RP> any of the other topics anyone wants to discuss?
23:17 < JaMa> RP: what about security_flags.inc? I thought it's already included by default, but seems it isn't
23:17 <+RP> JaMa: I'd love to include it too and reduce the delta
23:18 < JPEW> Are there specific reasons it isn't?
23:18 <+RP> poky and the autobuilder has long tested these things so the core should be ok. Other layers may run into issues, but, I think its probably time to sort this out
23:19 < bluelightning> took a while to get things to build well with it IIRC, that was a long time ago though
23:19 < JaMa> nodistro tests of meta-oe and other layers were IIRC also including this for a while, so shouldn't be terrible
23:19 <+RP> JPEW: Its easy for me to decide to push something into poky, changing nodistro traditionally causes much more friction
23:19 < JaMa> my world builds still include it as well
23:19 <+RP> JaMa: given that I think its a sign we should make it the default then
23:19 <+RP> JPEW: those flags can increase the binary size a bit iirc
23:22 < JaMa> just for record, the tags we agreed on last meeting for bitbake and openembedded-core repo were pushed today
23:22 <+RP> So, we also add security flags to nodistro?
23:22 <+RP> JaMa: thanks for sorting that out and sorry for the delay! :)
23:22 < JaMa> I vote yes for security flags
23:22 < JPEW> Yes, I think that makes sense
23:24 <+RP> I did just think of a thorny topic - SPDX license identifiers
23:24 <+RP> I keep trying to forget about this one :/
23:25 < JaMa> adding them to files or changing the values in LICENSE variables?
23:25 <+RP> Do we switch the LICENSE field to use the SPDX identifier?
23:26 <+RP> JaMa: As a general policy I think we're moving to add the license identifier field in code rather than the old license boilerplate which gets corrupted/outdated
23:26 < JaMa> I don't have strong opinion about this one, we're still dealing with a lot of packages which just say "LGPL" :(
23:26 <+RP> the LICENSE field one I'm torn on. I like our IDs and SPDX has changed at least once
23:26 < JPEW> I actually already though they were supposed to be SPDX
23:27 <+RP> JPEW: We have GPLv2, SPDX is GPL-2.0-only
23:27 <+RP> or GPL-2.0-or-later
23:28 <+RP> (instead of our GPLv2+)
23:28 < JaMa> RP: the maping between these will still be enabled, just the value in migrated recipes will prefer to be the "canonical" form?
23:28 < JPEW> RP: Ah, right. I recall that now.
23:28 <+RP> JaMa: no doubt we'd still have to have the mappings
23:28 <+RP> As I said, I'm torn on this one
23:29 <+RP> but SPDX is effectively the standard
23:29 < bluelightning> I'm not terribly keen FWIW
23:29 < JaMa> sounds like more work than gain, but I guess most of the recipes can be "migrated" with simple sed calls
23:29  * bluelightning -> out
23:29 < bluelightning> bye all
23:29 <+RP> bluelightning: safe travels!
23:29 < JaMa> bb bluelightning 
23:30 < JPEW> What is the advantage to using SPDX?
23:30 -!- bluelightning [~paul at pdpc/supporter/professional/bluelightning] has quit [Quit: Konversation terminated!!!111]
23:30 < JaMa> brb daughter is crying
23:30 <+RP> JPEW: ultimately the code license headers would match the license field and there would be only one value consistently
23:30 <+RP> shows support around the standard too
23:31 <+RP> JPEW: in general I'm  in favour of supporting SPDX if/where we can
23:32 <+RP> license handling is something we need to do better at and is a potential selling point of the project
23:32 <+RP> we don't need to make a decision on this one today but it is something to think about as OE could do with showing some leadership IMO around licensing
23:32 < JaMa> as long as it's not mandatory and doesn't need all recipes to be changed at the same time I'm not against it
23:33 < JPEW> Is is even possible to make it some sort of rolling change?
23:33 <+RP> JPEW: yes, we mainly need to decide if we're aiming for that
23:34 <+RP> I do prefer our own identifiers and there is a small worry upstream might change again (but unlikely now GNU are on board)
23:34 <+RP> If anyone has other topics please chime in. I'm just asking questions I have kind of queued up! :)
23:34 < JPEW> Why do you like ours better?
23:34 < zeddii> fewer-dashes :D
23:34 <+RP> JPEW: GPLv2 looks neater
23:35 < JaMa> agreed, SPDX are rather long
23:35 <+RP> I know why GNU wanted the other version
23:38 < JaMa> FWIW: here is the list https://spdx.org/licenses/ we already use the identifiers from version 3.0 and older in quite a few places (e.g. GPL-2.0 instead of GPLv2)
23:40 <+RP> JaMa: Right, we probably should at least standardise to SPDX or our own format
23:41 < JaMa> on separate topic, is there still strong objection to use 4 spaces for shell task indentation in oe-core for consistency with python tasks? I'm still willing to migrate the recipes
23:42 < JPEW> The mix was always a little weird to me, but I don't know why it was done that way
23:42 <+RP> JaMa: Compromise and allow it but don't migrate everything but just new code?
23:43 < JPEW> Sounds reasonable to me. I think that's documented in the OE style guide?
23:44 < JaMa> RP: migarting it incrementally is fine and once there is significant portion on 4 spaces I would volunteer to migrate the rest
23:44 <+RP> JaMa: I really don't want to mess the history with bulk respacing patches :(
23:44 <+RP> JaMa: it will be a particular pain for stable maintainer
23:45 < JaMa> RP: especially at the end of release cycle it makes IMHO most sense (e.g. when backports from dunfell to zeus are much more rare) and backports from the next one to dunfell will apply cleanly)
23:45 <+RP> JaMa: This was why we originally decided not to change it but the other layers, etc.
23:45 < JaMa> RP: not to mess with git blame?
23:46 <+RP> JaMa: its one of my concerns, yes
23:46 < JPEW> Alright, I have Christmas program 3 of 4 to attend, so I'll have to leave now.
23:46 < JaMa> I'm still just being triggered by functions which mix tabs and spaces (and for people with tab size != 8 it completely messes the indentation) and this is still happening
23:47 <+RP> JaMa: well, there is one in sstate.bbclass I know I'm aware of
23:47 <+RP> JPEW: thanks!
23:47 <+RP> JaMa: sounds like we'd better table this one for another day :/
23:49 < JaMa> meta/recipes-support/libpcre/libpcre_8.43.bb has tabs followed by spaces as well
23:49 < JaMa> db, curl, ..
23:50 < JaMa> if my grep was correct, then tab followed by spaces is in these: meta/recipes-bsp/formfactor/formfactor_0.0.bb meta/recipes-bsp/grub/grub-efi_2.04.bb meta/recipes-bsp/keymaps/keymaps_1.0.bb meta/recipes-bsp/libacpi/libacpi_0.2.bb meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb meta/recipes-bsp/pciutils/pciutils_3.6.2.bb meta/recipes-connectivity/bind/bind_9.11.13.bb meta/recipes-connectivity/neard/neard_0.16.bb 
23:50 < JaMa> meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.1.bb meta/recipes-connectivity/openssl/openssl_1.1.1d.bb meta/recipes-connectivity/ppp/ppp_2.4.7.bb meta/recipes-connectivity/resolvconf/resolvconf_1.79.bb meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.9.bb meta/recipes-core/dbus/dbus_1.12.16.bb meta/recipes-core/dbus/dbus-test_1.12.16.bb meta/recipes-core/expat/expat_2.2.9.bb 
23:50 < JaMa> meta/recipes-core/gettext/gettext_0.19.8.1.bb meta/recipes-core/ifupdown/ifupdown_0.8.22.bb meta/recipes-core/images/build-appliance-image_15.0.0.bb meta/recipes-core/initscripts/initscripts_1.0.bb meta/recipes-core/libxml/libxml2_2.9.9.bb meta/recipes-core/sysvinit/sysvinit_2.96.bb meta/recipes-devtools/autoconf/autoconf_2.69.bb meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb 
23:50 < JaMa> meta/recipes-devtools/flex/flex_2.6.4.bb meta/recipes-devtools/gnu-config/gnu-config_git.bb meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb meta/recipes-devtools/libtool/libtool-cross_2.4.6.bb meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb meta/recipes-devtools/rpm/rpm_4.14.2.1.bb meta/recipes-devtools/tcltk/tcl_8.6.9.bb meta/recipes-devtools/valgrind/valgrind_3.15.0.bb 
23:50 < JaMa> meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb meta/recipes-extended/chkconfig/chkconfig-alternatives-native_1.3.59.bb meta/recipes-extended/cronie/cronie_1.5.5.bb meta/recipes-extended/diffutils/diffutils_3.7.bb meta/recipes-extended/gawk/gawk_5.0.1.bb meta/recipes-extended/less/less_551.bb meta/recipes-extended/man-db/man-db_2.8.7.bb meta/recipes-extended/mdadm/mdadm_4.1.bb 
23:50 < JaMa> meta/recipes-extended/parted/parted_3.2.bb meta/recipes-extended/sed/sed_4.7.bb meta/recipes-extended/slang/slang_2.3.2.bb meta/recipes-extended/tcp-wrappers/tcp-wrappers_7.6.bb meta/recipes-extended/xinetd/xinetd_2.3.15.bb meta/recipes-extended/zip/zip_3.0.bb meta/recipes-gnome/epiphany/epiphany_3.34.1.bb meta/recipes-gnome/librsvg/librsvg_2.40.20.bb meta/recipes-graphics/mx/mx-1.0_1.4.7.bb 
23:50 < JaMa> meta/recipes-graphics/wayland/wayland_1.17.0.bb meta/recipes-graphics/xorg-lib/pixman_0.38.4.bb meta/recipes-kernel/dtc/dtc_1.5.1.bb meta/recipes-kernel/linux/kernel-devsrc.bb meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb meta/recipes-kernel/modutils-initscripts/modutils-initscripts.bb meta/recipes-kernel/perf/perf.bb meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb 
23:50 < JaMa> meta/recipes-rt/rt-tests/hwlatdetect_1.1.bb meta/recipes-sato/matchbox-keyboard/matchbox-keyboard_0.1.1.bb meta/recipes-sato/pcmanfm/pcmanfm_1.3.1.bb meta/recipes-sato/puzzles/puzzles_git.bb meta/recipes-sato/webkit/webkitgtk_2.26.2.bb meta/recipes-support/apr/apr_1.7.0.bb meta/recipes-support/apr/apr-util_1.6.1.bb meta/recipes-support/attr/acl_2.2.52.bb meta/recipes-support/curl/curl_7.67.0.bb 
23:50 < JaMa> meta/recipes-support/db/db_5.3.28.bb meta/recipes-support/libgpg-error/libgpg-error_1.36.bb meta/recipes-support/libpcre/libpcre_8.43.bb meta/recipes-support/lzo/lzo_2.10.bb meta/recipes-support/shared-mime-info/shared-mime-info_1.10.bb meta-skeleton/recipes-skeleton/service/service_0.1.bb
23:51 < JaMa> meta/classes/autotools.bbclass meta/classes/binconfig.bbclass meta/classes/buildhistory.bbclass meta/classes/cmake.bbclass meta/classes/cross-canadian.bbclass meta/classes/distutils.bbclass meta/classes/image-live.bbclass meta/classes/kernel.bbclass meta/classes/kernel-grub.bbclass meta/classes/kernel-yocto.bbclass meta/classes/module.bbclass meta/classes/multilib_header.bbclass 
23:51 < JaMa> meta/classes/rootfs-postcommands.bbclass meta/classes/staging.bbclass meta/classes/toolchain-scripts.bbclass meta/classes/useradd.bbclass meta/classes/utils.bbclass
23:52 < JaMa> meta/conf/distro/include/tclibc-glibc.inc meta/recipes-core/glibc/glibc-package.inc meta/recipes-core/ncurses/ncurses.inc meta/recipes-devtools/apt/apt-package.inc meta/recipes-devtools/autoconf/autoconf.inc meta/recipes-devtools/gcc/gcc-9.2.inc meta/recipes-devtools/gdb/gdb-8.3.1.inc meta/recipes-devtools/git/git.inc meta/recipes-devtools/m4/m4-1.4.18.inc meta/recipes-devtools/perl/perl-ptest.inc 
23:52 < JaMa> meta/recipes-devtools/pseudo/pseudo.inc meta/recipes-devtools/qemu/qemu.inc meta/recipes-extended/bash/bash.inc meta/recipes-extended/cups/cups.inc meta/recipes-extended/shadow/shadow.inc meta/recipes-extended/sudo/sudo.inc meta/recipes-extended/sysstat/sysstat.inc meta/recipes-graphics/clutter/clutter-1.0.inc meta/recipes-graphics/cogl/cogl-1.0.inc meta/recipes-graphics/mesa/mesa.inc 
23:52 < JaMa> meta/recipes-graphics/mx/mx.inc meta/recipes-sato/rxvt-unicode/rxvt-unicode.inc meta/recipes-support/attr/attr.inc meta/recipes-support/icu/icu.inc meta/recipes-support/libcap-ng/libcap-ng.inc
23:52 < JaMa> sorry :/ so it's not so rare..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20191217/9f38a772/attachment-0001.sig>