Hi,
On 5 January 2018 at 14:58, Thomas Haller wrote:
> For NM, at each moment not all its connection profiles are candidate
> for connecting automatically. The list of which profiles can be
> autoactivated depends on NM internal state, for example
> - is the profile even
Hi Dan,
> I am in favor of address randomization even while it has
> limited
> affect, but at least for background scanning it is useful.
> However
> doing this via RTNL is causing a weird layer violation and all
> sorts
> of potential races and issues. This needs to
On Fri, 2018-01-05 at 14:58 +0100, Thomas Haller wrote:
> On Thu, 2018-01-04 at 20:22 +0100, Marcel Holtmann wrote:
> > Hi Thomas,
> >
> > > > I am in favor of address randomization even while it has
> > > > limited
> > > > affect, but at least for background scanning it is useful.
> > > >
On Thu, 2018-01-04 at 20:22 +0100, Marcel Holtmann wrote:
> Hi Thomas,
>
> > > I am in favor of address randomization even while it has limited
> > > affect, but at least for background scanning it is useful.
> > > However
> > > doing this via RTNL is causing a weird layer violation and all
> > >
In a recent commit 686afe531ab3774cd818feda8361de74101971f5, a new
macro called `_NM_SD_MAX_CLIENT_ID_LEN` was introduced. However, the
systemd DHCP client handler did not include the file where the
macro was defined, `nm-types.h`. Although this worked in autotools,
it fails on meson.
The include
In a recent commit 1402fa7487b29fc1ea39a6bf7659fee7f30bb0e0 a new
way for testing Red Hat compatible distributions had been added.
This new testing approach has also been added to meson.
---
meson.build | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meson.build