Skip to contentSkip to conversation

Package upgrades

PATCH In review Denys Dmytriyenko 4 participants 12 messages Mar 20, 2018 – Mar 30, 2018

lore
Share & tools
lore
#0 lore raw

cover Package upgrades

From: Denys Dmytriyenko <[email protected]>

Upgrades for lzip, hdparm and lz4.

The following changes since commit c94271d87d16323f920891344642f76dfb3c994f:

buildperf: measure the size of core-image-sato rootfs (2018-03-16 03:42:03 -0700)

are available in the git repository at:

git://push.openembedded.org/openembedded-core-contrib denix/master

Denys Dmytriyenko (3):
lzip: upgrade 1.19 -> 1.20
hdparm: upgrade 9.53 -> 9.55
lz4: upgrade 1.7.4 -> 1.8.1.2

 .../hdparm/{hdparm_9.53.bb => hdparm_9.55.bb}      |  4 +-
 .../lzip/{lzip_1.19.bb => lzip_1.20.bb}            |  4 +-
 ...sts-Makefile-don-t-use-LIBDIR-as-variable.patch | 82 ----------------------
 .../lz4/{lz4_1.7.4.bb => lz4_1.8.1.2.bb}           | 10 +--
 4 files changed, 9 insertions(+), 91 deletions(-)
 rename meta/recipes-extended/hdparm/{hdparm_9.53.bb => hdparm_9.55.bb} (90%)
 rename meta/recipes-extended/lzip/{lzip_1.19.bb => lzip_1.20.bb} (88%)
 delete mode 100644 meta/recipes-support/lz4/files/0001-tests-Makefile-don-t-use-LIBDIR-as-variable.patch
 rename meta/recipes-support/lz4/{lz4_1.7.4.bb => lz4_1.8.1.2.bb} (79%)
Signature · 1 line
2.7.4
#1 lore raw

PATCH 1/3 lzip: upgrade 1.19 -> 1.20

From: Denys Dmytriyenko <[email protected]>

