[PATCH 1/2] binutils: drop UPSTREAM_VERSION_UNKNOWN

[PATCH 1/2] binutils: drop UPSTREAM_VERSION_UNKNOWN

[Alexander Kanavin]

As there is now a new version of binutils,
upstream version check works again.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/recipes-devtools/binutils/binutils-2.32.inc | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc b/meta/recipes-devtools/binutils/binutils-2.32.inc
index d3c52936d16..19baf8a8839 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -14,11 +14,8 @@ def binutils_branch_version(d):
     pvsplit = d.getVar('PV').split('.')
     return pvsplit[0] + "_" + pvsplit[1]
 
-# Actual upstream version is 2.32 (without the .0), so we have to set
-# UPSTREAM_VERSION_UNKNOWN to avoid the version check failure. The line can
-# be removed when a new version of binutils is released (if the PV is then
-# correctly set to match the upstream version tag).
-UPSTREAM_VERSION_UNKNOWN = "1"
+# When upgrading to 2.33, please make sure there is no trailing .0, so
+# that upstream version check can work correctly.
 PV = "2.32.0"
 CVE_VERSION = "2.32"
 BINUPV = "${@binutils_branch_version(d)}"
-- 
2.17.1

[PATCH 2/2] ethtool, libcap: fix upstream version check

[Alexander Kanavin]

The default URI returns a gzip-compressed index page
which browsers can auto-detect, but we can't.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/recipes-extended/ethtool/ethtool_5.2.bb | 2 ++
 meta/recipes-support/libcap/libcap_2.27.bb   | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/meta/recipes-extended/ethtool/ethtool_5.2.bb b/meta/recipes-extended/ethtool/ethtool_5.2.bb
index e9759bd21bd..67e7fadee0c 100644
--- a/meta/recipes-extended/ethtool/ethtool_5.2.bb
+++ b/meta/recipes-extended/ethtool/ethtool_5.2.bb
@@ -14,6 +14,8 @@ SRC_URI = "${KERNELORG_MIRROR}/software/network/ethtool/ethtool-${PV}.tar.gz \
 SRC_URI[md5sum] = "79cff0d4af62b030ad28be90414b5c4a"
 SRC_URI[sha256sum] = "8ad6cb30f6e1767d9d23a5cb5f606f3b51f83e85ebf0153c1506194f6709e90b"
 
+UPSTREAM_CHECK_URI = "https://www.kernel.org/pub/software/network/ethtool/"
+
 inherit autotools ptest bash-completion
 
 RDEPENDS_${PN}-ptest += "make"
diff --git a/meta/recipes-support/libcap/libcap_2.27.bb b/meta/recipes-support/libcap/libcap_2.27.bb
index 4f3bac84909..3f64ff76364 100644
--- a/meta/recipes-support/libcap/libcap_2.27.bb
+++ b/meta/recipes-support/libcap/libcap_2.27.bb
@@ -13,6 +13,8 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/libs/security/linux-privs/${BPN}2/${BPN}-${
 SRC_URI[md5sum] = "2e8f9fab32eb5ccb37969fe317fd17aa"
 SRC_URI[sha256sum] = "dac1792d0118bee6aae6ba7fb93ff1602c6a9bda812fd63916eee1435b9c486a"
 
+UPSTREAM_CHECK_URI = "https://www.kernel.org/pub/linux/libs/security/linux-privs/${BPN}2/"
+
 inherit lib_package
 
 # do NOT pass target cflags to host compilations
-- 
2.17.1

Re: [PATCH 2/2] ethtool, libcap: fix upstream version check

[Adrian Bunk]

On Wed, Oct 02, 2019 at 02:00:27PM +0200, Alexander Kanavin wrote:
> The default URI returns a gzip-compressed index page
> which browsers can auto-detect, but we can't.
>...

Works for me without your patch:

$ devtool check-upgrade-status ethtool 
NOTE: Starting bitbake server...
NOTE: Reconnecting to bitbake server...
NOTE: Retrying server connection (#1)...
Loading cache: 100% |###########################################################################################################################################################################################################| Time: 0:00:00
Loaded 3386 entries from dependency cache.
--2019-10-02 20:48:43--  https://cdn.kernel.org/pub/software/network/ethtool/
Resolving cdn.kernel.org (cdn.kernel.org)... 151.101.245.176, 2a04:4e42:3a::432
Connecting to cdn.kernel.org (cdn.kernel.org)|151.101.245.176|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12157 (12K) [text/html]
Saving to: ‘/tmp/wget-index-68s3yqp8/wget-listing-0s5soh5t’


2019-10-02 20:48:43 (4.08 MB/s) - ‘/tmp/wget-index-68s3yqp8/wget-listing-0s5soh5t’ saved [12157/12157]

INFO: ethtool                   5.2             5.3             Changhyeok Bae <changhyeok.bae@gmail.com>  
$ 

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 2/2] ethtool, libcap: fix upstream version check

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 205 bytes --]

On Wed, 2 Oct 2019 at 19:51, Adrian Bunk <bunk@stusta.de> wrote:

> Works for me without your patch:
>

I am not sure what this may mean; but for me the patch definitely solves
the problem.

Alex

