Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency
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 try to do this. The >> feed version you get is the feed version that exists at the time you last >> pulled from the feeds. > Uhm - I'm a bit taken aback by that. >> This hasn't been a big problem in practice, but it does mean that you don't >> really have a repeatable build. > I would have thought that that was a "show stopper". It certainly does not > inspire confidence. > I say this is a "problem" and should be a high priority issue. >> See my other e-mail about [git] submodules for a >> discussion on this. > Yes, I looked at that. It would seem to address and solve a number of issues. > There would be no need for a separate "manifest", and, most importantly, there > would be a git "snapshot" of the *entire* project state. If I understand, > that also means there would be a unique git tag that would label that state, > and could be associated with any kind of specific nickname, version, and build > number. It would mean that every build was repeatable. >>> It would be possible, I suppose, that each of these linked repositories >>> could be *required* to use the *same* versioned naming scheme. >> >> can't be done, these other repositories are not under our control. The most >> we can do is reference exactly which release we use.. --- So then, nothing was done to address this issue, when developing the new release process, where, instead, at worst, LEDE could simply "snapshot" a "feed", and keep that copy on github, and then *under LEDE's control*. And git submodules are still an available solution. I don't know that there is any polite way to express how ridiculous I find this situation, of non-repeatable builds, let alone the failure to bump the version number of the release. I might call it "unprofessional", though I'm tempted to be otherwise demeaning. Let me say again, I think that this is an important issue that the LEDE project needs to address and remedy. I believe that the ultimate credibility and reputation of the LEDE project is at stake. James ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency
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 packages from any of the feeds are > actually included in the released target binaries? Realize? No - I'm still learning how this build process works in LEDE. My impression is that you are distinguishing between "packages" and some other type of thing, which the lede-project.org site seems to implicitly, and generically, refer to as just "firmware" - even though a "package" is also a type of "firmware", and this "firmware" is also a type of "package". I will infer that you mean to distinguish between the "kernel and base filesystem" package from all other "packages". You also seem to be implying that all the various "kernel and base filesystem" package builds are now precisely repeatable - even though this fact does not seem to be documented anywhere. > Strictly speaking the package feeds are simply not a part of the > project making the release. With respect to the lingo, "package feeds" and "project making the release", I have no understanding of the meaning of that statement. Perhaps you could define precisely "package feeds" and "project making the release"? > From my understanding the original issue which was brought up by Pau > is the result of a lack of documentation how to properly use the SDK > and ImageBuilder. It doesn't have much too do with that past trauma > of yours, though obviously resembled it closely enough to trigger some > painful memories and write an email using lots of quotation marks and > emphasis to make us *see* "something". Ha! Quite! > Release builds (ie. building the buildroot from source) are entirely > reproducible, thanks to the long and tideous efforts of the > reproducible builds team, eliminating timestamps and other obstacles. Ok - I don't actually know what is meant by "buildroot", but my impression is that you mean the kernel and base filesystem, yes? And so then, any package labeled in similar form to "17.01.0" will be uniquely reproducible at any time in the future, yes? > I fail to see the issue which would even remotely justifies the degree > of inflated drama. Simply a combination of my uninformed state of mind, where I am left to "fill in the blanks" with the information presented in the past, specifically that "you don't really have a repeatable build." Since that seems to have changed, it would be good to advertise that fact in public, which is to say, to document that fact on the lede-project.org website. > I fail to see how this is unprofessional or even > inconsistent or anything like that. Maybe there have been > misunderstandings caused by wrong expectations caused by a lack of > documentation. Perhaps, depending upon what is meant by "wrong expectations". *My* expectations of the LEDE project are simply *my* expectations, no matter what the state of the LEDE project might be, documented or not. > I also fail to see how git submodules could make things > any better. Imho using git submodules, especially for meta-stuff is > a very bad practise, many distributions decided against that and for > good reason, see e.g. some input from puppetlinux [1]. Money quote: > "All of this smells of an antipattern. Git submodules sound great > initially, but the farther down this road that you go, the more work > you're going to generate trying to work around the limitations of git > submodules." > Maybe subtrees can be better. Having an explicite manifest, like > feeds.conf in the SDK, does the trick. I agree that it's a bit > hidden and that practise has not been very well documented (yet). I cannot speak to that specifically. If, as you suggest, there is a solution already in place for LEDE "controlling" the source code from the package source repositories, then this is no longer of any importance. But I am not quite sure that I have heard that that is so. Are all of the "package" builds versioned and repeatable? > Anyway. Back to the real issue here: > Imho you shouldn't use the SDK to build core packages or even any > package provided in a binary feed belonging to that release and then > use that version (which you have just built locally) in the > ImageBuilder. Yes, you may need to build it in order to build your > local packages to satisfy build dependencies. But when it comes to use > the ImageBuilder, always use the upstream binary feeds and only include > your hand full of local packages in a seperate feed. > If you really need to modify packages already included in an upstream > binary feed, rename them and use the (now working) PROVIDES variable to > satisfy dependencies (or make sure your modifications go upstream!!!) The specifics of that process would be outside my purview. As long as the "package" builds are versioned and repeatable,
Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency
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 kernel and base filesystem. LEDE does name each of them individually, based upon the target architecture. It would be nice to have some generally recognized single name for this class, "the kernel-fs packages" or some such. Of course it's a little complicated, since most traditional Linux distros target only one or two hardware architectures, and LEDE targets many many different target architectures. But then, that's the whole point of LEDE. > You will notice that it states the official download link for the > sources, a SHA256 hash and a specific version for the package name. > On some other packages it will state git commit or other way to identify > the same source to pull down and build. > ... So, if I understand, there always exists a set of hashes to verify that, at any time in the future, a package can be built which is identical to any package built in the past. Bastian also mentions "checkout LEDE and all feeds at a specific timestamp" as an approach. This suggest two general tracking mechanisms: 1) tracking by hash, and 2) tracking by time-stamp. Is one of these mechanisms, or are both of these mechanisms, used universally in the LEDE package management system? > In /patches folder of each package's folder you will find any patches > that will be applied to the source after downloading it, before > compiling, again the example package: > ... Hmm - it is not entirely clear to me that, if the patch set changes in the future, the version number of the package will be distinctly incremented, as would be pretty standard for any other Linux distro. Does each package have a minor version number, in the source and binary repositories, to allow distinguishing patch set changes, used in each build of every package? > Is this enough for having repeatable builds? Perhaps, assuming that these distinct version numbers exist, and that these historic time-stamp or hash verified sources are archived somewhere and available. > Yeah, I agree that adding this to the wiki would be good. > If you confirm that this answers your questions (more or less), I'm > adding it to the wiki. It sounds like the LEDE package management system has changed and improved over the past months. It would be great to see your description of the LEDE package management system and build system on the wiki! Still, as Daniel has suggested, I may not quite understand Pau's underlying concern, which started this thread. Looking back, Pau says: "The SDK published then is not consistent with the current package binary repositories", and "... if there are fixes a new revision must be published instead of modifying the current one (i.e 17.01.1). Are these concerns simply misunderstandings of the changing LEDE package management system? Or, are these concerns addressing actual shortcomings with version control in the LEDE package management system? I don't think I've heard a definite answer. I was not trying to hijack Pau's thread, but Daniel has questioned whether my issues and Pau's issues are the same, or not. Thanks James ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] musl: update to 1.1.17 - LEDE version numbers?
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 what - does LEDE have two completely different versioning systems? Is LEDE switching over to the openwrt versioning system? From where comes the "r5217"? Is that "r5217" a strictly reproducible LEDE version? Somebody, please clue me in here. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] LEDE version numbers?
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 and then: [RFE] Add minimal universal release management capabilities to GIT 20 Oct 2017 https://public-inbox.org/git/1290947539.4254.1508496039812.javamail.zim...@laposte.net/ Still, this is me again ranting about a problem which has no simple one solution. Food for thought... At one extreme, the linux kernel development uses a manual process to create formal development releases from a git repository. On the other extreme, the GNU C Library (glibc) project generally refuses to provide development releases, or even bug fix releases, between its official releases. Parenthetically, I notice that those two projects were perhaps the antithetical archetypes for "The Cathedral and the Bazaar" development models. Even though both projects use git now, they use it differently. LEDE is even more difficult, because it is not just one "package", but a construction of many packages. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE version numbers?
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) Thanks for that David! How are the r#'s known? Are they simply incremented with every git commit? And they would apply to only one particular branch? I see two "heads", "master" and "lede-17.01". Do the r#'s apply to only one of those? Or, are "master" and "lede-17.01" guaranteed to not be parallel branches? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE version numbers?
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 commits with a + (e.g. "r4601+95-1ab227d688" - the last > common commit is 1ab227d688, 4601 after "reboot", and there are 95 local > commits that aren't upstream). Thanks Matthias, that helps a lot. I also found some help with making sense of the git lingo, for anyone that has not already played with this: Visualizing Git Concepts with D3 https://onlywei.github.io/explain-git-with-d3/ It's an interactive visual learning aid. > Basically, we tried to mimic the "revision > ID" SVN provided for the old OpenWrt trunk, adding some extra information > provided by git. Ha! So there *was* an element of the OpenWrt revision numbering! I'm tempted to ask if there is not some value, then, in a LEDE revision numbering that would look like "lede-17.01.r4601"? Would that not be a precise, and monotonic, version declaration, no matter whether it was an "official" release, or a nightly, or even some random snapshot? Hmm - and then, isn't a designation of the form "lede r5217" completely unambiguous, other than not providing a branch name, to say, for instance, that it is, or is not, an "official release"? So then, LEDE does not run parallel development branches in the main git repository, and simply designates certain development snapshots as "official releases"? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE version numbers?
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.x maintenance releases). Aha! That's really useful. I looked for some help with git visualization: Visualizing branch topology in git https://stackoverflow.com/questions/1838873/visualizing-branch-topology-in-git Then: git clone git://git.lede-project.org/source.git cd source git log --graph --all --pretty=fuller --simplify-by-decoration Also useful: git-big-picture -i -m -f pdf -v okular ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] DirtyCOW backport
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
Re: [LEDE-DEV] Actual community change and additional developers compared to OpenWrt
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 CatB: "Linus Torvalds's style of development—release early and often, delegate everything you can, be open to the point of promiscuity—came as a surprise." Mostly my relationship to FOSS is writing bug reports - not here, yet - and chiding my friends who might complain about code, but then not - at least - write bug reports. Certainly the single most important interaction with a software project - or any kind of social activity - is the response I get from attempting to participate. This can range anywhere from the "slap in the face" experienced when being completely ignored, to actually generating a real incremental addition to the code base. The best way to "turn people off" is to ignore them. And the best way to engage their interest is to respond in a way that empowers them, that makes them feel that they are able to make a contribution to something that matters. Of course, everyone already knows that. But still, "be open to the point of promiscuity". "Promiscuously Open" to accepting patches from "outsiders". "Open" to accepting "structural" changes. Imagine someone trying to "shoehorn" systemd into LEDE. How would that feel? I suspect that "developer time" and "developer workload" are not really the issue, at the root of it, not really. Making friends with strangers, and then letting them muck-about in your "back yard". That's not so easy. It's not "safe". But developing those "stranger" relationships, taking the risk, allowing change, and taking the time - that's really really important. Easy for me to say - I'm just a spectator. I don't have to deal with the consequences. So far, a brief glance at the mailing list, I see people asking questions and people actually answering those questions. The mailing list seems quite responsive - very very good! And there is introspection. It looks healthy to me. One comment about the web site, and the home page, since that is the LEDE "first point of contact". If someone could "personalize" that - say, once a month, update a summary about - a few idle comments about - say, the mailing list activity and changes to the code base. Because now, at first glance, it looks "static", like "dead", like "nothing is happening" - and that's not true. Home page: Last updated 2016-08-10 20:04:24 Meeting Logs: Last modified 30-Mar-2016 09:57 LEDE Wiki: Last addition ??? no idea Hmm - let me also say this another way. Everyone with an interest in FOSS knows who Linus Torvalds is. Who is the "leader" of the LEDE Project? I cannot say. I don't know. And I am not invested in the answer. I'm perfectly comfortable with the idea that it could be anybody. I simply do not know "who the players are". The LEDE Project is "not personal" - it's an "abstraction", even though I run the software. Not even Wikipedia can tell me, though I did find a link there, to an article from TheRegister: "Individuals in the process include Jo-Philipp Wich, John Crispin, Daniel Golle, Felix Fietkau, Hauke Mehrtens, Matthias Schiffer and Steven Barth." Whoever you are, "mystery guys", take a risk, "expose" yourselves. Make it personal. I might want to get to know you - not Biblically, but still. Easy for me to say - I'm just a spectator. But then, I might have to deal with the consequences. As it is, loading Linux on Embedded Devices is kind of 'mysterious' and 'scary' if only because most people don't dare touch the manufacturer's boot loader without access to a soldering iron and specialized programming hardware. To say nothing of cross-compiling, which seems to *require* a specialized chroot environment, to actually work effectively, without "silent failures". And, if you want a little - well, really a lot - more public recognition, government support, and industry funding, I believe that you just need to learn to say "IoT DDoS". Pick up the gauntlet and shake it at people. I appreciate what the LEDE community is doing, and intending to do. James ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Release Preparation Questions
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 a > > http://downloads.lede-project.org/$version/targets/ar71xx/generic/ > packages/$buildno > for each build in order to ensure kmod compatibility even for older > installed images Right off, I see the term "buildno" being used twice in a "name": 1) "version number X.Y.Z ... Z the build number", and 2) "$version/targets/ar71xx/generic/ packages/$buildno". This appears redundant, and redundancy is a bad idea in this context. > Assuming that for each released build we produce a tag then we would use > the tag as designation plus the current hash, e.g. "16.11.1+git6b40471" > or we can alternatively use the logic used for master and use the last > tag as version number and count the number of commits since it, e.g. > 16.11.1+r5" "Human readability" is an issue here, where "r5" is easier to recognize than "git6b40471". If "information" is not essential *do not* use it in a "name". Looking through these posts, I see the following terms used. I "think" I know what some of them mean, but I am naive and am probably misunderstand what all these terms *actually* mean. Still, this is a very long list of terms to apply to a unique "name". If, in fact, each of these "terms of art" are both a) distinct, and b) essential, then the "version number", as used in the introductory post - "any related resources like download URLs, Git repositories etc. are using predictable names which can be constructed from the version number" - must contain the entire set of "independent variables", in order to convey the required information. I count twenty independent variables: 1) base repository 2) external feed repos 3) feed source branches 4) release branch number 5) commit tags 6) builds 7) master 8) release branch 9) release number 10) branch release builds 11) package feeds 12) commit hash 13) source branch 14) subrelease 15) new release 16) security fix 17) nickname 18) code name 19) version number 20) main firmware You know the drill: Pretend that you are explaining this to a grade-school child. My naive first impression is that, if the LEDE build process actually *requires* twenty different conceptual variables to designate a specific "version number", then something is probably wrong with the way this process is being managed. Still, I would encourage, a) writing-down an "essential" and "official" list of terms to be used in creating a LEDE software "release", b) explaining those terms to some naive person, and c) see if that person understood you. So far, *I* do not understand what you guys are talking about - and I've been doing this open source software thing for over twenty years. James ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Release Preparation Questions
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 Repository Ok. $ whois lede-project.org Admin Name: Jo-Philipp Wich Admin Country: DE That helps orient things. > it does not require twenty different variables but it has to deal > with (currently) five independent repositories: > - feeds.conf.default: git://git.lede-project.org/feed/packages.git Hmm - try Google again: https://git.lede-project.org/ Ah ha. feed/packages.git Mirror of packages feed Git 119 min ago feed/routing.gitMirror of routing feed Git 2 weeks ago feed/telephony.git Mirror of telephony feedGit 4 months ago ... project/luci.gitLua Configuration Interface... Git 28 hours ago Ok. I don't know what I'm seeing yet, but ok. > ... described in feeds.conf.default within the base repo. Hmm - still drawing a blank... source.git LEDE Source Repository Git 102 min ago https://git.lede-project.org/?p=source.git;a=tree https://git.lede-project.org/?p=source.git;a=blob;f=README 9 Run "./scripts/feeds update -a" to get all the latest package definitions 10 defined in feeds.conf / feeds.conf.default respectively 11 and "./scripts/feeds install -a" to install symlinks of all of them into 12 package/feeds/. ... getting closer... https://git.lede-project.org/?p=source.git;a=blob;f=feeds.conf.default Ah ha! 1 src-git packages https://git.lede-project.org/feed/packages.git 2 src-git luci https://git.lede-project.org/project/luci.git 3 src-git routing https://git.lede-project.org/feed/routing.git 4 src-git telephony https://git.lede-project.org/feed/telephony.git 5 #src-git targets https://github.com/openwrt/targets.git 6 #src-git management https://github.com/openwrt-management/packages.git 7 #src-git oldpackages http://git.openwrt.org/packages.git 8 #src-link custom /usr/src/openwrt/custom-feed Mmm-hmm - I seem to have gone in a circle. So, the term "feed" is a unique concept, referring to three "gitish" directories including the name "feed", and one "gitish" directory *not* including the name "feed". Hmm... Well, that seems like an inconsistent concept. So, a "feed" is whatever git "directory" a file "feeds.conf.default" says it is. That is not a traditional hierarchy, and it is a mistake for me to try to think of LEDE as a kind of file system hierarchy. It is more like a kind of linked-list, with a "root" located in a file, which is located in a git directory "projects/source.git/tree", which is best discovered by already knowing its location. This is an organizational model which I have not encountered before now. It is certainly not the most "discoverable" model which I could imagine, but ok. And then, there is a top-level git directory name, "source.git", where the term "source" is not used in the usual manner, to mean literally the directory holding the source code, but instead, seems to refer to that directory which contains the file which enumerates the elements of the term "feed". And also, there is the idea of "base repository", where the "base" is being defined as the "source", and the "source" is not really the "base" in the traditional sense, but instead is located under a traditional "base" URL, "https://git.lede-project.org/";. Again, this is a nontraditional use of the term "base", which seems to be used interchangeably with the term "source" - but ok. Lots of specialized, nontraditional, terminology, - "base", "source", "feed" - but ok. Now, revisiting the concept of "version number": 1) "base" repository - https://git.lede-project.org/?p=source.git 2) "feeds" - described in feeds.conf.default within the base repo. 1 src-git packages https://git.lede-project.org/feed/packages.git 2 src-git luci https://git.lede-project.org/project/luci.git 3 src-git routing https://git.lede-project.org/feed/routing.git 4 src-git telephony https://git.lede-project.org/feed/telephony.git 3) release branch number - an input variable, major.minor version, usually year.month - or instead, the number of the build being produced from a branch. There were two different definitions offered. I'm guessing that you meant the "build number" after the "major.minor" version number. 4) git tags - exactly match the source state; "commit hash". 5) builds - the binary artifacts produced, branch release builds. 6) master - master branch of the "base" repository. 7) release branch - used for *all* builds within a major.minor version; "source branch". 8) subrelease - Any release within a base version; patch levels; security updates. 9) nickname - Symbolic name given to an entire release branch; all 16.11.* releases will carry the same nickname. Hmm - it is still not clear to me
Re: [LEDE-DEV] Release Preparation Questions
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, tags/builds within that branch would be > Year.Month.Build Ok, I get that. > ... >> Hmm - it is still not clear to me how the term "branch" will apply here, >> because: 1) the hierarchy of "base.feeds" is referencing four *other* git >> repositories, each of which has its *own* "head" branch name, each of which >> - I >> assume - may be changed or selected independently; and 2) the "feeds" link >> list >> does *not* have any version information within it, itself. > > The branch is really based on the LEDE maintained git repository, ignoring the > feeds that are not maintained by LEDE or OpenWRT. > > 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 try to do this. The feed > version you get is the feed version that exists at the time you last pulled > from > the feeds. Uhm - I'm a bit taken aback by that. > This hasn't been a big problem in practice, but it does mean that you don't > really have a repeatable build. I would have thought that that was a "show stopper". It certainly does not inspire confidence. I say this is a "problem" and should be a high priority issue. > See my other e-mail about submodules for a > discussion on this. Yes, I looked at that. It would seem to address and solve a number of issues. There would be no need for a separate "manifest", and, most importantly, there would be a git "snapshot" of the *entire* project state. If I understand, that also means there would be a unique git tag that would label that state, and could be associated with any kind of specific nickname, version, and build number. It would mean that every build was repeatable. >> It would be possible, I suppose, that each of these linked repositories >> could be >> *required* to use the *same* versioned naming scheme. > > can't be done, these other repositories are not under our control. The most we > can do is reference exactly which release we use.. I see that now. > ... > actually, the LEDE/OpenWRT releases are long, they are trying to get them down > to only a year or so. > > What most people end up using is the roughly the equivalent of the nightly > builds, but even more granular in that people grab the source code and compile > it, so they get up-to-the-minute changes, not even nightly snapshots. I don't understand the point of having a LEDE "release" then. But then, I prefer using Arch, a rolling release distribution, where other people prefer something like Debian, for stability. So maybe LEDE would have a yearly "release" version for some people, and other people can grab the latest buildbot build? Or compile it themselves. With the git submodule idea, LEDE could have a repository that even includes the entire cross-compiler tool chain? Or maybe that's going too far? >> Cyanogenmod uses the term "manifest" instead of "feed", and uses "repo", a >> specialized "repository management tool that we built on top of Git." You >> are >> familiar? In a sense, the top level of the build system is the "manifest" >> file >> "default.xml" with its own web page, https://github.com/CyanogenMod/android. >> Hmm - LEDE has a program "[source.git] / scripts / feeds", which serves the >> same >> function as "repo", yes? Maybe I begin to understand. And then, the term >> "feed" would actually mean one of several git source code repositories >> enumerated in the LEDE "manifest". And "feeds" means a LEDE git repository >> management and build utility. > > more or less. OpenWRT was stuck for a long time using subversion instead of > git, > so things developed differently, but you seem to be mapping the concepts more > or > less correctly. Ok, thanks for confirming. >> I think that, essentially, I must understand how a LEDE build version number >> can >> be related to an instantaneous version of four independent git repositories. > > ignore the feeds for now, they are not part of the LEDE release. Yeah, I see now how that works - scary, but clarified. >> Would it be useful to version the manifest, and have the versioned manifest >> enumerate specific versions of the manifest components? I assume that each >> component could specify an instantaneous snapshot version of each master >> branch >> of that component? Perhaps git tags could be included inside the manifest, >> and >> no one would have to memorize or recognize or refer to these, because the >> manifest itself would have a human readable version number, as in >> "year-month-build". > > that would be inventing another layer of abstraction, I don't think we need to > do that. But this is the submodule discussion I raised in another branch of > thi
Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and 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 "embedded linux", in contrast to the "wireless router" focus implied by "OpenWRT". That promise of embedded device support is still my mental rationalization for choosing LEDE over OpenWRT. There is something to be said for the "evolved" branding of the LEDE name. How important is this focus on "embedded linux", which implies a linux distribution that runs, additionally, on devices that are *not* wireless routers? There are a great number of single-board computers that exist now that did not exist when OpenWRT was first released in 2004. The original WRT54G was first released in December 2002. The first generation (Raspberry Pi 1 Model B) was released in February 2012. Consider: https://en.wikipedia.org/wiki/Comparison_of_single-board_computers Does LEDE have builds for all of these products? I imagine that the stable/bleeding-edge issue might be addressed in the same way as other projects which have designated "long term support" versions. Just for fun: https://en.wiktionary.org/wiki/lede James ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE
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-dev
