Confusion over my feeds directory vs what is current in github's package repo

When I build my own images, I always update the feeds prior like so:

./scripts/feeds update -a
./scripts/feeds install -a

What I am confused about is the resulting ./feeds/ does not match with what I see on the packages repo hosted on github. For example, irqbalance is at version 1.7.0 from a few weeks ago, yet the version in my ./feeds/ is at version 1.6.0.

% grep PKG_VER feeds/packages/utils/irqbalance/Makefile
PKG_VERSION:=1.6.0
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)

Is this expected? Thanks!

EDIT: deleted feeds/ and re-running those two commands pulled in the latest version. Did I miss a recommended step to insure I always have the most up-to-date content?

Feeds rely on git.openwrt.org by default, which may be out of sync with github.com.

See also: A bigger picture - #8 by vgaetera

git.openwrt.org automatically mirrors the main packages site at GitHub

No idea what happened in your local system, but both GitHub and git.openwrt.org have had irqbalance 1.7.0 in the master and 19.70 branches for the last two weeks.

Those two commands should be enough to update feeds.

2 Likes

Thanks all, I too cannot explain why the scripts didn't update. Deleting solved it. Thanks.

How often does this happen?
Are there any logs to confirm there were no errors?

Every 5 minutes, I think.

Git checksums / commit hashes pretty much ensure that git mirrors are intact.

1 Like

But, what if the mirroring process fails entirely, at least temporarily?
Both repos should pass the integrity check, however they may be out of sync.

@darksky What might happen is you have local patches on top of the OpenWrt feeds - I've seen more than once that they seem to get updated but actually break (silently, from what I recall) on your uncommitted or unstashed changes. So they never seem to get updated, until you remove local your modifications.

2 Likes

I do apply local patches, but that happens on an overlay mount back to my openwrt base directory, so the base never sees them. If you're unfamiliar with the overlayfs concept, this blog is a good read. Also see the kernel docs.

Here is more detail:
My openwrt "base" resides on a SSD in /incoming/openwrt/

  1. I cloned the git repo
  2. Grabbed the latest feeds (with ./scripts/feeds update -a and ./scripts/feeds install -a)
  3. I built my toolchain and cleaned the build env with make clean

No custom stuff (with the exception of .config. I keep that as my "base" for openwrt building. I keep it in sync with master for commits via git fetch upstream && git checkout master && git rebase upstream/master

Now for building, I use an overlay mount to this "base" dir but all the building happens on a tmpfs partition (RAM disk) so there is no I/O back to the SSD.

The tmpfs partition is mounted to /scratch/

I mount via an overkay like this:

[[ -d /scratch/.openwrt-upper ]] || mkdir /scratch/.openwrt-upper
[[ -d /scratch/.openwrt-work ]] || mkdir /scratch/.openwrt-work
[[ -d /scratch/union ]] || mkdir /scratch/union

mount -t overlay openwrt-build \
  -olowerdir=/incoming/openwrt,upperdir=/scratch/.openwrt-upper,workdir=/scratch/.openwrt-work \
  /scratch/union

So now when I go to build, I enter /scratch/union/ and apply patches, copy over my .config etc there. All the disk writes goes out to RAM (tmpfs) so it minimizes SSD wear as I said.

1 Like

maybe you need to delete tmp directory

rm -rf tmp

and run scripts/feeds update again

1 Like

You don't see the irony of assuming people here are unfamiliar with what an overlay FS is, given Linux live ISOs and OpenWrt itself have been using such systems for years?

2 Likes

No offense was intended. Just wanted to share some detail and offer something for readers finding the thread who may not know about it.

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.