---
 meta/recipes-extended/lzip/{lzip_1.19.bb => lzip_1.20.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/lzip/{lzip_1.19.bb => lzip_1.20.bb} (88%)
meta/recipes-extended/lzip/lzip_1.20.bb renamed from meta/recipes-extended/lzip/lzip_1.19.bb +2 -2
similarity index 88%
rename from meta/recipes-extended/lzip/lzip_1.19.bb
rename to meta/recipes-extended/lzip/lzip_1.20.bb
index 099b364..d1fc2a1 100644
@@ -7,8 +7,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=76d6e300ffd8fb9d18bd9b136a9bba13 \
 
 SRC_URI = "${SAVANNAH_GNU_MIRROR}/lzip/lzip-${PV}.tar.gz"
 
-SRC_URI[md5sum] = "4dd8790d7528440d034fc713a8680bd3"
-SRC_URI[sha256sum] = "ffadc4f56be1bc0d3ae155ec4527bd003133bdc703a753b2cc683f610e646ba9"
+SRC_URI[md5sum] = "21c1517da2ace9689fd953918660b3c3"
+SRC_URI[sha256sum] = "c93b81a5a7788ef5812423d311345ba5d3bd4f5ebf1f693911e3a13553c1290c"
 
 CONFIGUREOPTS = "\
     '--srcdir=${S}' \
Signature · 1 line
2.7.4
#2 lore raw

PATCH 2/3 hdparm: upgrade 9.53 -> 9.55

In reply to Denys Dmytriyenko

From: Denys Dmytriyenko <[email protected]>

---
 meta/recipes-extended/hdparm/{hdparm_9.53.bb => hdparm_9.55.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/hdparm/{hdparm_9.53.bb => hdparm_9.55.bb} (90%)
meta/recipes-extended/hdparm/hdparm_9.55.bb renamed from meta/recipes-extended/hdparm/hdparm_9.53.bb +2 -2
similarity index 90%
rename from meta/recipes-extended/hdparm/hdparm_9.53.bb
rename to meta/recipes-extended/hdparm/hdparm_9.55.bb
index 4c3ec5c..c50e73f 100644
@@ -25,8 +25,8 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/hdparm/${BP}.tar.gz \
            file://wiper.sh-fix-stat-path.patch \
           "
 
-SRC_URI[md5sum] = "1e54b52e0c8cb79389d4d47eacba411d"
-SRC_URI[sha256sum] = "2673f591df6916c6a1faec07069a7eb1cb8ee307615a615d808192fb0c0265e5"
+SRC_URI[md5sum] = "adae46e9564075ae288af8082d5ad9fd"
+SRC_URI[sha256sum] = "b5c76b732483df36bf08001a209b95b45558016615f935008e5ea91a7fde6dc7"
 
 EXTRA_OEMAKE = 'STRIP="echo" LDFLAGS="${LDFLAGS}"'
 
Signature · 1 line
2.7.4
#3 lore raw

PATCH 3/3 lz4: upgrade 1.7.4 -> 1.8.1.2

In reply to Denys Dmytriyenko

From: Denys Dmytriyenko <[email protected]>

0001-tests-Makefile-don-t-use-LIBDIR-as-variable.patch accepted upstream.

License-Update: rephrased clarification regarding lib/ vs. programs/, tests/ and examples/
https://github.com/lz4/lz4/commit/97df1c9789cbc8a7891cadbd49ea5053574e2f72

---
 ...sts-Makefile-don-t-use-LIBDIR-as-variable.patch | 82 ----------------------
 .../lz4/{lz4_1.7.4.bb => lz4_1.8.1.2.bb}           | 10 +--
 2 files changed, 5 insertions(+), 87 deletions(-)
 delete mode 100644 meta/recipes-support/lz4/files/0001-tests-Makefile-don-t-use-LIBDIR-as-variable.patch
 rename meta/recipes-support/lz4/{lz4_1.7.4.bb => lz4_1.8.1.2.bb} (79%)
meta/recipes-support/lz4/files/0001-tests-Makefile-don-t-use-LIBDIR-as-variable.patch deleted +0 -82
deleted file mode 100644
index 00494e8..0000000
@@ -1,82 +0,0 @@
-From d4768d9e29b805096a86aa13c0d30ee8215af4df Mon Sep 17 00:00:00 2001
-From: Jussi Kukkonen <[email protected]>
-Date: Mon, 26 Jun 2017 12:07:09 +0300
-Subject: [PATCH] tests/Makefile: don't use LIBDIR as variable
-
-LIBDIR may be overriden with a environment variable: In this case make
-clean breaks. Use another variable name.
-
-Signed-off-by: Jussi Kukkonen <[email protected]>
-Upstream-Status: Backport
----
- tests/Makefile | 26 +++++++++++++-------------
- 1 file changed, 13 insertions(+), 13 deletions(-)
-
-diff --git a/tests/Makefile b/tests/Makefile
-index 97fa782..51dd038 100644
---- a/tests/Makefile
-+++ b/tests/Makefile
-@@ -32,7 +32,7 @@ DESTDIR ?=
- PREFIX  ?= /usr/local
- BINDIR  := $(PREFIX)/bin
- MANDIR  := $(PREFIX)/share/man/man1
--LIBDIR  := ../lib
-+LZ4DIR  := ../lib
- PRGDIR  := ../programs
- VOID    := /dev/null
- TESTDIR := versionsTest
-@@ -43,7 +43,7 @@ CFLAGS  += -g -Wall -Wextra -Wundef -Wcast-qual -Wcast-align -Wshadow -Wswitch-e
-            -Wdeclaration-after-statement -Wstrict-prototypes \
-            -Wpointer-arith -Wstrict-aliasing=1
- CFLAGS  += $(MOREFLAGS)
--CPPFLAGS:= -I$(LIBDIR) -I$(PRGDIR) -DXXH_NAMESPACE=LZ4_
-+CPPFLAGS:= -I$(LZ4DIR) -I$(PRGDIR) -DXXH_NAMESPACE=LZ4_
- FLAGS    = $(CFLAGS) $(CPPFLAGS) $(LDFLAGS)
- 
- 
-@@ -79,31 +79,31 @@ lz4c32:   # create a 32-bits version for 32/64 interop tests
- 	$(MAKE) -C $(PRGDIR) clean $@ CFLAGS="-m32 $(CFLAGS)"
- 	cp $(LZ4) $(LZ4)c32
- 
--fullbench  : $(LIBDIR)/lz4.o $(LIBDIR)/lz4hc.o $(LIBDIR)/lz4frame.o $(LIBDIR)/xxhash.o fullbench.c
-+fullbench  : $(LZ4DIR)/lz4.o $(LZ4DIR)/lz4hc.o $(LZ4DIR)/lz4frame.o $(LZ4DIR)/xxhash.o fullbench.c
- 	$(CC) $(FLAGS) $^ -o $@$(EXT)
- 
--fullbench-lib: fullbench.c $(LIBDIR)/xxhash.c
--	$(MAKE) -C $(LIBDIR) liblz4.a
--	$(CC) $(FLAGS) $^ -o $@$(EXT) $(LIBDIR)/liblz4.a
-+fullbench-lib: fullbench.c $(LZ4DIR)/xxhash.c
-+	$(MAKE) -C $(LZ4DIR) liblz4.a
-+	$(CC) $(FLAGS) $^ -o $@$(EXT) $(LZ4DIR)/liblz4.a
- 
--fullbench-dll: fullbench.c $(LIBDIR)/xxhash.c
--	$(MAKE) -C $(LIBDIR) liblz4
--	$(CC) $(FLAGS) $^ -o $@$(EXT) -DLZ4_DLL_IMPORT=1 $(LIBDIR)/dll/liblz4.dll
-+fullbench-dll: fullbench.c $(LZ4DIR)/xxhash.c
-+	$(MAKE) -C $(LZ4DIR) liblz4
-+	$(CC) $(FLAGS) $^ -o $@$(EXT) -DLZ4_DLL_IMPORT=1 $(LZ4DIR)/dll/liblz4.dll
- 
--fuzzer  : $(LIBDIR)/lz4.o $(LIBDIR)/lz4hc.o $(LIBDIR)/xxhash.o fuzzer.c
-+fuzzer  : $(LZ4DIR)/lz4.o $(LZ4DIR)/lz4hc.o $(LZ4DIR)/xxhash.o fuzzer.c
- 	$(CC) $(FLAGS) $^ -o $@$(EXT)
- 
--frametest: $(LIBDIR)/lz4frame.o $(LIBDIR)/lz4.o $(LIBDIR)/lz4hc.o $(LIBDIR)/xxhash.o frametest.c
-+frametest: $(LZ4DIR)/lz4frame.o $(LZ4DIR)/lz4.o $(LZ4DIR)/lz4hc.o $(LZ4DIR)/xxhash.o frametest.c
- 	$(CC) $(FLAGS) $^ -o $@$(EXT)
- 
--fasttest: $(LIBDIR)/lz4.o fasttest.c
-+fasttest: $(LZ4DIR)/lz4.o fasttest.c
- 	$(CC) $(FLAGS) $^ -o $@$(EXT)
- 
- datagen : $(PRGDIR)/datagen.c datagencli.c
- 	$(CC) $(FLAGS) -I$(PRGDIR) $^ -o $@$(EXT)
- 
- clean:
--	@$(MAKE) -C $(LIBDIR) $@ > $(VOID)
-+	@$(MAKE) -C $(LZ4DIR) $@ > $(VOID)
- 	@$(MAKE) -C $(PRGDIR) $@ > $(VOID)
- 	@$(RM) core *.o *.test tmp* \
-         fullbench-dll$(EXT) fullbench-lib$(EXT) \
--- 
-2.1.4
-
meta/recipes-support/lz4/lz4_1.8.1.2.bb renamed from meta/recipes-support/lz4/lz4_1.7.4.bb +5 -5
similarity index 79%
rename from meta/recipes-support/lz4/lz4_1.7.4.bb
rename to meta/recipes-support/lz4/lz4_1.8.1.2.bb
index 86a1ab9..03017b3 100644
@@ -2,18 +2,18 @@ SUMMARY = "Extremely Fast Compression algorithm"
 DESCRIPTION = "LZ4 is a very fast lossless compression algorithm, providing compression speed at 400 MB/s per core, scalable with multi-cores CPU. It also features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems."
 
 LICENSE = "BSD | BSD-2-Clause | GPL-2.0"
-LIC_FILES_CHKSUM = "file://lib/LICENSE;md5=ebc2ea4814a64de7708f1571904b32cc\
+LIC_FILES_CHKSUM = "file://lib/LICENSE;md5=ebc2ea4814a64de7708f1571904b32cc \
                     file://programs/COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
-                    file://LICENSE;md5=7f2857d58beff6d04137bf9b09e5ffb6"
+                    file://LICENSE;md5=d57c0d21cb917fb4e0af2454aa48b956 \
+                    "
 
 PE = "1"
 
-SRCREV = "7bb64ff2b69a9f8367de9ab483cdadf42b4c1b65"
+SRCREV = "dfed9fa1d77f0434306d377c4da1f7191d3ba08a"
 
 SRC_URI = "git://github.com/lz4/lz4.git \
-           file://0001-tests-Makefile-don-t-use-LIBDIR-as-variable.patch \
            file://run-ptest \
-"
+           "
 UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>.*)"
 
 S = "${WORKDIR}/git"
Signature · 1 line
2.7.4
#4 lore raw
In reply to Denys Dmytriyenko

Ping. It's been 10 days - are there any issues with these updates?

Quoted 35 lines · Denys Dmytriyenko

From: Denys Dmytriyenko <[email protected]>

Upgrades for lzip, hdparm and lz4.

The following changes since commit c94271d87d16323f920891344642f76dfb3c994f:

buildperf: measure the size of core-image-sato rootfs (2018-03-16 03:42:03 -0700)

are available in the git repository at:

git://push.openembedded.org/openembedded-core-contrib denix/master

Denys Dmytriyenko (3):
lzip: upgrade 1.19 -> 1.20
hdparm: upgrade 9.53 -> 9.55
lz4: upgrade 1.7.4 -> 1.8.1.2

 .../hdparm/{hdparm_9.53.bb => hdparm_9.55.bb}      |  4 +-
 .../lzip/{lzip_1.19.bb => lzip_1.20.bb}            |  4 +-
 ...sts-Makefile-don-t-use-LIBDIR-as-variable.patch | 82 ----------------------
 .../lz4/{lz4_1.7.4.bb => lz4_1.8.1.2.bb}           | 10 +--
 4 files changed, 9 insertions(+), 91 deletions(-)
 rename meta/recipes-extended/hdparm/{hdparm_9.53.bb => hdparm_9.55.bb} (90%)
 rename meta/recipes-extended/lzip/{lzip_1.19.bb => lzip_1.20.bb} (88%)
 delete mode 100644 meta/recipes-support/lz4/files/0001-tests-Makefile-don-t-use-LIBDIR-as-variable.patch
 rename meta/recipes-support/lz4/{lz4_1.7.4.bb => lz4_1.8.1.2.bb} (79%)
Signature · 7 lines
2.7.4

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
#5 lore raw
Quoted 1 line · Denys Dmytriyenko

Ping. It's been 10 days - are there any issues with these updates?

Only 10 days? :-)

#6 lore raw
Quoted 4 lines · Andre McCurdy
Quoted 1 line · Denys Dmytriyenko

Ping. It's been 10 days - are there any issues with these updates?

Only 10 days? :-)

Yeah, I know, I'm too demanding... :)

Signature · 1 line
Denys
#7 lore raw
Quoted 7 lines · Denys Dmytriyenko
Quoted 4 lines · Andre McCurdy
Quoted 1 line · Denys Dmytriyenko

Ping. It's been 10 days - are there any issues with these updates?

Only 10 days? :-)

Yeah, I know, I'm too demanding... :)

Ross does pick the patches from ml fairly quickly so always check

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/mut

or OE-Core's master-next

http://git.openembedded.org/openembedded-core/log/?h=master-next

from mut to master it might take a while since there are many patches coming in so integration takes time and sometimes there are issues with infra which can delay
things,

10 days seems pretty darn good in some cases its years see

https://github.com/projectNe10/Ne10/pull/143

in the end as long as it makes upstream.

#8 lore raw
Quoted 13 lines · Khem Raj
Quoted 7 lines · Denys Dmytriyenko
Quoted 4 lines · Andre McCurdy
Quoted 1 line · Denys Dmytriyenko

Ping. It's been 10 days - are there any issues with these updates?

