Re: [yocto] Dropping Debian 7 as supported?
> Am 14.02.2016 um 11:24 schrieb Richard Purdie > : > > On Sat, 2016-02-13 at 10:12 -0800, Khem Raj wrote: >> On Sat, Feb 13, 2016 at 9:28 AM, Richard Purdie >> wrote: >>> On Sat, 2016-02-13 at 15:30 +0100, Jens Rehsack wrote: > Am 11.02.2016 um 15:32 schrieb Burton, Ross < > ross.bur...@intel.com> > : > > > On 11 February 2016 at 14:21, Nick Leverton > wrote: > Possibly a little early - Debian 7 will be going onto LTS > security > support for > two years, starting some time this month. Quoting from > https://wiki.debian.org/LTS > > Ah yes, I'd forgotten about the LTS project and was looking at > the > security team. > > This does make it less clear, but it's still an old release and > we > can't support/test on everything. Sure, but are there some serious/expensive maintaining efforts continuing support Debian 7? Or is it an approach to kick Debian from list of supported distributions for (above?) reasons? Since I run some build instances on a Debian 7 machine which is not going to be upgraded that soon (don't want Debian 8, but don't want to reinstall from scratch and migrate my Xen VM's ...), dropping support for "it's just time to move on" is more a Desktop philosophy, not for embedded/datacenter approaches ... >>> >>> For example, we'd like to use the sparse option when building >>> rootfs: >>> >>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9099 >>> >>> This support isn't available in the version of dd in debian 7. Our >>> options are: >>> >>> * Build a dd -native That's something complete different than "End of regular support, switching to LTS" - so based on missing features, any distribution which doesn't fulfill the required features should be discarded from list of supported distributions unless the required features are Yocto patches in upstream. In such a case the drop smells like misusing power (then a smoother way should be found), >> For core feature like sparse files its better to control our own >> destiny and use dd-native regardless. > > There are certain core utilities which its very hard to add into the > dependency chains correctly. With xz, I recently gave up trying to get > the patches right. I'm sure it could be done, it didn't seem worth the > effort though. dd and other coreutils fall into the same category, very > hard to get right without races. There is probably a redesign of the > some of the way staging happens needed to make it work and that is a > low priority right now. Having an implicit xy.bbclass adding dependency to yocto-coreutils-native isn't a way? As said several times, my pkgsrc background leads me to Yocto for embedded Linux development - and this background educated add nb* utilities for each host utility which is incompatible to the infrastructure. >> But that does not mean we should >> not drop debian7 or arcane centos distros that we keep supporting for >> ever. I still see patches for centos 5.8 in metadata. > > We did retire centos 6 recently (qemu wouldn't run there correctly for > any of the automated tests). Which is again a good reason for retiring support for a dedicated distribution. I'm a bit torn regarding the lifecycle of RHEL/Cent OS, which is 10 years after release - dropping support for enterprise grade distribution to quick leaves a taste/smell ... (don't know how to express). Don't get me wrong - it is absolutely reasonable to retire distributions lacking important features which can't be added with reasonable effort into build chain. Deciding which important feature requires such a retirement should be proved with an eye of lifecycle of server distributions. Cheers -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Recipe reporting system] Upgradable recipe name list
This mail was sent out by Recipe reporting system. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade at this time, they can fill RECIPE_NO_UPDATE_REASON in respective recipe file to ignore this remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON = "Version 2.0 is unstable" You can check the detail information at: http://recipes.yoctoproject.org/ Package Version Upstream version Maintainer NoUpgradeReason --- --- -- texinfo 6.0 6.1 Alejandro Hernandez python-git1.0.11.0.2 Alejandro Hernandez python3-pip 8.0.08.0.2 Alejandro Hernandez python3-setuptools19.4 20.1.1Alejandro Hernandez ruby 2.2.22.3.0 Alejandro Hernandez python-pygobject 2.28.3 3.19.2Alejandro Hernandez Newer versions of python-py... python-setuptools 19.4 20.1.1Alejandro Hernandez liberation-fonts 1.04 2.00.1Alexander Kanavin 2.x depends on fontforge pa... mkelfimage4.0+gitX 4.3+gitAUTOINC+1b... Alexander Kanavin mkelfimage has been removed... apt 1.0.10.1 1.2.3 Aníbal Limón dpkg 1.18.2 1.18.4Aníbal Limón pinentry 0.9.20.9.7 Armin Kuster nettle3.1.13.2 Armin Kuster guilt-native 0.35+gitX0.36+gitAUTOINC+2... Bruce Ashfield linux-libc-headers4.4 4.4.1 Bruce Ashfield systemd 228+gitX 229+gitAUTOINC+95... Chen Qi grep 2.22 2.23 Chen Qi diffstat 1.60 1.61 Chen Qi coreutils 8.24 8.25 Chen Qi dbus-glib 0.1040.106 Chen Qi cups 2.0.42.1.3 Chen Qi findutils 4.5.14 4.5.19Chen Qi pax-utils 1.1.41.1.5 Hongxu Jia ncurses 6.0 6.0+20160213 Hongxu Jia createrepo0.4.11 0.10.4Hongxu Jia Versions after 0.9.* use YU... gnupg 2.1.10 2.1.11Hongxu Jia libgcrypt 1.6.41.6.5 Hongxu Jia ghostscript 9.16 9.18 Hongxu Jia elfutils 0.1640.165 Hongxu Jia wayland 1.9.01.9.93Jussi Kukkonen weston1.9.01.9.93Jussi Kukkonen clutter-gst-3.0 3.0.14 3.0.16Jussi Kukkonen gtk-icon-utils-na... 3.18.6 3.18.7Jussi Kukkonen libinput 1.1.41.1.901 Jussi Kukkonen cmake 3.4.23.4.3 Jussi Kukkonen docbook-xsl-style... 1.78.1 1.79.1Jussi Kukkonen vala 0.30.0 0.30.1Jussi Kukkonen gtk+3 3.18.6 3.18.7Jussi Kukkonen pixman0.32.8 0.34.0Jussi Kukkonen xserver-xorg 1.18.0 1.18.1Jussi Kukkonen xkeyboard-config 2.16 2.17 Jussi Kukkonen glew 1.12.0 1.13.0Jussi Kukkonen vte 0.28.2 0.42.4Jussi Kukkonen matchbox-terminal needs to ... linuxdoc-tools-na... 0.9.69 0.9.71Jussi Kukkonen slang 2.2.42.3.0 Kai Kang libsdl2 2.0.32.0.4 Kai Kang rpm 5.4.14 5.4.15Mark Hatle 5.4.15 has a package databa... prelink 1.0+gitX 20151030.+gitAUTO... Mark Hatle libpfm4 4.6.04.7.0 Matthew McClintock db6.0.30 6.1.26Maxin B. John Updating to 6.1.x requires ... ffmpeg2.8.63.0 No maintainer apt-native1.0.10.1 1.2.3 No maintainer cmake-native 3.4.23.4.3 No maintainer ifupdown 0.8.20.8.10No maintainer libsolv 0.6.17+gitX 0.6.18+gitAUTOINC... No maintainer debianutils 4.5.14.7 No maintainer sgmlspl-native1.1+gitX 1.03+gitAUTOINC+f... No maintainer adt-installer 0.3.00.3.1
[yocto] ERROR: Error executing a python function in exec_python_func() autogenerated
Hello:
Has anyone seen this error?
ERROR: Error executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function:
0001:
*** 0002:do_package(d)
0003:
File: '~/work/angstrom/sources/openembedded-core/meta/classes/package.bbclass',
lineno: 1982, function: do_package
1978:workdir = d.getVar('WORKDIR', True)
1979:outdir = d.getVar('DEPLOY_DIR', True)
1980:dest = d.getVar('D', True)
1981:dvar = d.getVar('PKGD', True)
*** 1982:pn = d.getVar('PN', True)
1983:
1984:if not workdir or not outdir or not dest or not dvar or not pn:
1985:msg = "WORKDIR, DEPLOY_DIR, D, PN and PKGD all must be
defined, unable to package"
1986:package_qa_handle_error("var-undefined", msg, d)
File: '~/work/angstrom/sources/openembedded-core/meta/classes/package.bbclass',
lineno: 1965, function: set_alternative_vars
1961:# way that the output of this class changes. rpmdeps is a good
example
1962:# as any change to rpmdeps requires this to be rerun.
1963:# PACKAGE_BBCLASS_VERSION = "1"
1964:
*** 1965:# Init cachedpath
1966:global cpath
1967:cpath = oe.cachedpath.CachedPath()
1968:
1969:
###
Exception: IOError: [Errno 2] No such file or directory:
'~/work/angstrom/build/tmp-angstrom_v2015_12-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/busybox/1.23.2-r0/image${sysconfdir}/busybox.links.nosuid'
ERROR: Function failed: do_package
ERROR: Logfile of failure stored in:
~/work/angstrom/build/tmp-angstrom_v2015_12-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/busybox/1.23.2-r0/temp/log.do_package.175963
ERROR: Task 203
(~/work/angstrom/sources/openembedded-core/meta/recipes-core/busybox/busybox_1.23.2.bb,
do_package) failed with exit code '1'
I'm running the Angstrom distribution. It is the jethro branch latest.
Does anyone know what might be causing this error?
Thanks for help,
-Ilya.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH] ref-manual: typo fix (s/If if/If/)
Signed-off-by: Mario Domenech Goulart
---
documentation/ref-manual/ref-variables.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/documentation/ref-manual/ref-variables.xml
b/documentation/ref-manual/ref-variables.xml
index f752856..8184c3a 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -8696,7 +8696,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
-If if you use the PACKAGE_GROUP
+If you use the PACKAGE_GROUP
variable, the OpenEmbedded build system issues a warning
message.
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dropping Debian 7 as supported?
On Sun, Feb 14, 2016 at 2:24 AM, Richard Purdie wrote: > On Sat, 2016-02-13 at 10:12 -0800, Khem Raj wrote: >> On Sat, Feb 13, 2016 at 9:28 AM, Richard Purdie >> wrote: >> > On Sat, 2016-02-13 at 15:30 +0100, Jens Rehsack wrote: >> > > > Am 11.02.2016 um 15:32 schrieb Burton, Ross < >> > > > ross.bur...@intel.com> >> > > > : >> > > > >> > > > >> > > > On 11 February 2016 at 14:21, Nick Leverton >> > > > wrote: >> > > > Possibly a little early - Debian 7 will be going onto LTS >> > > > security >> > > > support for >> > > > two years, starting some time this month. Quoting from >> > > > https://wiki.debian.org/LTS >> > > > >> > > > Ah yes, I'd forgotten about the LTS project and was looking at >> > > > the >> > > > security team. >> > > > >> > > > This does make it less clear, but it's still an old release and >> > > > we >> > > > can't support/test on everything. >> > > >> > > Sure, but are there some serious/expensive maintaining efforts >> > > continuing support Debian 7? >> > > Or is it an approach to kick Debian from list of supported >> > > distributions for (above?) reasons? >> > > >> > > Since I run some build instances on a Debian 7 machine which is >> > > not >> > > going to be upgraded that >> > > soon (don't want Debian 8, but don't want to reinstall from >> > > scratch >> > > and migrate my Xen VM's ...), >> > > dropping support for "it's just time to move on" is more a >> > > Desktop >> > > philosophy, not for embedded/datacenter >> > > approaches ... >> > >> > For example, we'd like to use the sparse option when building >> > rootfs: >> > >> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=9099 >> > >> > This support isn't available in the version of dd in debian 7. Our >> > options are: >> > >> > * Build a dd -native >> >> For core feature like sparse files its better to control our own >> destiny and use dd-native regardless. > > There are certain core utilities which its very hard to add into the > dependency chains correctly. With xz, I recently gave up trying to get > the patches right. I'm sure it could be done, it didn't seem worth the > effort though. dd and other coreutils fall into the same category, very > hard to get right without races. There is probably a redesign of the > some of the way staging happens needed to make it work and that is a > low priority right now. > >> But that does not mean we should >> not drop debian7 or arcane centos distros that we keep supporting for >> ever. I still see patches for centos 5.8 in metadata. > > We did retire centos 6 recently (qemu wouldn't run there correctly for > any of the automated tests). ver good. we can remove fix_for_centos_5.8.patch from glibc meta/recipes-devtools/apt/apt/0001-fix-the-gcc-version-check.patch meta/recipes-devtools/apt/apt/0001-remove-Wsuggest-attribute-from-CFLAGS.patch > > Cheers, > > Richard > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dropping Debian 7 as supported?
On Sat, 2016-02-13 at 10:12 -0800, Khem Raj wrote: > On Sat, Feb 13, 2016 at 9:28 AM, Richard Purdie > wrote: > > On Sat, 2016-02-13 at 15:30 +0100, Jens Rehsack wrote: > > > > Am 11.02.2016 um 15:32 schrieb Burton, Ross < > > > > ross.bur...@intel.com> > > > > : > > > > > > > > > > > > On 11 February 2016 at 14:21, Nick Leverton > > > > wrote: > > > > Possibly a little early - Debian 7 will be going onto LTS > > > > security > > > > support for > > > > two years, starting some time this month. Quoting from > > > > https://wiki.debian.org/LTS > > > > > > > > Ah yes, I'd forgotten about the LTS project and was looking at > > > > the > > > > security team. > > > > > > > > This does make it less clear, but it's still an old release and > > > > we > > > > can't support/test on everything. > > > > > > Sure, but are there some serious/expensive maintaining efforts > > > continuing support Debian 7? > > > Or is it an approach to kick Debian from list of supported > > > distributions for (above?) reasons? > > > > > > Since I run some build instances on a Debian 7 machine which is > > > not > > > going to be upgraded that > > > soon (don't want Debian 8, but don't want to reinstall from > > > scratch > > > and migrate my Xen VM's ...), > > > dropping support for "it's just time to move on" is more a > > > Desktop > > > philosophy, not for embedded/datacenter > > > approaches ... > > > > For example, we'd like to use the sparse option when building > > rootfs: > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=9099 > > > > This support isn't available in the version of dd in debian 7. Our > > options are: > > > > * Build a dd -native > > For core feature like sparse files its better to control our own > destiny and use dd-native regardless. There are certain core utilities which its very hard to add into the dependency chains correctly. With xz, I recently gave up trying to get the patches right. I'm sure it could be done, it didn't seem worth the effort though. dd and other coreutils fall into the same category, very hard to get right without races. There is probably a redesign of the some of the way staging happens needed to make it work and that is a low priority right now. > But that does not mean we should > not drop debian7 or arcane centos distros that we keep supporting for > ever. I still see patches for centos 5.8 in metadata. We did retire centos 6 recently (qemu wouldn't run there correctly for any of the automated tests). Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