[-- Attachment #2: Type: text/html, Size: 549 bytes --]

Re: [PATCH 2/2] ethtool, libcap: fix upstream version check

[Adrian Bunk]

On Wed, Oct 02, 2019 at 08:08:08PM +0200, Alexander Kanavin wrote:
> On Wed, 2 Oct 2019 at 19:51, Adrian Bunk <bunk@stusta.de> wrote:
> 
> > Works for me without your patch:
> 
> I am not sure what this may mean; but for me the patch definitely solves
> the problem.

It means that even without your patch devtool is able to tell me that 
there is a new upstream version of ethtool available.

I was originally wondering whether there is a problem that also affects 
other users of KERNELORG_MIRROR, and was then surprised that it worked 
for me without the change the way I tried.

How are you reproducing the problem?

> Alex

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 2/2] ethtool, libcap: fix upstream version check

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

On Wed, 2 Oct 2019 at 20:18, Adrian Bunk <bunk@stusta.de> wrote:

> On Wed, Oct 02, 2019 at 08:08:08PM +0200, Alexander Kanavin wrote:
> > On Wed, 2 Oct 2019 at 19:51, Adrian Bunk <bunk@stusta.de> wrote:
> >
> > > Works for me without your patch:
> >
> > I am not sure what this may mean; but for me the patch definitely solves
> > the problem.
>
> It means that even without your patch devtool is able to tell me that
> there is a new upstream version of ethtool available.
>
> I was originally wondering whether there is a problem that also affects
> other users of KERNELORG_MIRROR, and was then surprised that it worked
> for me without the change the way I tried.
>
> How are you reproducing the problem?
>

The same way. I am getting the following on my home computer and on both of
my work computers (which are on two different networks). Note the IP
address is different, and the file size is smaller, as it's gzip-compressed:

ak@linux-f9zs:~/development/poky/build> devtool check-upgrade-status ethtool
NOTE: Starting bitbake server...
NOTE: Reconnecting to bitbake server...
NOTE: Retrying server connection (#1)...
NOTE: Reconnecting to bitbake server...
NOTE: Previous bitbake instance shutting down?, waiting to retry...
NOTE: Retrying server connection (#2)...
Loading cache: 100%
|#####################################################################################################################################################################################################|
Time: 0:00:00
Loaded 1301 entries from dependency cache.
--2019-10-02 20:25:30--
https://cdn.kernel.org/pub/software/network/ethtool/
Resolving cdn.kernel.org (cdn.kernel.org)... 151.101.113.176
Connecting to cdn.kernel.org (cdn.kernel.org)|151.101.113.176|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 2155 (2.1K) [text/html]
Saving to: ‘/tmp/wget-index-l2jg_z9r/wget-listing-mo7c995y’


2019-10-02 20:25:30 (89.5 MB/s) -
‘/tmp/wget-index-l2jg_z9r/wget-listing-mo7c995y’ saved [2155/2155]

WARNING:root:Some characters could not be decoded, and were replaced with
REPLACEMENT CHARACTER.
INFO: ethtool                   5.2             UNKNOWN_BROKEN  Changhyeok
Bae <changhyeok.bae@gmail.com>

Alex

[-- Attachment #2: Type: text/html, Size: 3084 bytes --]

Re: [PATCH 2/2] ethtool, libcap: fix upstream version check

[Adrian Bunk]

On Wed, Oct 02, 2019 at 08:27:55PM +0200, Alexander Kanavin wrote:
> On Wed, 2 Oct 2019 at 20:18, Adrian Bunk <bunk@stusta.de> wrote:
> 
> > On Wed, Oct 02, 2019 at 08:08:08PM +0200, Alexander Kanavin wrote:
> > > On Wed, 2 Oct 2019 at 19:51, Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > > Works for me without your patch:
> > >
> > > I am not sure what this may mean; but for me the patch definitely solves
> > > the problem.
> >
> > It means that even without your patch devtool is able to tell me that
> > there is a new upstream version of ethtool available.
> >
> > I was originally wondering whether there is a problem that also affects
> > other users of KERNELORG_MIRROR, and was then surprised that it worked
> > for me without the change the way I tried.
> >
> > How are you reproducing the problem?
> 
> The same way. I am getting the following on my home computer and on both of
> my work computers (which are on two different networks). Note the IP
> address is different, and the file size is smaller, as it's gzip-compressed:
>...

I am able to reproduce your problem from a machine located elsewhere, 
and there is no difference in the headers sent that can change the 
behaviour to either make both work or both break.

My guess would be that this is a temporary problem on some part of the
Fastly network,
  wget --debug http://www.kernel.org/pub/software/network/ethtool/
says the cache that is broken for me is HHN in Frankfurt:
  Content-Encoding: gzip
  X-Served-By: cache-hhn4065-HHN

I'd be surprised if this affects only 2 recipes, the big hammer would be
  -KERNELORG_MIRROR = "https://cdn.kernel.org/pub"
  +KERNELORG_MIRROR = "https://www.kernel.org/pub"

But so far it looks to me that it might only be a temporary hiccup 
(and affecting only functionality not usually used by users).

I sent an email to Fastly support, let's see if they will answer.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 2/2] ethtool, libcap: fix upstream version check

[Adrian Bunk]

On Wed, Oct 02, 2019 at 11:20:01PM +0300, Adrian Bunk wrote:
>...
> I sent an email to Fastly support, let's see if they will answer.

This is something that has to be fixed at the kernel.org side (see [1]),
my ticket for that is Linux Foundation RT #80134.

cu
Adrian

[1] https://www.fastly.com/blog/best-practices-using-vary-header

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed