liberation-fonts: update to 2.00.1
PATCH 1/5 liberation-fonts: update to 2.00.1
'fontforge issue' was actually a non-issue; fontforge is required only when building ttf fonts from sfd source. We took prebuilt ttf fonts when using 1.04 version, and can do the same thing with 2.00.1 version, it's just that the tarball name for prebuilt fonts has slightly changed and no one noticed somehow.
License has changed from GPLv2 to Open Font License v.1.1
---
meta/conf/distro/include/default-versions.inc | 3 ---
...eration-fonts_1.04.bb => liberation-fonts_2.00.1.bb} | 17 ++++++++---------
2 files changed, 8 insertions(+), 12 deletions(-)
rename meta/recipes-graphics/ttf-fonts/{liberation-fonts_1.04.bb => liberation-fonts_2.00.1.bb} (67%)meta/conf/distro/include/default-versions.inc +0 -3
@@ -2,6 +2,3 @@ # Default preferred versions # -# Force the older version of liberation-fonts until we fix the fontforge issue -PREFERRED_VERSION_liberation-fonts ?= "1.04" -
meta/recipes-graphics/ttf-fonts/liberation-fonts_2.00.1.bb renamed from meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb +8 -9
@@ -5,23 +5,22 @@ Arial, Times New Roman, Courier New." HOMEPAGE = "https://releases.pagure.org/liberation-fonts/" BUGTRACKER = "https://bugzilla.redhat.com/" -RECIPE_NO_UPDATE_REASON = "2.x depends on fontforge package, which is not yet provided in oe-core" - SECTION = "x11/fonts" -LICENSE = "GPLv2" -LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" -PR = "r4" +LICENSE = "OFL-1.1" +LIC_FILES_CHKSUM = "file://LICENSE;md5=f96db970a9a46c5369142b99f530366b" PE = "1" inherit allarch fontcache FONT_PACKAGES = "${PN}" -SRC_URI = "https://releases.pagure.org/liberation-fonts/liberation-fonts-${PV}.tar.gz \ +SRC_URI = "https://releases.pagure.org/liberation-fonts/liberation-fonts-ttf-${PV}.tar.gz \ file://30-liberation-aliases.conf" -SRC_URI[md5sum] = "4846797ef0fc70b0cbaede2514677c58" -SRC_URI[sha256sum] = "0e0d0957c85b758561a3d4aef4ebcd2c39959e5328429d96ae106249d83531a1" +S = "${WORKDIR}/liberation-fonts-ttf-${PV}" + +SRC_URI[md5sum] = "5c781723a0d9ed6188960defba8e91cf" +SRC_URI[sha256sum] = "7890278a6cd17873c57d9cd785c2d230d9abdea837e96516019c5885dd271504" do_install () { install -d ${D}${datadir}/fonts/ttf/
@@ -33,7 +32,7 @@ do_install () { install -m 0644 ${WORKDIR}/30-liberation-aliases.conf ${D}${sysconfdir}/fonts/conf.d/ install -d ${D}${prefix}/share/doc/${BPN}/ - install -m 0644 License.txt ${D}${datadir}/doc/${BPN}/ + install -m 0644 LICENSE ${D}${datadir}/doc/${BPN}/ } PACKAGES = "${PN}"
Signature · 1 line
2.11.0
PATCH 2/5 packagegroup-core-lsb: do not include Qt4 anymore
Last version of qt4 was released 2 years ago, and Qt4 was officially EOLd at the end of 2015. On the other hand, LSB is no longer being developed, and so will 'require' Qt4 until the end of time.
Let's pull the plug.
--- .../conf/distro/include/poky-world-exclude.inc | 4 ---- .../packagegroups/packagegroup-core-lsb.bb | 26 ---------------------- 2 files changed, 30 deletions(-)
meta-poky/conf/distro/include/poky-world-exclude.inc +0 -4
@@ -2,7 +2,3 @@ # Things we exlude fromw world testing within the reference distro # -# qwt from meta-qt4, has poky-lsb QA warnings, qt4 for lsb only -EXCLUDE_FROM_WORLD_pn-qwt = "1" -# python-pyqt from meta-qt4 requires sip from meta-oe -EXCLUDE_FROM_WORLD_pn-python-pyqt = "1"
meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb +0 -26
@@ -202,31 +202,6 @@ RDEPENDS_packagegroup-core-lsb-python = "\ python-misc \ " -QT4PKGS = " \ - libqtcore4 \ - libqtgui4 \ - libqtsql4 \ - libqtsvg4 \ - libqtxml4 \ - libqtnetwork4 \ - qt4-plugin-sqldriver-sqlite \ - ${@bb.utils.contains("DISTRO_FEATURES", "opengl", "libqtopengl4", "", d)} \ - " -QT4PKGS_mips64 = "" -QT4PKGS_mips64n32 = "" - -def get_libqt4(d): - if 'linuxstdbase' in d.getVar('DISTROOVERRIDES', False) or "": - if 'qt4' in d.getVar('BBFILE_COLLECTIONS', False) or "": - return d.getVar('QT4PKGS', False) - - bb.warn('The meta-qt4 layer should be added, this layer provides Qt 4.x ' \ - 'libraries. Its intended use is for passing LSB tests as Qt4 is ' \ - 'a requirement for LSB.') - return '' -# We don't want this to rebuild every time you change your layer config -get_libqt4[vardepsexclude] += "BBFILE_COLLECTIONS" - SUMMARY_packagegroup-core-lsb-desktop = "LSB Desktop" DESCRIPTION_packagegroup-core-lsb-desktop = "Packages required to support libraries \ specified in the LSB Desktop specification"
@@ -247,7 +222,6 @@ RDEPENDS_packagegroup-core-lsb-desktop = "\ gtk+ \ atk \ libasound \ - ${@get_libqt4(d)} \ " RDEPENDS_packagegroup-core-lsb-runtime-add = "\
Signature · 1 line
2.11.0
PATCH 3/5 libpng12: remove the recipe
In reply to Alexander KanavinIt was only in oe-core because of LSB; let's remove it. Current libpng is 1.6.x.
--- .../packagegroups/packagegroup-core-lsb.bb | 1 - meta/recipes-lsb4/libpng/libpng12_1.2.57.bb | 36 ---------------------- 2 files changed, 37 deletions(-) delete mode 100644 meta/recipes-lsb4/libpng/libpng12_1.2.57.bb
meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb +0 -1
@@ -177,7 +177,6 @@ RDEPENDS_packagegroup-core-lsb-core = "\ ncurses \ zlib \ nspr \ - libpng12 \ nss \ "
meta/recipes-lsb4/libpng/libpng12_1.2.57.bb deleted +0 -36
@@ -1,36 +0,0 @@ -SUMMARY = "PNG image format decoding library" -HOMEPAGE = "http://www.libpng.org/" -SECTION = "libs" -LICENSE = "Libpng" -LIC_FILES_CHKSUM = "file://LICENSE;md5=597b8a91994a3e27ae6aa79bf02677d9 \ - file://png.h;beginline=19;endline=109;md5=166406397718925b660f0033f7558ef7" -DEPENDS = "zlib" - -PN = "libpng12" -S = "${WORKDIR}/libpng-${PV}" - -SRC_URI = "${GENTOO_MIRROR}/libpng-${PV}.tar.xz" - -SRC_URI[md5sum] = "307052e5e8af97b82b17b64fb1b3677a" -SRC_URI[sha256sum] = "0f4620e11fa283fedafb474427c8e96bf149511a1804bdc47350963ae5cf54d8" - -UPSTREAM_CHECK_URI = "http://sourceforge.net/projects/libpng/files/libpng12/" -UPSTREAM_CHECK_REGEX = "/libpng12/(?P<pver>(\d+[\.\-_]*)+)/" - -BINCONFIG_GLOB = "${PN}-config" - -inherit autotools binconfig pkgconfig - -do_install_append() { - # The follow link files link to corresponding png12*.h and libpng12* files - # They conflict with higher verison, so drop them - rm ${D}/${includedir}/png.h - rm ${D}/${includedir}/pngconf.h - - rm ${D}/${libdir}/libpng.la - rm ${D}/${libdir}/libpng.so - rm ${D}/${libdir}/libpng.a || true - rm ${D}/${libdir}/pkgconfig/libpng.pc - - rm ${D}/${bindir}/libpng-config -}
Signature · 1 line
2.11.0
Re: [PATCH 3/5] libpng12: remove the recipe
Hi Alexander
Am Mittwoch, den 03.05.2017, 16:11 +0300 schrieb Alexander Kanavin:
Quoted 1 line
It was only in oe-core because of LSB; let's remove it. Current libpng is 1.6.x.
This will break at least meta-openembedded glmark2 and glcompbench.
Max
Quoted 66 lines
Signed-off-by Alexander Kanavin <[email protected]>--- .../packagegroups/packagegroup-core-lsb.bb | 1 - meta/recipes-lsb4/libpng/libpng12_1.2.57.bb | 36 ---------------------- 2 files changed, 37 deletions(-) delete mode 100644 meta/recipes-lsb4/libpng/libpng12_1.2.57.bbmeta/recipes renamed from meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb +0
-1-extended/packagegroups/packagegroup-core-lsb.bbindex
61b35e68921..a6fb3023052100644meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb +0
-1@@ -177,7 +177,6 @@ RDEPENDS_packagegroup-core-lsb-core = "\ ncurses \ zlib \ nspr \ - libpng12 \ nss \ "meta/recipes renamed from meta/recipes-lsb4/libpng/libpng12_1.2.57.bb +0
-1-lsb4/libpng/libpng12_1.2.57.bbdeleted file mode 100644
index 9f74f5fdb5a..00000000000meta/recipes-lsb4/libpng/libpng12_1.2.57.bb deleted +0
-36@@ -1,36 +0,0 @@ -SUMMARY = "PNG image format decoding library" -HOMEPAGE = "http://www.libpng.org/" -SECTION = "libs" -LICENSE = "Libpng" -LIC_FILES_CHKSUM = "file://LICENSE;md5=597b8a91994a3e27ae6aa79bf02677d9 \ - file://png.h;beginline=19;endline=109;md5=166406397718925b660f0033f7558ef7" -DEPENDS = "zlib" - -PN = "libpng12" -S = "${WORKDIR}/libpng-${PV}" - -SRC_URI = "${GENTOO_MIRROR}/libpng-${PV}.tar.xz" - -SRC_URI[md5sum] = "307052e5e8af97b82b17b64fb1b3677a" -SRC_URI[sha256sum] = "0f4620e11fa283fedafb474427c8e96bf149511a1804bdc47350963ae5cf54d8" - -UPSTREAM_CHECK_URI = "http://sourceforge.net/projects/libpng/files/libpng12/" -UPSTREAM_CHECK_REGEX = "/libpng12/(?P<pver>(\d+[\.\-_]*)+)/" - -BINCONFIG_GLOB = "${PN}-config" - -inherit autotools binconfig pkgconfig - -do_install_append() { - # The follow link files link to corresponding png12*.h and libpng12* files - # They conflict with higher verison, so drop them - rm ${D}/${includedir}/png.h - rm ${D}/${includedir}/pngconf.h - - rm ${D}/${libdir}/libpng.la - rm ${D}/${libdir}/libpng.so - rm ${D}/${libdir}/libpng.a || true - rm ${D}/${libdir}/pkgconfig/libpng.pc - - rm ${D}/${bindir}/libpng-config -}Signature · 1 line
2.11.0
Re: [PATCH 3/5] libpng12: remove the recipe
Quoted 4 lines · Max Krummenacher
Quoted 1 line
It was only in oe-core because of LSB; let's remove it. Current libpng
is 1.6.x.
This will break at least meta-openembedded glmark2 and glcompbench.
Then meta-oe can continue to host libpng12.
Ross
Re: [PATCH 3/5] libpng12: remove the recipe
Quoted 7 lines · Ross
Quoted 2 lines
It was only in oe-core because of LSB; let's remove it. Current libpng is 1.6.x.
This will break at least meta-openembedded glmark2 and glcompbench.
Then meta-oe can continue to host libpng12.
I actually think allowing those recipes to fail and blacklisting them is better. Moving libpng12 to meta-oe is the lazy way out; the proper way to deal with such regressions is to look at the actual recipes, what they do, why they need such an old version of libpng, and whether they should be updated or removed from meta-oe altogether. The only way to get people to do this real maintenance work is to break the build for them, sadly. I cannot take on maintaining things in meta-oe in this way, I have to draw the line somewhere, and this is it.
Alex
Re: [PATCH 3/5] libpng12: remove the recipe
On 4 May 2017 at 10:18, Alexander Kanavin <[email protected]
Quoted 5 lines
wrote:
Then meta-oe can continue to host libpng12.
Quoted 1 line
Quoted 9 lines
I actually think allowing those recipes to fail and blacklisting them is better. Moving libpng12 to meta-oe is the lazy way out; the proper way to deal with such regressions is to look at the actual recipes, what they do, why they need such an old version of libpng, and whether they should be updated or removed from meta-oe altogether. The only way to get people to do this real maintenance work is to break the build for them, sadly. I cannot take on maintaining things in meta-oe in this way, I have to draw the line somewhere, and this is it.
For what it's worth, glmark2 was fixed in 2014:
https://github.com/glmark2/glmark2/commit/499aa81a68fb4c8aac1c80f0d6a4cce05941c4cc
glcompbench appears to be a fork of glmark, so the same fix should be trivial to apply.
Ross
Re: [PATCH 3/5] libpng12: remove the recipe
Am Donnerstag, den 04.05.2017, 10:54 +0100 schrieb Burton, Ross:
Quoted 15 lines
On 4 May 2017 at 10:18, Alexander Kanavin <[email protected]
Quoted 14 lines
wrote:
Then meta-oe can continue to host libpng12.
Quoted 1 line
I actually think allowing those recipes to fail and blacklisting them is better. Moving libpng12 to meta-oe is the lazy way out; the proper way to deal with such regressions is to look at the actual recipes, what they do, why they need such an old version of libpng, and whether they should be updated or removed from meta-oe altogether. The only way to get people to do this real maintenance work is to break the build for them, sadly. I cannot take on maintaining things in meta-oe in this way, I have to draw the line somewhere, and this is it.
My concern at the moment is that anything removed now from oe-core will also be removed in oe-core pyro in the foreseeable future but the fix or relocation in meta-xyz will take time.
Around the release of morty the same happened with libwnck3 which then made morty fail for anyone using libwnck3.
Quoted 6 lines
For what it's worth, glmark2 was fixed in 2014:
https://github.com/glmark2/glmark2/commit/499aa81a68fb4c8aac1c80f0d6a4cce05941c4ccglcompbench appears to be a fork of glmark, so the same fix should be trivial to apply.
I agree that the it is an easy fix for glmark2 and probably not that hard with glcompbench, nonetheless its sometimes nice to get a head start before things break.
Max
Quoted 1 line
Ross
Re: [PATCH 3/5] libpng12: remove the recipe
Quoted 3 lines · Max Krummenacher
My concern at the moment is that anything removed now from oe-core will also be removed in oe-core pyro in the foreseeable future but the fix or relocation in meta-xyz will take time.
I'm fairly sure these patches will not make it to pyro - they are for 2.4 only. So everyone will have a few months to fix up their layers before 2.4 is out.
Quoted 2 lines
Around the release of morty the same happened with libwnck3 which then made morty fail for anyone using libwnck3.
We probably should have a section in the release notes that lists removed recipes. There are more layers than meta-oe, obviously they can't be all fixed in sync with oe-core.
Quoted 8 lines
Quoted 5 lines
For what it's worth, glmark2 was fixed in 2014:
https://github.com/glmark2/glmark2/commit/499aa81a68fb4c8aac1c80f0d6a4cce05941c4ccglcompbench appears to be a fork of glmark, so the same fix should be trivial to apply.
I agree that the it is an easy fix for glmark2 and probably not that hard with glcompbench, nonetheless its sometimes nice to get a head start before things break.
I would rather remove glcompbench, as it was last updated in 2012 upstream. If someone objects, they should step up and actually maintain the code and the recipe.
Generally, such fixes scale poorly in the absence of proper recipe maintainers: we are lucky there's just two recipes, but what if there was twenty?
Alex
Re: [PATCH 3/5] libpng12: remove the recipe
Quoted 7 lines · NZST Alexander Kanavin
Quoted 2 lines · Max Krummenacher
Around the release of morty the same happened with libwnck3 which then made morty fail for anyone using libwnck3.
We probably should have a section in the release notes that lists removed recipes. There are more layers than meta-oe, obviously they can't be all fixed in sync with oe-core.
We have a migration section of the YP reference manual [1], which is linked from the release notes. I strongly recommend reading this on every major release upgrade, as it should cover changes that you need to adapt your recipes/configuration to.
That said, there are some limitations of this currently:
1) We (and I say "we", it's often me supplying Scott with the information) usually only get to writing it towards the end of the release cycle, so if you're following master then you won't get much out of this, but then again if you're following master you should probably expect to have to deal with the bleeding edge. There is a wiki page [2] where we are supposed to be adding items as we go along during the cycle, and we did do a few during 2.3 but there were still quite a number of things that were missing and lots of details that needed to be added.
2) There may be upstream changes that we pick up as a result of recipe upgrades that could cause issues for someone (depending on what you're actually building, of course). We don't really have a way of easily tracking these at the moment; unfortunately every upstream reports their changes differently.
Cheers,
Paul
[2] https://wiki.yoctoproject.org/wiki/FutureMigrationGuide
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Re: [PATCH 3/5] libpng12: remove the recipe
In reply to Max KrummenacherQuoted 6 lines · Max Krummenacher
My concern at the moment is that anything removed now from oe-core will also be removed
in oe-core pyro in the foreseeable future but the fix or relocation in meta-xyz will
take time.
Releases only receive critical and security fixes, a recipe will never[1] be removed once a release branch has frozen.
Quoted 4 lines
Around the release of morty the same happened with libwnck3 which then made morty fail for
anyone using libwnck3.
I think you're remembering wrong, or using master.
$ git show 5741419426c6f8255d55560e3a4721fa4c68a179 commit 5741419426c6f8255d55560e3a4721fa4c68a179 Author: Alexander Kanavin <[email protected]> Date: Mon Oct 24 15:45:48 2016 +0300
libwnck3: remove the recipe
Nothing requires it in oe-core now, so it will be re-added to
meta-openembedded.
$ git branch -r --contains 5741419426c6f8255d55560e3a4721fa4c68a179 | grep oe-core/ oe-core/master oe-core/pyro
It was removed in master *after* morty branched, and was subsequently aded to meta-oe.
Ross
[1] Almost never. Don't think it's ever happened but we won't remove a recipe from a stable release because we don't like it.
PATCH 4/5 recipes-lsb4/perl: remove the recipes
In reply to Alexander KanavinThese were required by LSB 4.1 tests; there's no other reason to continue carrying them in oe-core.
--- .../packagegroups/packagegroup-core-lsb.bb | 6 ---- meta/recipes-lsb4/perl/libclass-isa-perl_0.36.bb | 31 --------------------- meta/recipes-lsb4/perl/libdumpvalue-perl_1.17.bb | 18 ------------ meta/recipes-lsb4/perl/libenv-perl_1.04.bb | 21 -------------- .../perl/libfile-checktree-perl_4.41.bb | 32 ---------------------- .../recipes-lsb4/perl/libi18n-collate-perl_1.02.bb | 21 -------------- meta/recipes-lsb4/perl/libpod-plainer-perl_1.04.bb | 23 ---------------- 7 files changed, 152 deletions(-) delete mode 100644 meta/recipes-lsb4/perl/libclass-isa-perl_0.36.bb delete mode 100644 meta/recipes-lsb4/perl/libdumpvalue-perl_1.17.bb delete mode 100644 meta/recipes-lsb4/perl/libenv-perl_1.04.bb delete mode 100644 meta/recipes-lsb4/perl/libfile-checktree-perl_4.41.bb delete mode 100644 meta/recipes-lsb4/perl/libi18n-collate-perl_1.02.bb delete mode 100644 meta/recipes-lsb4/perl/libpod-plainer-perl_1.04.bb
meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb +0 -6
@@ -239,10 +239,4 @@ RDEPENDS_packagegroup-core-lsb-runtime-add = "\ glibc-localedata-posix \ glibc-extra-nss \ glibc-pcprofile \ - libclass-isa-perl \ - libenv-perl \ - libdumpvalue-perl \ - libfile-checktree-perl \ - libi18n-collate-perl \ - libpod-plainer-perl \ "
meta/recipes-lsb4/perl/libclass-isa-perl_0.36.bb deleted +0 -31
@@ -1,31 +0,0 @@ -SUMMARY = "Perl module for reporting the search path for a class's ISA tree" -DESCRIPTION = "Suppose you have a class (like Food::Fish::Fishstick) that is derived, \ -via its @ISA, from one or more superclasses (as Food::Fish::Fishstick is from Food::Fish,\ -Life::Fungus, and Chemicals), and some of those superclasses may themselves each be\ -derived, via its @ISA, from one or more superclasses (as above).\ -\ -When, then, you call a method in that class ($fishstick->calories), Perl first searches\ -there for that method, but if it's not there, it goes searching in its superclasses, and\ -so on, in a depth-first (or maybe "height-first" is the word) search. In the above example,\ -it'd first look in Food::Fish, then Food, then Matter, then Life::Fungus, then Life, then\ -Chemicals.\ -\ -This library, Class::ISA, provides functions that return that list -- the list\ -(in order) of names of classes Perl would search to find a method, with no duplicates." - -HOMEPAGE = "http://search.cpan.org/dist/Class-ISA/" -SECTION = "libs" -LICENSE = "Artistic-1.0 | GPL-1.0+" - -LIC_FILES_CHKSUM = "file://README;beginline=107;endline=111;md5=6a5c6842a63cfe4dab1f66e2350e4d25" - -SRC_URI = "http://search.cpan.org/CPAN/authors/id/S/SM/SMUELLER/Class-ISA-${PV}.tar.gz" - -SRC_URI[md5sum] = "3a2ad203c8dc87d6c9de16215d00af47" -SRC_URI[sha256sum] = "8816f34e9a38e849a10df756030dccf9fe061a196c11ac3faafd7113c929b964" - -S = "${WORKDIR}/Class-ISA-${PV}" - -inherit cpan - -BBCLASSEXTEND = "native"
meta/recipes-lsb4/perl/libdumpvalue-perl_1.17.bb deleted +0 -18
@@ -1,18 +0,0 @@ -SUMMARY = "Perl module for provides screen dump of Perl data" - -HOMEPAGE = "http://search.cpan.org/~flora/Dumpvalue/" -SECTION = "libs" -LICENSE = "Artistic-1.0 | GPL-1.0+" - -LIC_FILES_CHKSUM = "file://LICENSE;md5=f736bec5ada1fc5e39b2a8e7e06bbcbb" - -SRC_URI = "http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Dumpvalue-${PV}.tar.gz" - -SRC_URI[md5sum] = "6ede9f693d4a9c4555541cb1a1cc2006" -SRC_URI[sha256sum] = "9ea74606b545f769a787ec2ae229549a2ad0a8e3cd4b14eff2ce3841836b3bdb" - -S = "${WORKDIR}/Dumpvalue-${PV}" - -inherit cpan - -BBCLASSEXTEND = "native"
meta/recipes-lsb4/perl/libenv-perl_1.04.bb deleted +0 -21
@@ -1,21 +0,0 @@ -SUMMARY = "Perl module that imports environment variables as scalars or arrays" -DESCRIPTION = "Perl maintains environment variables in a special hash named %ENV. \ -For when this access method is inconvenient, the Perl module Env allows environment \ -variables to be treated as scalar or array variables." - -HOMEPAGE = "http://search.cpan.org/~flora/Env/" -SECTION = "libs" -LICENSE = "Artistic-1.0 | GPL-1.0+" - -LIC_FILES_CHKSUM = "file://LICENSE;md5=76c1cbf18db56b3340d91cb947943bd3" - -SRC_URI = "http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Env-${PV}.tar.gz" - -SRC_URI[md5sum] = "fdba5c0690e66972c96fee112cf5f25c" -SRC_URI[sha256sum] = "d94a3d412df246afdc31a2199cbd8ae915167a3f4684f7b7014ce1200251ebb0" - -S = "${WORKDIR}/Env-${PV}" - -inherit cpan - -BBCLASSEXTEND = "native"
meta/recipes-lsb4/perl/libfile-checktree-perl_4.41.bb deleted +0 -32
@@ -1,32 +0,0 @@ -SUMMARY = "Perl module that run many filetest checks on a tree" -DESCRIPTION = "The validate() routine takes a single multiline string consisting \ -of directives, each containing a filename plus a file test to try on it. (The file \ -test may also be a "cd", causing subsequent relative filenames to be interpreted \ -relative to that directory.) After the file test you may put || die to make it a \ -fatal error if the file test fails. The default is || warn. The file test may \ -optionally have a "!' prepended to test for the opposite condition. If you do a \ -cd and then list some relative filenames, you may want to indent them slightly for \ -readability. If you supply your own die() or warn() message, you can use $file to \ -interpolate the filename. \ -\ -Filetests may be bunched: "-rwx" tests for all of -r, -w, and -x. Only the first failed \ -test of the bunch will produce a warning. \ -\ -The routine returns the number of warnings issued." - -HOMEPAGE = "http://search.cpan.org/~flora/File-CheckTree/" -SECTION = "libs" -LICENSE = "Artistic-1.0 | GPL-1.0+" - -LIC_FILES_CHKSUM = "file://LICENSE;md5=c6fcacc5df80e037060300a7f4b93bf9" - -SRC_URI = "http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/File-CheckTree-${PV}.tar.gz" - -SRC_URI[md5sum] = "519c82aa7e5b7f752b4da14a6c8ad740" -SRC_URI[sha256sum] = "fc99ab6bb5af4664832715974b5a19e328071dc9202ab72e5d5a594ebd46a729" - -S = "${WORKDIR}/File-CheckTree-${PV}" - -inherit cpan - -BBCLASSEXTEND = "native"
meta/recipes-lsb4/perl/libi18n-collate-perl_1.02.bb deleted +0 -21
@@ -1,21 +0,0 @@ -SUMMARY = "Perl module that compare 8-bit scalar data according to the current locale" -DESCRIPTION = "This module provides you with objects that will collate according to \ -your national character set, provided that the POSIX setlocale() function is supported \ -on your system." - -HOMEPAGE = "http://search.cpan.org/~flora/I18N-Collate/" -SECTION = "libs" -LICENSE = "Artistic-1.0 | GPL-1.0+" - -LIC_FILES_CHKSUM = "file://LICENSE;md5=ff6d629144a6ec1ea8c300f75760184f" - -SRC_URI = "http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/I18N-Collate-${PV}.tar.gz" - -SRC_URI[md5sum] = "72ddb6d1c59cfdf31aa3b04799b86af0" -SRC_URI[sha256sum] = "9174506bc903eda89690394e3f45558ab7e013114227896d8569d6164648fe37" - -S = "${WORKDIR}/I18N-Collate-${PV}" - -inherit cpan - -BBCLASSEXTEND = "native"
meta/recipes-lsb4/perl/libpod-plainer-perl_1.04.bb deleted +0 -23
@@ -1,23 +0,0 @@ -SUMMARY = "Perl extension for converting Pod to old-style Pod" -DESCRIPTION = "Pod::Plainer uses Pod::Parser which takes Pod with the (new) 'C<< .. >>' \ -constructs and returns the old(er) style with just 'C<>'; '<' and '>' are replaced by \ -'E<lt>' and 'E<gt>'. \ -\ -This can be used to pre-process Pod before using tools which do not recognise the new style Pods." - -HOMEPAGE = "http://search.cpan.org/dist/Pod-Plainer/" -SECTION = "libs" -LICENSE = "Artistic-1.0 | GPL-1.0+" - -LIC_FILES_CHKSUM = "file://README;beginline=27;md5=227cf83970fc61264845825d9d2bf6f8" - -SRC_URI = "http://search.cpan.org/CPAN/authors/id/R/RM/RMBARKER/Pod-Plainer-${PV}.tar.gz" - -SRC_URI[md5sum] = "f502eacd1a40894b9dfea55fc2cd5e7d" -SRC_URI[sha256sum] = "1bbfbf7d1d4871e5a83bab2137e22d089078206815190eb1d5c1260a3499456f" - -S = "${WORKDIR}/Pod-Plainer-${PV}" - -inherit cpan - -BBCLASSEXTEND = "native"
Signature · 1 line
2.11.0
Re: [PATCH 4/5] recipes-lsb4/perl: remove the recipes
Quoted 3 lines · Alexander Kanavin
These were required by LSB 4.1 tests; there's no other reason to continue
carrying them in oe-core.
We did discuss LSB and agreed we'd document which pieces we'd support and not support. Can we add such a text file before we start deleting things please?
[I'm totally in favour of killing off some of these things, but we need to do what we said we'd do]
Cheers,
Richard
Re: [PATCH 4/5] recipes-lsb4/perl: remove the recipes
Quoted 11 lines · Richard Purdie
Quoted 3 lines · Alexander Kanavin
These were required by LSB 4.1 tests; there's no other reason to continue
carrying them in oe-core.We did discuss LSB and agreed we'd document which pieces we'd support and not support. Can we add such a text file before we start deleting things please?
[I'm totally in favour of killing off some of these things, but we need to do what we said we'd do]
I have added a 'docchange: yes' flag to the bug [1], so that Scott would document the changes, and assumed this would be sufficient?
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=11316
Alex
Re: [PATCH 4/5] recipes-lsb4/perl: remove the recipes
Quoted 13 lines · Alexander Kanavin
Quoted 12 lines · Richard Purdie
Quoted 4 lines · Alexander Kanavin
These were required by LSB 4.1 tests; there's no other reason to continue
carrying them in oe-core.We did discuss LSB and agreed we'd document which pieces we'd support
and not support. Can we add such a text file before we start deleting
things please?
Quoted 8 lines
Quoted 3 lines
[I'm totally in favour of killing off some of these things, but we need
to do what we said we'd do]I have added a 'docchange: yes' flag to the bug [1], so that Scott would
document the changes, and assumed this would be sufficient?
In this case I think we need to do a little more. I think we need a README.LSB at the top of tree which says something like:
"""
OE-Core aims to be able to provide basic LSB compatible images. There are some challenges for OE as LSB isn't always 100% relevant to its target embedded and IoT audiences.
One challenge is that the LSB spec is no longer being actively developed [insert link] and has components which are end of life or significantly dated. OE therefore provides compatibility with the following caveats:
* Qt4 is provided by the separate meta-qt4 layer. Its noted that Qt4 is end of life and this isn't something the core project regularly tests any longer. Users are recommended to group together to support maintenance of that layer.
* mailx has been dropped since its no longer being developed upstream and there are better, more modern replacements [add details]
* [details about perl modules]
"""
So when you delete something which LSB needs, we can add it here with some information about why.
Cheers,
Richard
PATCH 5/5 mailx: remove the recipe
In reply to Alexander KanavinThis recipe was carried only for LSB compatibility,
with upstream being defunct for a long time; if there is a need for a modern, supported implementation of mail/mailx, then s-nail (http://sdaoden.eu/code.html) or mailutils (http://mailutils.org/)
should be used.
--- ...e-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch | 59 ----------- ...-SSL2-support-since-it-is-no-longer-suppo.patch | 41 -------- ...ntian-warning-warning-macro-N-not-defined.patch | 25 ----- .../0011-outof-Introduce-expandaddr-flag.patch | 71 ------------- ...ble-option-processing-for-email-addresses.patch | 79 -------------- ...c-Unconditionally-require-wordexp-support.patch | 113 --------------------- ...4-globname-Invoke-wordexp-with-WRDE_NOCMD.patch | 31 ------ .../mailx/files/0015-usr-sbin-sendmail.patch | 38 ------- .../files/explicitly.disable.krb5.support.patch | 46 --------- meta/recipes-extended/mailx/mailx_12.5-5.bb | 53 ---------- .../packagegroups/packagegroup-core-lsb.bb | 1 - 11 files changed, 557 deletions(-) delete mode 100644 meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch delete mode 100644 meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch delete mode 100644 meta/recipes-extended/mailx/files/0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch delete mode 100644 meta/recipes-extended/mailx/files/0011-outof-Introduce-expandaddr-flag.patch delete mode 100644 meta/recipes-extended/mailx/files/0012-unpack-Disable-option-processing-for-email-addresses.patch delete mode 100644 meta/recipes-extended/mailx/files/0013-fio.c-Unconditionally-require-wordexp-support.patch delete mode 100644 meta/recipes-extended/mailx/files/0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch delete mode 100644 meta/recipes-extended/mailx/files/0015-usr-sbin-sendmail.patch delete mode 100644 meta/recipes-extended/mailx/files/explicitly.disable.krb5.support.patch delete mode 100644 meta/recipes-extended/mailx/mailx_12.5-5.bb
meta/recipes-extended/mailx/files/0001-Don-t-reuse-weak-symbol-optopt-to-fix-FTBFS-on-mips.patch deleted +0 -59
@@ -1,59 +0,0 @@ -From: Luk Claes <[email protected]> -Date: Sat, 4 Jul 2009 10:54:53 +0200 -Subject: Don't reuse weak symbol optopt to fix FTBFS on mips* - -This patch is taken from -ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.5-5.debian.tar.xz - -Upstream-Status: Inappropriate [upstream is dead] ---- - getopt.c | 10 +++++----- - 1 file changed, 5 insertions(+), 5 deletions(-) - -diff --git a/getopt.c b/getopt.c -index 83ce628..82e983c 100644 ---- a/getopt.c -+++ b/getopt.c -@@ -43,7 +43,7 @@ typedef int ssize_t; - char *optarg; - int optind = 1; - int opterr = 1; --int optopt; -+int optoptc; - - static void - error(const char *s, int c) -@@ -69,7 +69,7 @@ error(const char *s, int c) - *bp++ = *s++; - while (*msg) - *bp++ = *msg++; -- *bp++ = optopt; -+ *bp++ = optoptc; - *bp++ = '\n'; - write(2, buf, bp - buf); - ac_free(buf); -@@ -101,13 +101,13 @@ getopt(int argc, char *const argv[], const char *optstring) - } - curp = &argv[optind][1]; - } -- optopt = curp[0] & 0377; -+ optoptc = curp[0] & 0377; - while (optstring[0]) { - if (optstring[0] == ':') { - optstring++; - continue; - } -- if ((optstring[0] & 0377) == optopt) { -+ if ((optstring[0] & 0377) == optoptc) { - if (optstring[1] == ':') { - if (curp[1] != '\0') { - optarg = (char *)&curp[1]; -@@ -127,7 +127,7 @@ getopt(int argc, char *const argv[], const char *optstring) - optind++; - optarg = 0; - } -- return optopt; -+ return optoptc; - } - optstring++; - }
meta/recipes-extended/mailx/files/0002-Patched-out-SSL2-support-since-it-is-no-longer-suppo.patch deleted +0 -41
41 lines not on this page · raw message
meta/recipes-extended/mailx/files/0003-Fixed-Lintian-warning-warning-macro-N-not-defined.patch deleted +0 -25
@@ -1,25 +0,0 @@ -From: Hilko Bengen <[email protected]> -Date: Sat, 14 Apr 2012 20:22:43 +0200 -Subject: Fixed Lintian warning (warning: macro `N' not defined) - -This patch is taken from -ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.5-5.debian.tar.xz - -Upstream-Status: Inappropriate [upstream is dead] ---- - mailx.1 | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/mailx.1 b/mailx.1 -index a02e430..b0723bd 100644 ---- a/mailx.1 -+++ b/mailx.1 -@@ -3781,7 +3781,7 @@ you could examine the first message by giving the command: - .sp - .fi - which might cause --.N mailx -+.I mailx - to respond with, for example: - .nf - .sp
meta/recipes-extended/mailx/files/0011-outof-Introduce-expandaddr-flag.patch deleted +0 -71
71 lines not on this page · raw message
meta/recipes-extended/mailx/files/0012-unpack-Disable-option-processing-for-email-addresses.patch deleted +0 -79
79 lines not on this page · raw message
meta/recipes-extended/mailx/files/0013-fio.c-Unconditionally-require-wordexp-support.patch deleted +0 -113
113 lines not on this page · raw message
meta/recipes-extended/mailx/files/0014-globname-Invoke-wordexp-with-WRDE_NOCMD.patch deleted +0 -31
@@ -1,31 +0,0 @@ -From 73fefa0c1ac70043ec84f2d8b8f9f683213f168d Mon Sep 17 00:00:00 2001 -From: Florian Weimer <[email protected]> -Date: Mon, 17 Nov 2014 13:11:32 +0100 -Subject: [PATCH 4/4] globname: Invoke wordexp with WRDE_NOCMD (CVE-2004-2771) - -This patch is taken from -ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.5-5.debian.tar.xz - -Upstream-Status: Inappropriate [upstream is dead] -CVE: CVE-2004-2771 ---- - fio.c | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/fio.c b/fio.c -index 1529236..774a204 100644 ---- a/fio.c -+++ b/fio.c -@@ -497,7 +497,7 @@ globname(char *name) - sigemptyset(&nset); - sigaddset(&nset, SIGCHLD); - sigprocmask(SIG_BLOCK, &nset, NULL); -- i = wordexp(name, &we, 0); -+ i = wordexp(name, &we, WRDE_NOCMD); - sigprocmask(SIG_UNBLOCK, &nset, NULL); - switch (i) { - case 0: --- -1.9.3 - -
meta/recipes-extended/mailx/files/0015-usr-sbin-sendmail.patch deleted +0 -38
@@ -1,38 +0,0 @@ -Description: Sendmail is at /usr/sbin/sendmail - As per Debian Policy §11.6 -Author: Ryan Kavanagh <[email protected]> -Origin: Debian -Forwarded: no ---- -This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ -Index: heirloom-mailx-12.5/Makefile -=================================================================== -This patch is taken from -ftp://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.5-5.debian.tar.xz - -Upstream-Status: Inappropriate [upstream is dead] - ---- heirloom-mailx-12.5.orig/Makefile 2011-04-26 17:23:22.000000000 -0400 -+++ heirloom-mailx-12.5/Makefile 2015-01-27 13:20:04.733542801 -0500 -@@ -13,7 +13,7 @@ - - MAILRC = $(SYSCONFDIR)/nail.rc - MAILSPOOL = /var/mail --SENDMAIL = /usr/lib/sendmail -+SENDMAIL = /usr/sbin/sendmail - - DESTDIR = - -Index: heirloom-mailx-12.5/mailx.1 -=================================================================== ---- heirloom-mailx-12.5.orig/mailx.1 2015-01-27 13:18:49.000000000 -0500 -+++ heirloom-mailx-12.5/mailx.1 2015-01-27 13:20:32.382336867 -0500 -@@ -4922,7 +4922,7 @@ - which just acts as a proxy. - .PP - \fIMailx\fR immediately contacts the SMTP server (or --.IR \%/usr/lib/sendmail ) -+.IR \%/usr/sbin/sendmail ) - even when operating in - .I disconnected - mode.
meta/recipes-extended/mailx/files/explicitly.disable.krb5.support.patch deleted +0 -46
46 lines not on this page · raw message
meta/recipes-extended/mailx/mailx_12.5-5.bb deleted +0 -53
53 lines not on this page · raw message
meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb +0 -1
@@ -153,7 +153,6 @@ RDEPENDS_packagegroup-core-lsb-core = "\ localedef \ lsb \ m4 \ - mailx \ make \ man \ man-pages \
Signature · 1 line
2.11.0
✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more
In reply to Alexander Kanavin== Series Details ==
Series: "liberation-fonts: update to 2...." and 4 more
Revision: 1
URL : https://patchwork.openembedded.org/series/6590/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures:
* Issue Series does not apply on top of target branch [test_series_merge_on_head]
Suggested fix Rebase your series on top of targeted branch
Targeted branch master (currently at 1239620182)
* Issue Series sent to the wrong mailing list [test_target_mailing_list]
Suggested fix Send the series again to the correct mailing list (ML)
Suggested ML [email protected] [http://git.yoctoproject.org/cgit/cgit.cgi/poky/]
If you believe any of these test results are incorrect, please reply to the mailing list ([email protected]) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...).
---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
Re: ✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more
Quoted 1 line · NZST Patchwork
* Issue Series sent to the wrong mailing list
[test_target_mailing_list]
Quoted 2 lines
Suggested fix Send the series again to the correct mailing list (ML)
Suggested ML [email protected] [http://git.yoctoproject.org/cgit/
cgit.cgi/poky/]
Leo - looks like this is another false positive.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Re: ✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more
Quoted 8 lines · Paul Eggleton
Quoted 1 line · NZST Patchwork
* Issue Series sent to the wrong mailing list
[
test_target_mailing_list]Quoted 2 lines
Suggested fix Send the series again to the correct mailing list (ML)
Suggested ML [email protected] [http://git.yoctoproject.org/cgit/cgit.cgi/poky/]
Leo - looks like this is another false positive.
Actually, no - one of the patches accidentally included a file from meta-poky. Still, could be reported better:
1) Should refer to a specific patch where the issue is
2) Should, if possible, refer to specific files in the patch that are causing the problem.
3) The problem is not the wrong mailing list, the problem is that the patch should be splitted up and sent to several lists :)
In general, why run these checks after the patches have been already posted for review? That is adding unnecessary friction. Why not have them as a git hook, that is run locally when making the commit?
Alex
Re: ✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more
Hi Alex,
Quoted 6 lines · NZST Alexander Kanavin
Quoted 5 lines · Paul Eggleton
Quoted 1 line · NZST Patchwork
* Issue Series sent to the wrong mailing list
[
test_target_mailing_list]Quoted 2 lines
Suggested fix Send the series again to the correct mailing list (ML)
Suggested ML [email protected] [http://git.yoctoproject.org/
cgit/
Quoted 10 lines
Quoted 3 lines
cgit.cgi/poky/]
Leo - looks like this is another false positive.
Actually, no - one of the patches accidentally included a file from meta-poky. Still, could be reported better:
1) Should refer to a specific patch where the issue is
2) Should, if possible, refer to specific files in the patch that are causing the problem.
Right, agreed on both counts. I guess we were trying to catch the more common case of people sending entire patchsets to the wrong list.
Quoted 2 lines
3) The problem is not the wrong mailing list, the problem is that the patch should be splitted up and sent to several lists :)
The question is can an automated tool tell the difference? I guess even if it can't though we can be honest about that in the message i.e. "Wrong mailing list, or incorrectly split patch" or something like that.
Quoted 3 lines
In general, why run these checks after the patches have been already posted for review? That is adding unnecessary friction. Why not have them as a git hook, that is run locally when making the commit?
The original idea was that the tests could also be run from your local machine (could easily be as a git hook), and whilst it's not as easy as I might have liked it is doable - however even if it were much easier, we have to be realistic and acknowledge that most people still won't do it.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Re: ✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more
Quoted 4 lines · Paul Eggleton
The original idea was that the tests could also be run from your local machine (could easily be as a git hook), and whilst it's not as easy as I might have liked it is doable - however even if it were much easier, we have to be realistic and acknowledge that most people still won't do it.
I thought default git hooks can be enforced by the remote repo when you do a clone, no?
Alex
Re: ✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more
Quoted 14 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Alexander Kanavin
Sent: den 4 maj 2017 12:17
To: Paul Eggleton <[email protected]>
Cc: Leonardo Sandoval <[email protected]>; [email protected]
Subject: Re: [OE-core] ✗ patchtest: failure for "liberation-fonts:
update to 2...." and 4 moreQuoted 1 line · Paul Eggleton
The original idea was that the tests could also be run from your
local machine
Quoted 8 lines
Quoted 1 line
(could easily be as a git hook), and whilst it's not as easy as I
might have
Quoted 1 line
liked it is doable - however even if it were much easier, we have to
be
Quoted 1 line
realistic and acknowledge that most people still won't do it.
I thought default git hooks can be enforced by the remote repo when you do a clone, no?
Nope, standard Git has no such support. It would be a security risk if the remote repository would provide hooks that started running on the client without being actively activated.
Quoted 1 line
Alex
//Peter
Re: ✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more
In reply to Alexander KanavinQuoted 2 lines · NZST Alexander Kanavin
Quoted 1 line · Paul Eggleton
The original idea was that the tests could also be run from your local
machine
Quoted 1 line
Quoted 1 line
(could easily be as a git hook), and whilst it's not as easy as I might
have
Quoted 5 lines
Quoted 2 lines
liked it is doable - however even if it were much easier, we have to be realistic and acknowledge that most people still won't do it.
I thought default git hooks can be enforced by the remote repo when you do a clone, no?
On the client side, no, you can't set up hooks as part of a clone - I assume this is for security reasons if nothing else. You could add a hook on the server side, but that carries its own penalty - it means that the hook needs to run synchronous with the operation (e.g. push). Whilst the patchtest tests aren't supposed to take too long, it's not hard to imagine they could take a minute or two, and that is going to be somewhat infuriating especially with the amount of WIP stuff that people (quite legitimately) push to the contrib repos which shouldn't be evaluated at all. Besides, not everyone uses the contrib repos.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Re: ✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more
In reply to Paul EggletonQuoted 21 lines · Paul Eggleton
Hi Alex,
Quoted 6 lines · NZST Alexander Kanavin
Quoted 5 lines · Paul Eggleton
Quoted 1 line · NZST Patchwork
* Issue Series sent to the wrong mailing list
[
test_target_mailing_list]Quoted 2 lines
Suggested fix Send the series again to the correct mailing list (ML)
Suggested ML [email protected] [http://git.yoctoproject.org/cgit/
Quoted 10 lines
Quoted 3 lines
cgit.cgi/poky/]
Leo - looks like this is another false positive.
Actually, no - one of the patches accidentally included a file from meta-poky. Still, could be reported better:
1) Should refer to a specific patch where the issue is
2) Should, if possible, refer to specific files in the patch that are causing the problem.
yes, I realized that and try to make it better with:
Due to the nature of the objects being used, the easiest is to provide the patch's path, so point 2 is covered, not 1.
Quoted 11 lines
Right, agreed on both counts. I guess we were trying to catch the more common case of people sending entire patchsets to the wrong list.
Quoted 2 lines
3) The problem is not the wrong mailing list, the problem is that the patch should be splitted up and sent to several lists :)
The question is can an automated tool tell the difference? I guess even if it can't though we can be honest about that in the message i.e. "Wrong mailing list, or incorrectly split patch" or something like that.
agree on the proposed message. I change it.
Quoted 10 lines
Quoted 4 lines
In general, why run these checks after the patches have been already posted for review? That is adding unnecessary friction. Why not have them as a git hook, that is run locally when making the commit?
The original idea was that the tests could also be run from your local machine (could easily be as a git hook), and whilst it's not as easy as I might have liked it is doable - however even if it were much easier, we have to be realistic and acknowledge that most people still won't do it.
I proposed the following script:
http://lists.openembedded.org/pipermail/openembedded-core/2017-February/132592.html
which basically takes patches from master to current branch HEAD and iterates on each one (not yet merged on master). Once script is run, results are in console then developer can iterate on the series in case of failures.
Quoted 7 lines
Cheers,
PaulSignature · 2 lines
Paul Eggleton Intel Open Source Technology Centre