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

Tue Mar 28 20:28:07 PDT 2017

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.

>>
>> 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.

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...
** For ALFRED we need "enable autogeneration of /etc/bat-hosts" enbled
** We need POSIX MQUEUE enabled for WbeSockets and Lighttpd
** 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)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20170329/4a0a652e/attachment.sig>