Only 10 days? :-)

Yeah, I know, I'm too demanding... :)

Ross does pick the patches from ml fairly quickly so always check

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/mut

Quoted 8 lines

or OE-Core's master-next

http://git.openembedded.org/openembedded-core/log/?h=master-next

from mut to master it might take a while since there are many patches coming in so integration takes time and sometimes there are issues with infra which can delay
things,

Yes, I'm quite aware of all the above - you don't have to mention all the details to me. Still, it's a standard practice to inquire about own patches once in a while. Especially since other similar non-critical updates are merged right away. This is the only way to know if there were any issues with the patches themselves, but Ross forgot or didn't have time to follow up yet.

Quoted 5 lines

10 days seems pretty darn good in some cases its years see

https://github.com/projectNe10/Ne10/pull/143

in the end as long as it makes upstream.

Heh, I don't think we should take that as an example to follow... :)

Signature · 1 line
Denys
#9 lore raw
Quoted 18 lines · Denys Dmytriyenko
Quoted 17 lines · Khem Raj
Quoted 7 lines · Denys Dmytriyenko
Quoted 4 lines · Andre McCurdy
Quoted 1 line · Denys Dmytriyenko

Ping. It's been 10 days - are there any issues with these updates?

Only 10 days? :-)

Yeah, I know, I'm too demanding... :)

