Re: [OE-core] Fwd: [oe-commits] [openembedded-core] branch thud updated (ad0a553 -> 748f946)
On 3/17/19 9:25 AM, Adrian Bunk wrote: > On Sun, Mar 17, 2019 at 08:38:20AM -0700, akuster808 wrote: >> >> On 3/17/19 6:08 AM, Adrian Bunk wrote: >>> On Sat, Mar 16, 2019 at 08:50:13AM -0700, akuster808 wrote: On 3/16/19 5:20 AM, Andreas Müller wrote: ... > 2. This was applied on Feb 6th which is not 3 month back exactly. then its worst than I thought, I can't remember what my thought process was back to Feb 6th. > [1] > https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Point_release I am glad you are bringing these things up, it helps me revisit my own processes and help me improve. We are planning on revising the maintenance guidelines soon so I hope to get your input. >>> Was the boost upgrade in thud sent to the mailing list for review? >> That series did not, the previous ones and several Sumo request have. >> >> So you are the second person to mention the update, is it causing a >> problem? > You were requesting input. > > I am not using boost on Yocto, but in Debian it is pretty normal > that several packages stop building each time boost gets updated. > > "Drop signals library as upstream has removed it" in the backported > commit shows the tip of this iceberg. > > What went wrong that even the removal of a library from boost > did not prevent this change from entering a stable branch? Like I said before, I don't recall the thought process when that series was put together. > >>> My reading of the "Requesting a fix in a stable branch" section >>> would be that this is already a mandatory part of the process. >> That is not under the "Maintainers procedure" so it does not apply. >> >> I have taken requests via IRC and a simple "please add this to stable >> branch X" emails so I have not been enforcing the letter of the law. >> ... >> Like I have mentioned already, the processes mentioned in >> "Stable_branch_maintenance" are under review. > One problem is that changes to master are getting better reviewed than > changes to stable branches. > > Upgrading boost in a stable branch wouldn't have survived a mailing > list review. I would hope so. > > A possible improvement would be to always use thud-next, and each time > commits are added to thud-next an email thread with all new commits gets > sent to the mailing list (similar to the review threads for new upstream > stable kernels, see [1] for an example). That is what I do for meta-openembedded and then I send a pull request. - Armin > >> regards, >> Armin > cu > Adrian > > [1] https://lkml.org/lkml/2019/3/12/1290 > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: [oe-commits] [openembedded-core] branch thud updated (ad0a553 -> 748f946)
On Sun, Mar 17, 2019 at 08:38:20AM -0700, akuster808 wrote: > > > On 3/17/19 6:08 AM, Adrian Bunk wrote: > > On Sat, Mar 16, 2019 at 08:50:13AM -0700, akuster808 wrote: > >> On 3/16/19 5:20 AM, Andreas Müller wrote: > >> ... > >>> 2. This was applied on Feb 6th which is not 3 month back exactly. > >> then its worst than I thought, I can't remember what my thought process > >> was back to Feb 6th. > >>> [1] > >>> https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Point_release > >> I am glad you are bringing these things up, it helps me revisit my own > >> processes and help me improve. > >> > >> We are planning on revising the maintenance guidelines soon so I hope to > >> get your input. > > Was the boost upgrade in thud sent to the mailing list for review? > That series did not, the previous ones and several Sumo request have. > > So you are the second person to mention the update, is it causing a > problem? You were requesting input. I am not using boost on Yocto, but in Debian it is pretty normal that several packages stop building each time boost gets updated. "Drop signals library as upstream has removed it" in the backported commit shows the tip of this iceberg. What went wrong that even the removal of a library from boost did not prevent this change from entering a stable branch? > > My reading of the "Requesting a fix in a stable branch" section > > would be that this is already a mandatory part of the process. > > That is not under the "Maintainers procedure" so it does not apply. > > I have taken requests via IRC and a simple "please add this to stable > branch X" emails so I have not been enforcing the letter of the law. >... > Like I have mentioned already, the processes mentioned in > "Stable_branch_maintenance" are under review. One problem is that changes to master are getting better reviewed than changes to stable branches. Upgrading boost in a stable branch wouldn't have survived a mailing list review. A possible improvement would be to always use thud-next, and each time commits are added to thud-next an email thread with all new commits gets sent to the mailing list (similar to the review threads for new upstream stable kernels, see [1] for an example). > regards, > Armin cu Adrian [1] https://lkml.org/lkml/2019/3/12/1290 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: [oe-commits] [openembedded-core] branch thud updated (ad0a553 -> 748f946)
On 3/17/19 6:08 AM, Adrian Bunk wrote: > On Sat, Mar 16, 2019 at 08:50:13AM -0700, akuster808 wrote: >> On 3/16/19 5:20 AM, Andreas Müller wrote: >> ... >>> 2. This was applied on Feb 6th which is not 3 month back exactly. >> then its worst than I thought, I can't remember what my thought process >> was back to Feb 6th. >>> [1] >>> https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Point_release >> I am glad you are bringing these things up, it helps me revisit my own >> processes and help me improve. >> >> We are planning on revising the maintenance guidelines soon so I hope to >> get your input. > Was the boost upgrade in thud sent to the mailing list for review? That series did not, the previous ones and several Sumo request have. So you are the second person to mention the update, is it causing a problem? > > My reading of the "Requesting a fix in a stable branch" section > would be that this is already a mandatory part of the process. That is not under the "Maintainers procedure" so it does not apply. I have taken requests via IRC and a simple "please add this to stable branch X" emails so I have not been enforcing the letter of the law. Now what does apply to me is under "Maintainer Procedure". I have never done steps 6,7 and 8. RP has scripts the does the splitting into the separate repos. Doing those steps adds more overhead to the maintenance process as the AB builds require "Poky". Like I have mentioned already, the processes mentioned in "Stable_branch_maintenance" are under review. regards, Armin > >> - armin > cu > Adrian > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: [oe-commits] [openembedded-core] branch thud updated (ad0a553 -> 748f946)
On Sat, Mar 16, 2019 at 08:50:13AM -0700, akuster808 wrote: > On 3/16/19 5:20 AM, Andreas Müller wrote: >... > > 2. This was applied on Feb 6th which is not 3 month back exactly. > then its worst than I thought, I can't remember what my thought process > was back to Feb 6th. > > > > [1] > > https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Point_release > > I am glad you are bringing these things up, it helps me revisit my own > processes and help me improve. > > We are planning on revising the maintenance guidelines soon so I hope to > get your input. Was the boost upgrade in thud sent to the mailing list for review? My reading of the "Requesting a fix in a stable branch" section would be that this is already a mandatory part of the process. > - armin cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: [oe-commits] [openembedded-core] branch thud updated (ad0a553 -> 748f946)
On 3/16/19 5:20 AM, Andreas Müller wrote: > On Sat, Mar 16, 2019 at 12:11 PM akuster808 wrote: >> On 3/15/19 10:24 AM, Andreas Müller wrote: >>> Replied to wrong mailing >>> >>> On Wed, Feb 6, 2019 at 5:38 PM wrote: This is an automated email from the git hooks/post-receive script. rpurdie pushed a change to branch thud in repository openembedded-core. from ad0a553 build-appliance-image: Update to thud head revision add 0bbe3d5 kernel: use olddefconfig as the primary target for KERNEL_CONFIG_COMMAND add 933712e linux-yocto/4.18: update to v4.18.22 add 193eb75 icecc: readlink -f on the recipe-sysroot gcc/g++ add 57673fe icecc: Trivial simplification add d4ec470 icecc: Syntax error meant that we weren't waiting for tarball generation add 46db052 icecc: Don't generate recipe-sysroot symlinks at recipe-parsing time add 9d3587d icecc: patchelf is needed by icecc-create-env add d8bf7e5 eudev: upgrade 3.2.5 -> 3.2.7 add a316146 gsettings-desktop-schemas: upgrade 3.28.0 -> 3.28.1 add 88581ac libatomic-ops: upgrade 7.6.6 -> 7.6.8 add 7c6e9f5 libpng: upgrade 1.6.35 -> 1.6.36 add be1429b common-licenses: update Libpng license text add 93c76fe i2c-tools: upgrade 4.0 -> 4.1 add b09f261 oeqa/utils/qemurunner: Print output when failed to login add 47731b4 grub2: Fix passing null to printf formats add e3ef28a gnupg: Upgrade to 2.2.12 release add a44c7ba tzdata/tzcode-native: update to 2018i add 4a7945c lighttpd: update to 1.4.51 add 4f14eac boost: update to 1.69.0 >>> In my infinite naivety I just updated thud. >>> >>> * Many updates here - wasn't there some policy just to update in case >>> of 'emergency'? >> Nope the process does not say that. I will update recipes when they >> bugfix updates. I have been doing that for years. In fact, you should >> be seeing something on the arch list to make the process standard. >>> * How can you update boost on a stable branch - a first class citizen >>> for build trouble? >> Don't recall the thought process on a given backport especial when its 3 >> months back. Can't tell why I decided to update boost. >> >> - armin >> >>> Wonder which further fallout I'll get... >>> >>> Andreas > Just for the record: > > 1. In [1] I read at policies: > > * No recipe upgrades unless: > * The old version is completely broken > * The new version contains a security patch or other critical bugfix > that is too difficult to backport to the version already in the stable > branch For completeness: As always, the stable branch maintainers' judgement is important when it comes to deciding which fixes are or are not appropriate. If there is doubt, feel free to consult with the overall project maintainer (Richard Purdie ). > 2. This was applied on Feb 6th which is not 3 month back exactly. then its worst than I thought, I can't remember what my thought process was back to Feb 6th. > > [1] https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Point_release I am glad you are bringing these things up, it helps me revisit my own processes and help me improve. We are planning on revising the maintenance guidelines soon so I hope to get your input. - armin > > Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: [oe-commits] [openembedded-core] branch thud updated (ad0a553 -> 748f946)
On Sat, Mar 16, 2019 at 12:11 PM akuster808 wrote: > On 3/15/19 10:24 AM, Andreas Müller wrote: > > Replied to wrong mailing > > > > On Wed, Feb 6, 2019 at 5:38 PM wrote: > >> This is an automated email from the git hooks/post-receive script. > >> > >> rpurdie pushed a change to branch thud > >> in repository openembedded-core. > >> > >> from ad0a553 build-appliance-image: Update to thud head revision > >> add 0bbe3d5 kernel: use olddefconfig as the primary target for > >> KERNEL_CONFIG_COMMAND > >> add 933712e linux-yocto/4.18: update to v4.18.22 > >> add 193eb75 icecc: readlink -f on the recipe-sysroot gcc/g++ > >> add 57673fe icecc: Trivial simplification > >> add d4ec470 icecc: Syntax error meant that we weren't waiting for > >> tarball generation > >> add 46db052 icecc: Don't generate recipe-sysroot symlinks at > >> recipe-parsing time > >> add 9d3587d icecc: patchelf is needed by icecc-create-env > >> add d8bf7e5 eudev: upgrade 3.2.5 -> 3.2.7 > >> add a316146 gsettings-desktop-schemas: upgrade 3.28.0 -> 3.28.1 > >> add 88581ac libatomic-ops: upgrade 7.6.6 -> 7.6.8 > >> add 7c6e9f5 libpng: upgrade 1.6.35 -> 1.6.36 > >> add be1429b common-licenses: update Libpng license text > >> add 93c76fe i2c-tools: upgrade 4.0 -> 4.1 > >> add b09f261 oeqa/utils/qemurunner: Print output when failed to login > >> add 47731b4 grub2: Fix passing null to printf formats > >> add e3ef28a gnupg: Upgrade to 2.2.12 release > >> add a44c7ba tzdata/tzcode-native: update to 2018i > >> add 4a7945c lighttpd: update to 1.4.51 > >> add 4f14eac boost: update to 1.69.0 > > In my infinite naivety I just updated thud. > > > > * Many updates here - wasn't there some policy just to update in case > > of 'emergency'? > Nope the process does not say that. I will update recipes when they > bugfix updates. I have been doing that for years. In fact, you should > be seeing something on the arch list to make the process standard. > > * How can you update boost on a stable branch - a first class citizen > > for build trouble? > Don't recall the thought process on a given backport especial when its 3 > months back. Can't tell why I decided to update boost. > > - armin > > > Wonder which further fallout I'll get... > > > > Andreas Just for the record: 1. In [1] I read at policies: * No recipe upgrades unless: * The old version is completely broken * The new version contains a security patch or other critical bugfix that is too difficult to backport to the version already in the stable branch 2. This was applied on Feb 6th which is not 3 month back exactly. [1] https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Point_release Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: [oe-commits] [openembedded-core] branch thud updated (ad0a553 -> 748f946)
On 3/15/19 10:24 AM, Andreas Müller wrote: > Replied to wrong mailing > > On Wed, Feb 6, 2019 at 5:38 PM wrote: >> This is an automated email from the git hooks/post-receive script. >> >> rpurdie pushed a change to branch thud >> in repository openembedded-core. >> >> from ad0a553 build-appliance-image: Update to thud head revision >> add 0bbe3d5 kernel: use olddefconfig as the primary target for >> KERNEL_CONFIG_COMMAND >> add 933712e linux-yocto/4.18: update to v4.18.22 >> add 193eb75 icecc: readlink -f on the recipe-sysroot gcc/g++ >> add 57673fe icecc: Trivial simplification >> add d4ec470 icecc: Syntax error meant that we weren't waiting for >> tarball generation >> add 46db052 icecc: Don't generate recipe-sysroot symlinks at >> recipe-parsing time >> add 9d3587d icecc: patchelf is needed by icecc-create-env >> add d8bf7e5 eudev: upgrade 3.2.5 -> 3.2.7 >> add a316146 gsettings-desktop-schemas: upgrade 3.28.0 -> 3.28.1 >> add 88581ac libatomic-ops: upgrade 7.6.6 -> 7.6.8 >> add 7c6e9f5 libpng: upgrade 1.6.35 -> 1.6.36 >> add be1429b common-licenses: update Libpng license text >> add 93c76fe i2c-tools: upgrade 4.0 -> 4.1 >> add b09f261 oeqa/utils/qemurunner: Print output when failed to login >> add 47731b4 grub2: Fix passing null to printf formats >> add e3ef28a gnupg: Upgrade to 2.2.12 release >> add a44c7ba tzdata/tzcode-native: update to 2018i >> add 4a7945c lighttpd: update to 1.4.51 >> add 4f14eac boost: update to 1.69.0 > In my infinite naivety I just updated thud. > > * Many updates here - wasn't there some policy just to update in case > of 'emergency'? Nope the process does not say that. I will update recipes when they bugfix updates. I have been doing that for years. In fact, you should be seeing something on the arch list to make the process standard. > * How can you update boost on a stable branch - a first class citizen > for build trouble? Don't recall the thought process on a given backport especial when its 3 months back. Can't tell why I decided to update boost. - armin > Wonder which further fallout I'll get... > > Andreas >> add 70e942e oeqa/utils/qemurunner: set timeout to 60s for run_serial >> add 1f3577f libsndfile1: Security fix CVE-2017-17456/17457 >> CVE-2018-19661/19662 >> add 86a4eca binutils: Fix build with clang >> add 2c12e1d oeqa: Fix for QEMU_USE_KVM >> add 30b68e8 nativesdk-*-provides-dummy: Fixes to allow correct >> operation with opkg >> add f57d83c sstate: add support for caching shared workdir tasks >> add 284252d package.bbclass: fix python unclosed file ResourceWarning >> add f51e59b scripts/oe-git-archive: fix non-existent key referencing >> error >> add 2bb4774 toolchain-scripts: run post-relocate scripts for every >> environment >> add 9841962 patch: reproducibility: Fix host umask leakage >> add 694d62e kernel: don't assign the build user/host >> add 778f33d classes: Correctly markup regex strings >> add bfd7257 testimage: Remove duplicate dependencies >> add 16c9002 testimage: Simplfy DEFAULT_TEST_SUITES logic >> add 7dce356 testimage: Further cleanup DEFAULT_TEST_SUITES >> add 1da4c2e testimage: Enable autorunning of the package manager >> testsuites >> add ab49891 testimage: Add support for slirp >> add 0469c75 testimage: Add possibility to pass parmeters to qemu >> add 51423c3 testimage.bbclass: remove boot parameter systemd.log_target >> add 5fedb01 meta/classes/testimage.bbclass: Only validate >> IMAGE_FSTYPES when is QEMU >> add 310a2b1 oeqa: make it work for multiple users >> add d082852 classes/testsdk: Split implementation into classes >> add 4b5a4b7 runqemu: clean up subprocess usage >> add 79471a2 runqemu-gen-tapdevs: Allow run --help without sudo >> add a916a92 wic: sdimage-bootpart: Use mmcblk0 drive instead of bogus >> mmcblk >> add 27b9008 binutils: Upgrade to latest on 2.31 release branch >> add f829801 binutils: bfd doesn't handle ELF compressed data alignment >> add 601f870 oeqa/runtime/cases: Improve test dependency information >> add e65d168 oeqa/runtime/cases: Improve dependencies of >> kernel/gcc/build tests >> add c3d51e9 oeqa/qemu & runtime: qemu do not need ip input from >> external >> add 63f0ce0 oeqa/manual/bsp-qemu.json: Update for QEMU_USE_KVM >> add ffea871 oeqa/selftest/runqemu: Enable kvm when QEMU_USE_KVM is set >> add 34efb67 oeqa/utils/buildproject: Only clean files if we've done >> something >> add e35ced7 kernel.bbclass: Fix incorrect deploying of >> fitimage.initramfs >> add 7800f42 linux-yocto/4.18: update to v4.18.25 >> add aee9c2c systemd-systemctl-native: handle Install wildcards >> add f2c5e46 systemd: backport fix to stop enabling ECN >> add 9a78a88
