I am motivated to rant again on this topic. Repeating what I said last
November, before the new release process was finalized, in response to
David Lang:
---
>> There is an interesting question of how to refer to what state of each feed
>> you use for a release. Currently OpenWRT doesn't even tr
Hi Daniel
> Well, this was actually fixed by having a specific snapshot of all
> feeds referenced in the SDK. Which is exactly the cause of all the
> confusion now...
> ...
>>> ... It would mean that every build was repeatable.
>
> Every build of what exactly?
> Do you realise that *none* of the p
Hi Alberto
> Also the kernel is handled like a package for the build system, but
> since most devices expect it outside of root filesystem in various ways,
> it's added to the firmware image the way the device's bootloader expects it.
I haven't seen a preferred term for the class of this combined
On 11/01/2017 12:15 PM, Hannu Nyman wrote:
> At the first glance LEDE r5217-098afa1e1b compiled with 1.1.18 booted ok and
> got normally a DHCP wan address, hostapd started etc..
Excuse me what?! "LEDE r5217-098afa1e1b"?
Why does that look like a "release 5217" and a SHA prefix "098afa1e1b"?
So
On the topic of version numbers of the form "LEDE r5217-098afa1e1b" about which
I am clueless, there is some discussion about the challenge of relating git
hash numbers and "release" version numbers:
Point releases for the GNU C Library
October 16, 2017
https://lwn.net/Articles/736429/#Comments
On 11/06/2017 09:01 AM, David Lang wrote:
> These version numbers are used between releases, the part after the - is
> enough of the git commit id (it's hash) for you to identify it. The r# gives
> you an idea if it's newer or older than another one (since git hashes don't
> give you that info)
On 11/06/2017 11:44 PM, Matthias Schiffer wrote:
> r# is the number of commits since the "reboot" tag. If your local branch
> (e.g. "master") has a upstream branch (e.g. "origin/master"), it will use
> number and commit ID of the last common commit of both branches, and add
> the number of local co
On 11/07/2017 07:43 AM, Matthias Schiffer wrote:
> No, we have two official branches: master (active development for the next
> major release), and lede-17.01 (forked from master shortly before the 17.01
> release; only bugfixes and other "small" changes are backported from
> master; base for 17.01
What are thoughts about backporting the DirtyCOW patch to the Lede kernels? I
did not see any mention in the Lede-dev Archives.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Hi - a few "armchair" comments from a complete outsider, repeating things that
you probably already know:
> There are large PRs (think the Mikrotik changes) which are unsuitable for
> inclusion as-is, yet too worthwhile to be left rotting.
One of my favorite lines from the first chapter of ESR's
Hmm - A few comments from a naive outsider -
> 1) Images shall have a version number X.Y.Z where X is the year of
> release, Y the month and Z the build number produced by buildbot
>
> 2) The nonshared base repository holding kmods will be copied for each
> consecutive build, so there will be
Ok - thanks for taking the time to explain this versioning process. So now, I
should take the time to "feed it back" and see if I understand. Ha!
> https://git.lede-project.org/source.git
404 Not Found
Hmm. Try Google...
https://git.lede-project.org/?p=source.git
description LEDE Source R
On 11/20/2016 08:26 PM, David Lang wrote:
> replying to details other than the feeds concept/
> ...
>> There were two different definitions offered. I'm guessing that you meant
>> the
>> "build number" after the "major.minor" version number.
>
> not quite
>
> the branch would be Year.Month, ta
On 12/22/2016 12:27 AM, John Crispin wrote:
> or do we want to build a "one stop shop" for embedded linux
Yes, we do?
When I read that, my gut reaction was "Oh yeah - embedded linux."
I remember, when I first heard about "LEDE", as distinct from OpenWRT, I was
attracted to the broader focus on
OpenLEDE
The name both combines the project names and conveys that sense of greater
transparency that was, in part, the purpose of the LEDE project.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede
15 matches
Mail list logo