Ross does pick the patches from ml fairly quickly so always check

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/mut

or OE-Core's master-next

http://git.openembedded.org/openembedded-core/log/?h=master-next

Quoted 7 lines
Quoted 4 lines

from mut to master it might take a while since there are many patches coming in so integration takes time and sometimes there are issues with infra which can delay
things,

Yes, I'm quite aware of all the above - you don't have to mention all the details to me.

I am glad thats the case. It was not clear from the message and some times this can be misconstrued.

Still, it's a standard practice to inquire about own patches

Quoted 13 lines

once in a while. Especially since other similar non-critical updates are merged right away. This is the only way to know if there were any issues with the patches themselves, but Ross forgot or didn't have time to follow up yet.

Quoted 5 lines

10 days seems pretty darn good in some cases its years see

https://github.com/projectNe10/Ne10/pull/143

in the end as long as it makes upstream.

Heh, I don't think we should take that as an example to follow... :)

#10 lore raw
Quoted 24 lines · Khem Raj
Quoted 23 lines · Denys Dmytriyenko
Quoted 21 lines · Khem Raj
Quoted 7 lines · Denys Dmytriyenko
Quoted 4 lines · Andre McCurdy
Quoted 1 line · Denys Dmytriyenko

Ping. It's been 10 days - are there any issues with these updates?

Only 10 days? :-)

Yeah, I know, I'm too demanding... :)

Ross does pick the patches from ml fairly quickly so always check

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/mut

or OE-Core's master-next

http://git.openembedded.org/openembedded-core/log/?h=master-next

from mut to master it might take a while since there are many patches coming in so integration takes time and sometimes there are issues with infra which can delay
things,

Quoted 5 lines
Quoted 2 lines

Yes, I'm quite aware of all the above - you don't have to mention all the details to me.

I am glad thats the case. It was not clear from the message and some times this can be misconstrued.

You are absolutely right! After 10+ years in the OE community my mind and memory are not as sharp as they used to be - I keep forgetting things and do not communicate as clearly as before... :-P

Quoted 15 lines

Still, it's a standard practice to inquire about own patches

Quoted 13 lines

once in a while. Especially since other similar non-critical updates are merged right away. This is the only way to know if there were any issues with the patches themselves, but Ross forgot or didn't have time to follow up yet.

Quoted 5 lines

10 days seems pretty darn good in some cases its years see

https://github.com/projectNe10/Ne10/pull/143

in the end as long as it makes upstream.

Heh, I don't think we should take that as an example to follow... :)

#11 lore raw
In reply to Denys Dmytriyenko
Quoted 1 line · Denys Dmytriyenko

Ping. It's been 10 days - are there any issues with these updates?

We're past feature freeze at this point and M3 was built (finally, and late). During stabilisation we're only taking upgrades "with a good reason". Security fixes, bug fixes and issues with maintenance windows (e.g. bind) are reasons we might see some upgrades going in now but in general we're holding upgrades until 2.6 opens.

I think Ross has a "post sumo" branch which he may pull some of these into but I'd really like people to focus on bug fixing for sumo right now.

Ross is also on vacation so I'll be handling things over the next week or so (when do I get one?!). I might push a master-next-2.6 to queue things just to make it clearer what is being deferred. Rebasing can be a nightmare though.

Cheers,

Richard