and/or
stderr capturing either per-script and/or globally
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Just a note in case you were not aware, json-c is not thread-safe (the rsyslog
project forked it to libfastjson to fix the thread safety and drastically
improve speed)
On Mon, 27 Mar 2017, Florian Fainelli wrote:
Date: Mon, 27 Mar 2017 17:10:57 -0700
From: Florian Fainelli
To: lede-dev@lists
May I suggest that you talk directly rather than through the mailing list?
David Lang
On Mon, 3 Apr 2017, lede-proj...@bepo.de wrote:
Date: Mon, 3 Apr 2017 13:51:21 +0200
From: "lede-proj...@bepo.de"
To: lede-dev@lists.infradead.org
Subject: Re: [LEDE-DEV] [AD] support me hacking
ogress and look forward to the remerge happening.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
s, then you really aren't part of the
project any longer.
All it takes is changing the word "Committers" to "Contributers".
The existing method of giving programmers commit/voting privileges will work
just as well for non-programmers (i.
een taking place have included discussions on
the rules. If there are OpenWRT devs that are unhappy with the LEDE rules, I
would be expecting them to be speaking up in these discussions, and not in
general terms, but with what they specifically are unhappy with.
It almost sounds like you are tr
would have to comply with these rules?
or are they outsiders (I am an outsider)
David Lang
On Fri, 12 May 2017, Eric Luehrsen wrote:
Date: Fri, 12 May 2017 04:09:31 +
From: Eric Luehrsen
Cc: LEDE Development List
Subject: Re: [LEDE-DEV] openwrt and lede - remerge proposal
I read this on
m as source addresses for
performing acts on behalf of openwrt.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
On Fri, 12 May 2017, Stijn Segers wrote:
David Lang wrote:
The (soon to be former) LEDE developers don't want @openwrt.org addresses,
so
providing a way to not break the existing addresses and not giving out new
ones
doesn't seem like it is upsetting to any of the developers.
On Fri, 12 May 2017, Daniel Golle wrote:
Hi Edwin,
On Fri, May 12, 2017 at 10:02:36AM +0200, Edwin van Drunen wrote:
As a long time user of OpenWRT and recent “LEDE convert” I would also like to
chime in on the naming and branding of the post-merge project.
My employer and several of my indu
ge OpenWRT/LEDE user base' was not part of the vote, both LEDE and
OpenWRT limit the vote to a fairly small set of people who contribute to the
code (very common in opensource projects. I don't know of any who allow the user
base to vote on project infrastructure)
David Lang
I also
east consider voting on "should the merged project
be called OpenWrt" before the final decision on the name of the merged
project is made.
they already voted on exactly that question.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
The original post in this thread listed the remaining items to be
done/decided for a remerge.
David Lang
On Fri, 12 May 2017, Fernando Frediani wrote:
If the majority voted for the name OpenWRT what's the remaining issue then ?
Fernando
On 12 May 2017 23:40, "David Lang"
unity'? how do you determin who would be
allowed to vote? how would you prevent voter fraud from people who have very
strong opinions?
David Lang
P.S. the people who voted, including those who have strong opinions against the
name OpenWRT are not disputing the vote, w
ually passionate in the other direction, while still others are
less passionate.
But the vote is the vote, and stating how passionate you are on one side or
another doesn't alter the vote.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradea
the vote on the name was held several months ago, please stop trying to re-do
the vote just because it didn't come out the way you wanted it to.
k
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-d
note that the kernel currently under development (4.14) is tagged to be a LTS
kernel (6 years of support), so it would be good to work on that if possible.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listin
On Tue, 3 Oct 2017, Kevin Darbyshire-Bryant wrote:
It's tempting to set it to 1 (like I have for the past year+) and be damned
:-)
So what is the failure mode and how will people who experience failures know
what they need to change?
David
On Sat, 7 Oct 2017, Hauke Mehrtens wrote:
* Port the generic patches
what are the 'generic patches' and is there an effort to get them upstream so
that they don't need to be ported in each release?
* Make all the out of tree modules work with it
is there any work being done to make these
On Sat, 4 Nov 2017, Hans Dedecker wrote:
On Sat, Nov 4, 2017 at 10:14 AM, Petr Štetiar wrote:
Hans Dedecker [2017-11-03 13:46:14]:
Hi,
By default dropbear logs to syslog which discloses info about account names
when doing connection attempts (e.g. "Bad password attempt for 'engineer'
from
t hash.
LEDE makes fewer official release candidates and the nightly snapshots are just
that.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
17.01 is pointer to a particular commit on the master branch
I haven't looked at the specific method used for the r# generation, but I think
it's incremented daily
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mail
On Wed, 8 Nov 2017, John Crispin wrote:
you can probably drop the validation. if the users passes 9 as a
priority everything will be logged. passing -1 will cause silent logging.
you should do limit checks and cap the internal value to the limit, otherwise
you have to do more work for each lo
that's mostly a question to direct at the upstream software sources. only a
small portion of things are written by the LEDE team
SPDX is mostly useful for people wanting to fork or extract code from opensource
projects, not for the project writing the code
David Lang
On Thu, 9 Nov
given that 4.4.114 added meltdown/spectrefixes, shouldn't we move to it?
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
s out when it hits a limit?
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
via e-mail?
in other words, would this really be able to cover all commits without having
people sign for other people's work? If it can't, what do the signatures
actually tell you?
David Lang
___
Lede-dev mailing list
Lede-dev
nts down will ease introducing new versions, reducing the
load on developers so they can produce more patches ;-)
But I do think a push to get as much as possible upstream will help. And it will
help not juse LEDE/OpenWRT but also every other project that's targeting this
space. If w
end up conflicting when building package C.
automated tests for #1 would be a good start.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
combined build, in an ideal world I'd try to build with everything
submitted, and then bisect down to find the item that breaks it if the combined
build doesn't work.
If it's possible to auto-flash/pxeboot some devices to run the new build and do
real tests on them, so
ts to have a separate folder for each of them.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
to be worth the hassle?
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
On Thu, 5 May 2016, John Crispin wrote:
On 05/05/2016 07:38, David Lang wrote:
On Thu, 5 May 2016, John Crispin wrote:
On 04/05/2016 23:38, Kus wrote:
Greetings
I'd like to propose that all commits (at least to master) going
forward be signed with the commiter's gpg key.
h
claiming to be someone who has access to that
signing key), the value of signatures is much less.
By all means consider using them. I'm just saying that the project should be
able to state why with something other than "because we can" to the question of
&qu
, what you are especially interested in getting your hands on, and what you
won't bother with even if someone donates it.
Setup a way for people to donate small amounts monthly to the project (to fund
such devices and/or hosting, trips to DC to argue with/brief the FCC, et
On Thu, 5 May 2016, John Crispin wrote:
On 05/05/2016 10:14, David Woodhouse wrote:
On Thu, 2016-05-05 at 08:13 +0200, John Crispin wrote:
Hi David,
some folks would prefer to have the prefix on the 2 lists. I just had a
look in the mailman settings and failed to quickly spot the location
wh
On Thu, 5 May 2016, Michal Hrusecky wrote:
David Lang - 18:20 4.05.16 wrote:
Debian has ...
Just for the sake of discussion and inspiration, how openSUSE does it's rolling
release. We have OBS, which is server software, connected to multiple builders.
It has projects and in those pro
by, etc tags to
the commit message?
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
n take this approach has seen
both more stability and more change.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
o the nntp feed that mailman can
provide).
I believe that I saw that a recent version of mailman added a web interface to
mailing lists, but I haven't seen anyone using it yet.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.inf
On Thu, 5 May 2016, Matthias Schiffer wrote:
On 05/05/2016 07:43 PM, David Lang wrote:
On Thu, 5 May 2016, Ben Greear wrote:
On 05/05/2016 07:30 AM, Kus wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Ben,
Just to be clear. We're talking about signing git commits, not emai
to it available.
OpenWRT updates against *openwrt.org servers, so LEDE is not going to be able to
do anything there.
David Lang
Trunk introduces important changes, for example the switch from uClibc to
musl, so until everything's polished and ready for release I'd rather not
use trunk
could be setup by someone outside of the core group
(working with their own fork of the project until they get things functioning)
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
erent
firmware from being loaded on the devices and the proposed rule that would have
required lockdowns have basically been stopped.
However, multiple vendors are imposing restriction and claiming that the FCC is
requiring them, even after the FCC says that it'
On Wed, 16 Nov 2016, Simon Wunderlich wrote:
Hi David,
On Tuesday, November 15, 2016 4:49:40 PM CET David Lang wrote:
Well, we are. We can't change the fact that the devices need to be locked
to be sold in the US. But if you google a little, you will find a lot of
patches for various
argument for the
lede source in that you may backport some fixes into a release branch)
Other than this, it looks reasonable.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
the 'feeds'.
LEDE maintains this structure and uses the same feeds as OpenWRT
David Lang
On Sun, 20 Nov 2016, James Feeney wrote:
Date: Sun, 20 Nov 2016 18:11:16 -0700
From: James Feeney
To: lede-dev@lists.infradead.org
Subject: Re: [LEDE-DEV] Release Preparation Questions
Ok - thanks fo
kernel.org and see what
the folks there have to say.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
r to
just the git repository "https://git.lede-project.org/";, and the git directory
"source.git" would instead be named "build.git". The file "feeds.conf.default"
could be called "manifest.default", which would be a concept shared
every couple of blocks.
On a 10TB filesystem, we probably want 4K block size and an inode for every few
K blocks
A menu to customize these rather than calculating them will allow people to
tweak them to fit the uncommon cases that LEDE is likely to be used for.
David Lang
_
not sure I understand how this would work?
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On 2016-11-22 17:43, David Lang wrote:
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On a 16M filesystem, we probably want to use a 1K block size and have an inode
for every couple of blocks.
I'd say on a 16M filesystem we probably want to use squ
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On 2016-11-22 17:48, David Lang wrote:
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On 2016-11-22 17:43, David Lang wrote:
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On a 16M filesystem, we probably want to use a 1K block size and have an inode
for
farm? how much hardware would people need to donate to
reduce this significantly (1-2 days for example)?
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
that brand attached
to the development moving forward.
I agree, I think this is an obvious choice to make. OpenWRT has a lot of name
recognition, it would be foolish to throw that away.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradea
or a period, you want to use a tilde
'~'
the reason for this is sort order, if something is sorting versions with an
alpha sort, you want the ~rc to show up as older than the YY.MM release, and you
want that to show up as older than the YY.MM.N releases.
David Lang
On Wed, 21 Dec 2016, Dave Taht wrote:
On Wed, Dec 21, 2016 at 12:29 PM, David Lang wrote:
On Wed, 21 Dec 2016, Kathy Giori wrote:
From a PR perspective, I strongly suggest keeping the term OpenWrt as
part of the branding of the project moving forward. It can just be
cosmetic (web site, etc
On Wed, 21 Dec 2016, Stefan Monnier wrote:
- While brands have value, you can change a name without losing all the
brand recognition. I'm thinking here of cases like XBMC->Kodi or
OpenOffice->LibreOffice.
I would point at OpenOffice -> LibreOffice as a failure of name change
oblem that can be solved by a http redirect ...
Is that going to break all links in discussions that point at OpenWRT docs
and/or forum threads?
That's a high cost.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://list
On Thu, 22 Dec 2016, James Feeney wrote:
On 12/22/2016 01:33 AM, David Lang wrote:
the reason for this is sort order, if something is sorting versions with an
alpha sort, you want the ~rc to show up as older than the YY.MM release, and you
want that to show up as older than the YY.MM.N
On Thu, 22 Dec 2016, John Crispin wrote:
On 22/12/2016 09:42, David Lang wrote:
On Thu, 22 Dec 2016, John Crispin wrote:
Yes, the name is pointing at a product that doesn't exist any longer,
but Deb and Ian aren't involved with Debian any longer either. At some
point the fact that
doesn't happen for a
while, the list will still be useful as it reduces how far back people would
have to go at the point of release.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
ease. If you are able to sustain the results for a few versions,
people may start to trust and use it (or they may just use the more up-to-date
tree)
David Lang (who has no authority within LEDE or OpenWRT)
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
ready accepting pull requests via github
But I think everyone is saying there won't be a 'commercial' vs 'community'
split. There will be 'stable' vs tip-of-development, but that's it.
David Lang
___
Lede-dev
k.
Reason:
We're sorry, but new users are temporarily limited to 3 replies in the same
topic.
If you can correct the problem, please try again.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
ers are free to pass the
source along, as it is GPL.
But if it's a separate download, it does have to be made available to anyone.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
violation of the GPL and while none have gone to court
in the US, that's because the violators have always settled before getting into
court (with vmware being the only exception, and I haven't heard that that case
has gone to trial yet)
David Lang
On Fri, 10 Feb 2017, Philip Prindeville wrote:
Hi.
I was wondering if there’s an obvious place to install a hook that’s:
(a) after all the packages have been installed;
(b) before the root filesystem image gets finalized;
I’d like to be able to run some simple sed scripts inside the root-to-b
On Sat, 11 Feb 2017, Philip Prindeville wrote:
This can't eliminate the /etc/rc.d/S* files as it only adds files, and it's not
as flexibile as adding a user or changing a password (as it would just let you
replace the /etc/passwd, /etc/shadow files, not modify them).
If you look for where the
On Sun, 12 Feb 2017, Philip Prindeville wrote:
If you look for where the /files/* are copied into the filesystem, that is
probably the place you would want to add your scripting hooks.
Good idea. I’ll look there.
Once you find this, may I suggest that you create /scripts/* and contribute t
he root user to select a password that
is shorter than 'recommended', that's normal behavior on *nix systems and has
been for decades, even as the 'recommendations' have changed.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.
On Fri, 17 Feb 2017, Dan Lüdtke wrote:
Hi David,
thanks for the fast response!
On 17 Feb 2017, at 11:54, David Lang wrote:
But deciding that you know better than the admin of the system is not.
Not that I am a fan of telling admins what to do, but do you see any chance
that we can get an
On Fri, 17 Feb 2017, Alberto Bursi wrote:
On 02/17/2017 12:26 PM, John Crispin wrote:
On 17/02/2017 12:16, Dan Lüdtke wrote:
Hi David,
thanks for the fast response!
On 17 Feb 2017, at 11:54, David Lang wrote:
But deciding that you know better than the admin of the system is not.
Not
On Fri, 17 Feb 2017, Alberto Bursi wrote:
On 02/17/2017 12:52 PM, David Lang wrote:
On Fri, 17 Feb 2017, Alberto Bursi wrote:
And having no password is a much bigger change than having a short
password when you are testing things. It makes a lot of sense to be
excercising the password routine
The kernel already includes facilities for signing modules, if you are looking
for a way to sign and verify things, it seems like it would make sense to adapt
that to sign the entire image.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http:/
result
would greatly multiply the size of the downloaded page, not nice to users.
This change seems reasonable to me.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
On Fri, 6 May 2016, Vittorio G (VittGam) wrote:
On 05/05/2016 21:30:56 CEST, David Lang wrote:
On Thu, 5 May 2016, Vittorio G (VittGam) wrote:
Hello,
I'd like to know if there are any plans for Chaos Calmer?
Will it become mantained by LEDE?
almost certinly not. But LEDE will c
s will they be able to
really think about the larger issues and figure out what to do about them.
And the LEDE folks have a lot of infrastructure to setup (and there will be a
lot of bikeshedding going on while they do this), so they are going to take some
time to get everything going and g
rough a hierarchy similar to how the Linux
kernel maintainers merge things from their area and then Linus merges from them
to the final tree.
Too many people with commit access to the central tree just leads to more ways
to trip over each other.
David Lang
___
On Fri, 6 May 2016, Ben Greear wrote:
On 05/06/2016 10:20 AM, Toke Høiland-Jørgensen wrote:
Ben Greear writes:
I am interested in feedback on the testing output. My goal is to add a
few more different hardware configurations and then do nightly (or at
least weekly) tests.
So that is showin
On Fri, 6 May 2016, Ben Greear wrote:
On 05/06/2016 12:05 PM, David Lang wrote:
On Fri, 6 May 2016, Ben Greear wrote:
On 05/06/2016 10:20 AM, Toke Høiland-Jørgensen wrote:
Ben Greear writes:
I am interested in feedback on the testing output. My goal is to add a
few more different
atches could be
more widely tested than an individual can do (in fact I'd argue that
ideally *everyone* goes through some level of testing from someone other
than themselves.
Ideally, but we need to recognize that we don't live in an ideal world :-)
David Lang
__
s it much harder to figure out what change
broke things.
It's good for someone creating a patchset to review the patches, re-ordering
and/or squashing and/or splitting the patches as appropriate to produce a clean
history (ideally, everything should work after every individual patch), b
27;t help a lot, but there are a lot of options
that would.
David Lang
2) I repeat my offer to help with triage (i.e. making sure what does get
posted is actually useful before a developer sees it) and my suggestion
of asking for others to help with this, and providing the necessary
access to mak
cess
for those people ase well, but I don't know for sure.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
any
more either.
the git history can untangle this for anyone who cares.
But there is enough bad feelings going around, we don't need someone getting
angry over copyright notices being removed.
David Lang
On Mon, 9 May 2016, Rafał Miłecki wrote:
Date: Mon, 9 May 2016 20:35:20 +0
ge - to ~ and it will sort before the release
so 15.05.1~rc1 15.05.1~beta1 etc
also 15.05.1-14-ge1357c0 will sort after the rc, not before it.
David Lang
* branch release builds: Branch codename designation, official release
number, source revision, opkg download from release repo
Once a rc bec
ng on a single target, especially as they are
iterating through tweaks on their build.
and resources for the project may change, if you can use spinning rust, storage
is pretty cheap now.
David Lang
Another approach is to rebuild single packages (plus their dependency
subtrees) using th
we really
need the IP details and routing info? I can see some cases where they would
matter, but most of the time they don't.
I'm not arguing for security by obscurity, but I am willing to argue against
providing info to attackers instead of making them work a littl
s out of the box)
thoughts?
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
ea, let alone one that is common enough to have to introduce uci specific
knowledge into the logd daemon.
You are better off sending to a remote logserver anyway.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
On Fri, 13 May 2016, Alexandru Ardelean wrote:
On Fri, May 13, 2016 at 8:55 PM, David Lang wrote:
On Fri, 13 May 2016, Helmut Schaa wrote:
I was thinking of a different use-case:
Increasing the buffer size on the fly comes in handy during a debug
session
where you'd like to not inte
There are various other things that will require capabilities to work (including
some versions of ping and traceroute), but it's a matter of fixing them as you
bump into them.
don't try to make everything run as the same !root user, migrate things one (or
at least one
On Wed, 18 May 2016, John Crispin wrote:
On 18/05/2016 08:08, David Lang wrote:
On Wed, 18 May 2016, John Crispin wrote:
Hi,
we had previously started building the infra for running stuff as !root.
so far we have added
* the userid/gid stuff
* acl on ubus
things that i know are missing
the same packages
installed in a different order have different user->uid mapping) or if we are
going to define service accounts distro wide so they are always going to be the
same.
David Lang
___
Lede-dev mailing list
Lede-dev@lis
On Wed, 18 May 2016, John Crispin wrote:
On 18/05/2016 09:04, David Lang wrote:
The first question I would have is if we are going to the system users
in an essentially random order (as needed so two systems with the same
packages installed in a different order have different user->
o they all rely on
some external storage/database setup to hold all that stuff. Not something
normally available to LEDE type devices running in homes and small offices.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
of that caliber around. A reasonably competent
sysadmin can understand an AppArmor config and tweak it for their layout without
too much effort (once they identify that AppArmor is blocking what they are
trying to do)
David Lang
___
Lede-dev mailing
On Wed, 18 May 2016, Ferry Huberts wrote:
On 18/05/16 10:03, David Lang wrote:
On Wed, 18 May 2016, John Crispin wrote:
On 18/05/2016 09:46, Ferry Huberts wrote:
already in-place in Fedora and RedHat/CentOS.
You then get even stronger protection and run-time performance impact is
s the packages are installed in the system (with
the exception of a small number in the minimal base system)
I see arguments both ways, which is the issue I raised in a different thread.
David Lang
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
1 - 100 of 144 matches
Mail list logo
