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
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/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 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/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
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
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
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
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
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
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
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
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
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
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
15 matches
Mail list logo
