[LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency

Wed Mar 29 03:42:33 PDT 2017

On Wed, Mar 29, 2017 at 05:28:07AM +0200, Pau wrote:
> On 29/03/17 02:45, Daniel Golle wrote:
> > On Tue, Mar 28, 2017 at 10:55:09PM +0200, Pau wrote:
> >> Hi Daniel, thanks for your reply. Find my comments in-line.
> >>
> >> On 28/03/17 22:37, Daniel Golle wrote:
> >>> Hi Pau,
> >>>
> >>> On Tue, Mar 28, 2017 at 09:28:22PM +0200, Pau wrote:
> >>>> Hi.
> >>>>
> >>>> I am using the SDK and IB from LEDE 17.01.0 release (mips_24kc). I've
> >>>> been using it successfully the last days until now. I did not change
> >>>> anything but I get the error:
> >>>>
> >>>> * opkg_install_pkg: Package luci-lib-nixio sha256sum mismatch. Either
> >>>> the opkg or the package index are corrupt. Try 'opkg update'.
> >>>>
> >>>> Then I went to downloads.lede-project.org [1] and I see that there are
> >>>> new compiled packages with date "Tue Mar 28 18:35:15 2017".
> >>>> Luci-lib-nixio is one of them [2] (which now is published on the
> >>>> repository with a new version).
> >>>
> >>> Packages from the feeds and even base-packages (think: openssl) can
> >>> change after a release, just like for other distributions.
> >>> The error message you see more looks like being caused by inconsistent
> >>> Package index not matching the actual binaries. Maybe regenerating
> >>> the index can fix that...?
> >>
> >> I know I can manually fix it. But let me explain my corner case:
> >>
> >> The current SDK is compiling luci-lib-nixio which I want to include to
> >> the firmware generated by the ImageBuilder (I want to include my local
> >> version, not the repository one).
> > 
> > Ok, now I understand better. So the package index of the binary feed
> > is consistent.
> > 
> >>
> >> The source of this package comes from the SDK's feeds.conf.default which
> >> points to commit "a100738163585ae1edc24d832ca9bef1f34beef0".
> >>
> >> As the current LEDE official repository for 17.01.0 has been updated the
> >> luci-lib-nixio package has a newer version. In consequence the
> >> ImageBuilder selects it instead of my local compiled package.
> > 
> > I get that problem, and it can be solved easily by removing the git
> > commit hash from feeds.conf in the SDK and rather use the current
> > snapshot instead.
> > I agree that the lack of a lede-17.01 release branch on the package
> > feeds may cause weird and problematic situations, especially in the
> > future once LEDE HEAD has diverged more from 17.01.x released versions.
> 
> Sure, it is what I did. But I liked the idea of sticking and trusting
> the official feeds.conf.default included in the SDK.

I just realize that a lede-17.01 branch has been created for
openwrt/packages.git, openwrt/luci.git, openwrt/telephony.git and
openwrt-routing/packhages.git, just openwrt-management/packages.git
seems to lack a lede-17.01 release branch.

> 
> >>
> >> So it is an unexpected behavior, and it makes impossible for us to be
> >> sure that our LibreMesh SDK will work, not even when sticking to a LEDE
> >> release.
> > 
> > I fail to see the drama, why would that truely prevent you from doing
> > anything? What is the behaviour you'd expect?
> 
> The drama is that I've been following OpenWRT (and now LEDE) for so many
> years and stability is not (¿yet?) a word that I would use to describe it.
> 
> As you already know in the past we were freezing the OpenWRT buildroot
> so we were 100% sure that we were producing always the same release
> firmware (which was kind of deeply tested by us). Now (in 2017) I'd like
> to trust on LEDE releases and be sure that no new bugs are introduced.
> But two months after (not even) the public announcement of 17.01.0 I see
> new versions entering into the release official packages. We cannot be
> testing all this stuff all the time... it's a long process.

As with every release, those updates (to the respective lede-17.01
branch) should be bug- and security-fixes only and should never break
compatibility of depending packages.
If that's still too much movement, you can bake your own package builds
and use those in the ImageBuilder by editing repositories.conf instead
of using the upstream ones.

> 
> So it is not an actual drama but I am a bit afraid. I'm really happy
> with the evolution of OpenWRT and now LEDE (mainly since AA) but still I
> need to see with my own eyes that a release is truly stable and
> seriously taken.
> 
> >>
> >> In this case luci.lib-nixio is not a critical package and we can use the
> >> vanilla one, but the same might happen with any other package that we
> >> are compiling with different options and we expect the IB to use it
> >> instead of the online one.
> > 
> > Ok, all this is expected behaviour and shouldn't prevent anyone from
> > building their packages using the SDK and then including their binaries
> > in the ImageBuilder.
> > 
> > Simply speaking, if you modify (ie. fork) a package you should either
> > rename it or pull-request your changes upstream.
> 
> Not all changes can be always pull-requested**. Of course we have to
> walk on the direction to not diverge from mainstream decisions but it
> takes time until we adapt our stuff. Things are going fast on LEDE.
> 
> Renaming packages is something I would like to avoid but of course it is
> what we will do for the moment (we already considered this possibility).
> 
> ** For instance compat-wireless and regdb.txt modifications...
** which are quite problematic and I still haven't understood the need
for that.

> ** For ALFRED we need "enable autogeneration of /etc/bat-hosts" enbled
> ** We need POSIX MQUEUE enabled for WbeSockets and Lighttpd

That's the old package configuration (=bad) vs. build variants (=good)
debate. The problem is kinda that we would have
2^(nr.of-boolean-configurations) package build variants or skip certain
combinations and have -mini, -default and -full variants.

> ** We need busybox+SHA1 (I know it's horrible, but it will be only until
> we change to SHA256 or drop Orange-RPCd, I hope very soon)

I also hope for that :)

