Skip to contentSkip to conversation

liberation-fonts: update to 2.00.1

PATCH Superseded Alexander Kanavin 8 participants 24 messages May 3, 2017 – May 7, 2017

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

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
index d976508ff51..a6f331350eb 100644
@@ -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
similarity index 67%
rename from meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb
rename to meta/recipes-graphics/ttf-fonts/liberation-fonts_2.00.1.bb
index 74212e7e5ed..412da48725e 100644
@@ -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
#1 lore raw

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
index a6635b63aa4..1a2dea5859b 100644
@@ -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
index 224ff19819c..61b35e68921 100644
@@ -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
#2 lore raw

PATCH 3/5 libpng12: remove the recipe

In reply to Alexander Kanavin

It 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
index 61b35e68921..a6fb3023052 100644
@@ -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
deleted file mode 100644
index 9f74f5fdb5a..00000000000
@@ -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
#3 lore raw

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
---
 .../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 renamed from meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb +0 -1
-extended/packagegroups/packagegroup-core-lsb.bb

index 61b35e68921..a6fb3023052 100644

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 renamed from meta/recipes-lsb4/libpng/libpng12_1.2.57.bb +0 -1
-lsb4/libpng/libpng12_1.2.57.bb

deleted file mode 100644
index 9f74f5fdb5a..00000000000

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
#4 lore raw

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

#5 lore raw

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

#6 lore raw

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

#7 lore raw

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/499aa81a68fb4c8aac1c80f0d6a4cce05941c4cc

glcompbench 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

#8 lore raw

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/499aa81a68fb4c8aac1c80f0d6a4cce05941c4cc

glcompbench 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

#9 lore raw

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

[1] http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.3-release

[2] https://wiki.yoctoproject.org/wiki/FutureMigrationGuide

Signature · 2 lines
Paul Eggleton
Intel Open Source Technology Centre
#10 lore raw

Re: [PATCH 3/5] libpng12: remove the recipe

In reply to Max Krummenacher
Quoted 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.

#11 lore raw

PATCH 4/5 recipes-lsb4/perl: remove the recipes

In reply to Alexander Kanavin

These 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
index a6fb3023052..112fe7bf11d 100644
@@ -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
deleted file mode 100644
index f93841dc7f1..00000000000
@@ -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
deleted file mode 100644
index 9a7461463a8..00000000000
@@ -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
deleted file mode 100644
index dd8e1159ee5..00000000000
@@ -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
deleted file mode 100644
index ce37c72ca87..00000000000
@@ -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
deleted file mode 100644
index f1839e0cf97..00000000000
@@ -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
deleted file mode 100644
index a3e58f031ec..00000000000
@@ -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
#12 lore raw

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

#13 lore raw

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

#14 lore raw

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?

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=11316

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

#15 lore raw

PATCH 5/5 mailx: remove the recipe

In reply to Alexander Kanavin

This 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
deleted file mode 100644
index 77da33321d3..00000000000
@@ -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
deleted file mode 100644
index 13b73ae593f..00000000000
@@ -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
deleted file mode 100644
index ae14b8acfe5..00000000000
@@ -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
deleted file mode 100644
index 2b5991425bb..00000000000
@@ -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
index 112fe7bf11d..5baaf351e18 100644
@@ -153,7 +153,6 @@ RDEPENDS_packagegroup-core-lsb-core = "\
     localedef \
     lsb \
     m4 \
-    mailx \
     make \
     man \
     man-pages \
Signature · 1 line
2.11.0
#16 lore raw

✗ 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
#17 lore raw

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
#18 lore raw

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

#19 lore raw

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
#20 lore raw

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

#21 lore raw

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 more

Quoted 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

#22 lore raw

Re: ✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more

In reply to Alexander Kanavin
Quoted 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
#23 lore raw

Re: ✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more

In reply to Paul Eggleton
Quoted 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:

http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe/commit/?id=d1841aa2d19c6576d84c461656043d0b49ee689e

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,
Paul

Signature · 2 lines
Paul Eggleton
Intel Open Source Technology Centre