> 
> > 
> >>
> >>>>
> >>>> In the other hand the feeds.conf.default file included in the release
> >>>> SDK points to the specific commit
> >>>> a100738163585ae1edc24d832ca9bef1f34beef0 from  Sat Jan 28 01:38:06 2017.
> >>>> The SDK published then is not consistent with the current package binary
> >>>> repositories.
> >>>
> >>> The SDK doesn't need to be consistent with all packages, but the fixed
> >>> commit (instead of a branch) is indeed misleading (and most likely got
> >>> rather political reasons, like not poluting a repo called
> >>> github.com/openwrt/packages with a branch called for-lede-17.01...)
> >>>
> >>>>
> >>>> So my question here is: what's the point for publishing a Release if the
> >>>> packages included are changing? Is this the expected behavior?
> >>>
> >>> Definitely not the expected behaviour, but packages may and should
> >>> change, eg. for bug or security fixes.
> >>
> >> IMHO and as far I understand the concept of Release, if there are fixes
> >> a new revision must be published instead of modifying the current one
> >> (i.e 17.01.1). Once a release is published it is expected to be always
> >> the same.
> > 
> > Why is that? And when has it ever been like that?
> > Binary packages have also been updated for past OpenWrt releases,
> > especially but not exclusively to fix security issues. (e.g. HeartBleed
> > was fixed in binary packages all the way back to 12.09 afaik)
> 
> Somehow I thought it was the idea behind LEDE releases but it seems that
> I was wrong.
> 
> So the only thing I really expect now is that the SDK is consistent with
> the current state of the release.
> 
> > 
> >>
> >>>
> >>> Cheers
> >>>
> >>>
> >>> Daniel
> 
> Thanks and cheers.
> 
> >>>>
> >>>> Thanks.
> >>>>
> >>>> [1]
> >>>> https://downloads.lede-project.org/releases/17.01.0/packages/mipsel_24kc/
> >>>> [2]
> >>>> https://downloads.lede-project.org/releases/17.01.0/packages/mips_24kc/luci/luci-lib-nixio_git-17.073.42825-b47a21f-1_mips_24kc.ipk
> >>>>
> >>>> -- 
> >>>> ./p4u
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>> _______________________________________________
> >>>> Lede-dev mailing list
> >>>> Lede-dev at lists.infradead.org
> >>>> http://lists.infradead.org/mailman/listinfo/lede-dev
> >>>
> >>
> >> -- 
> >> ./p4u
> >>
> > 
> > 
> > 
> > 
> >> _______________________________________________
> >> Lede-dev mailing list
> >> Lede-dev at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/lede-dev
> > 
> 
> -- 
> ./p4u
> 