Hi,
Zbigniew Jędrzejewski-Szmek:
> > wrap a few *_FOREACH macros in curly braces
> >
> cppcheck is full of errors anyway. I don't think we should make the code
> less pretty just to satisfy a checker, and a rarely used one.
>
While you may be right about cppcheck, IMHO it's good style to
NetworkManager sets logind inhibitor lock to monitor for suspend
events. So it implicitly requires logind to be present when NM starts.
logind is ordered after nss-user-lookup.target. If we have remote user
database, it means that logind depends on network to be up and running.
If network is prov
Yeah, something similar is happening. If I edit the container.target and
add the Wants= instead of creating the .wants directory it works well.
I think the preset-all is "syncing" the config with the .wants directory as
well and removes all links which are not defined in the config. So editing
the
The "in the field" problem is that after what firmware 1.7 changes with
Intel network drivers or what not things broke due to the fact that network
interfaces settings did not get inherited to the bridge interface and we
need to avoid that problem, which is why I think we need to redefine how we
fu
On Fri, Dec 12, 2014 at 6:29 PM, Chris Atkinson wrote:
>
> Should the line:
>
> PKG_CHECK_MODULES(BLKID, [ blkid >= 2.24 ],
>
> instead read
>
> PKG_CHECK_MODULES(BLKID, [ blkid >= 2.25 ],
>
> instead since the commit message appears to mandate 2.25 not 2.24?
>
I made only necessary changes, patc
Bump libblkid requirement from 2.20 to 2.24.
util-linux 2.25 is actually required since
fdbbad981cc5da8bb4ed7e9b6646e7a114745ec5
---
README| 2 +-
configure.ac | 2 +-
src/udev/udev-builtin-blkid.c | 13 -
3 files changed, 14 insertions(+), 3
On Fri, Dec 12, 2014 at 12:58:04PM -0800, Thomas H.P. Andersen wrote:
> Author: Thomas Hindoe Paaboel Andersen
> Date: Fri Dec 12 19:51:41 2014 +0100
>
> wrap a few *_FOREACH macros in curly braces
>
> cppcheck would give up with "syntax error" without them. This led
> to repor
On Fri, Dec 12, 2014 at 04:07:23PM +0100, Lennart Poettering wrote:
> On Fri, 12.12.14 09:07, Rauta, Alin ([email protected]) wrote:
>
> > What do you think about the following transformations:
> >
> > [FDBEntry] => [FDBNeigh]
>
> We try to avoid acronyms and abbreviations unles
On Fri, Dec 12, 2014 at 08:11:54PM +0100, Lennart Poettering wrote:
> On Fri, 05.12.14 15:54, Karel Zak ([email protected]) wrote:
> > I guess it's enough to add the 'fd' to systmed sd_event_add_io() and
> > call mnt_table_parse_mtab() when a change is detected. (As already
> > implemeted in the orig
On Fri, Dec 12, 2014 at 4:46 PM, Lennart Poettering
wrote:
> On Fri, 12.12.14 10:10, Umut Tezduyar Lindskog ([email protected]) wrote:
>
>> >
>> > https://sourceware.org/bugzilla/show_bug.cgi?id=11133
>> >
>> > But that's 4y old... Or is your toolchain that old?
>>
>> Shouldn't be:
>>
>> mipsisa32
On Fri, 05.12.14 15:54, Karel Zak ([email protected]) wrote:
> I have added struct libmnt_monitor to make this new interface easy to
> extend and usable for more resources (I'll probably also add mountinfo
> fd for findmnt(8), but this is irrelevant for systemd;-)
>
> All you need is:
>
> mn =
Should the line:
PKG_CHECK_MODULES(BLKID, [ blkid >= 2.24 ],
instead read
PKG_CHECK_MODULES(BLKID, [ blkid >= 2.25 ],
instead since the commit message appears to mandate 2.25 not 2.24?
Regards,
___
systemd-devel mailing list
[email protected]
For now I'm concerned with the FDB entries.
They are in the .network files following the logic of [Address] & [Route]
sections.
/Alin
-Original Message-
From: systemd-devel [mailto:[email protected]] On
Behalf Of "Jóhann B. Guðmundsson"
Sent: Friday, December 1
On 12/12/2014 04:12 PM, Rauta, Alin wrote:
Hi,
[BrigdeFDB] can be also fine. It's just that [BridgeFDB] makes you think at the
entire forwarding database table and you are actually defining only one entry.
[BridgeFDBEntry] makes you think at just one entry in that table.
Hmm
So it can grow
Hi,
[BrigdeFDB] can be also fine. It's just that [BridgeFDB] makes you think at the
entire forwarding database table and you are actually defining only one entry.
[BridgeFDBEntry] makes you think at just one entry in that table.
/Alin
-Original Message-
From: systemd-devel [mailto:syst
> If I get this right "fdb" only makes sense in a bridge context, correct?
> Maybe [BridgeFDBEntry] instead?
Yes, the FDB table is used by a Layer 2 device (switch/bridge), but an ordinary
interface also has a FDB table.
[BridgeFDBEntry] seems also fine.
> I mean, if networkd would simply flus
On Fri, 12.12.14 10:10, Umut Tezduyar Lindskog ([email protected]) wrote:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=11133
> >
> > But that's 4y old... Or is your toolchain that old?
>
> Shouldn't be:
>
> mipsisa32r2el-axis-linux-gnu-gcc --version
> mipsisa32r2el-axis-linux-gnu-gcc
Hi,
"Jóhann B. Guðmundsson":
> After I explained it to them they said why not just call it [BridgeFDB] ...
>
+1
--
-- Matthias Urlichs
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/syst
On 12/12/2014 03:12 PM, "Jóhann B. Guðmundsson" wrote:
On 12/12/2014 03:07 PM, Lennart Poettering wrote:
Given that "fdb" and "entry" are commonly used I think [FDBEntry]
would be fine.
It exist there in the first place makes it an "entry" so what's wrong
with just calling this entry [FDB]
On 12/12/2014 03:07 PM, Lennart Poettering wrote:
Given that "fdb" and "entry" are commonly used I think [FDBEntry]
would be fine.
It exist there in the first place makes it an "entry" so what's wrong
with just calling this entry [FDB]?
JBG
___
s
On Fri, 12.12.14 09:07, Rauta, Alin ([email protected]) wrote:
> What do you think about the following transformations:
>
> [FDBEntry] => [FDBNeigh]
We try to avoid acronyms and abbreviations unless they are very widely
established. Hence I am not convinced "Neigh" is something
Hi,
Today I had one unit in failed state, and after taking care of things I
wanted to simply reset its state (to inactive) w/out having to start it.
Looking up the man page, I see there's a command reset-failed for this
exact purpose, awesome. So I go:
% systemctl reset-failed backups2.service
F
hi,
Our / partitions are on a squashfs media, which means that unit files
are read-only. There is a partition for read-write content
(Scratchable), and I'm wondering if it would be possible to add
unit-files there and have the boot order cope with this correctly?
How should this be set up -prop
On 12/12/2014 02:57 PM, Matthias Urlichs wrote:
Hi,
Colin Guthrie:
What's the argument for including /usr/local in all this stuff? Feels
wrong to me.
+ME_TOO. /usr/local frequently has wider permissions than reasonable for
something that can affect system startup.
I can think of one argumen
Hi,
Colin Guthrie:
> What's the argument for including /usr/local in all this stuff? Feels
> wrong to me.
>
+ME_TOO. /usr/local frequently has wider permissions than reasonable for
something that can affect system startup.
I can think of one argument in favor of this -- you can modify the system
Adam Papai wrote on 11/12/14 09:17:
> Why and what is removing my files from the target directories? Those are
> required to run the lxc-container properly otherwise it'll boot up in a
> dergaded state, without ssh and iptables forwarding and so on.
>
> What did I miss? Is it something change bet
Lennart Poettering wrote on 11/12/14 00:16:
> * All systemd programs that read standalone configuration
> files in /etc now also support a corresponding series of
> .conf.d configuration directories in /etc/, /run/,
> /usr/local/lib/, /usr/lib/, and (if configu
Tom Gundersen writes:
> On Thu, Dec 11, 2014 at 9:14 AM, Jan Synáček wrote:
>> test-dhcp-{client,server} are failing in mock:
>>
>> FAIL: test-dhcp-client
>> ==
>> Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:138,
>> function sd_dhcp_client_set_requ
Bump libblkid requirement from 2.20 to 2.24.
util-linux 2.25 is actually required since
fdbbad981cc5da8bb4ed7e9b6646e7a114745ec5
---
configure.ac | 2 +-
src/udev/udev-builtin-blkid.c | 13 -
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/configure.a
In case someone has an idea, here is the full linker command:
/bin/sh ./libtool --tag=CC --mode=link
mipsisa32r2el-axis-linux-gnu-gcc -isystem
/build/target/mipsisa32r2el-axis-linux-gnu/include -isystem
/build/target/mipsisa32r2el-axis-linux-gnu/usr/include -std=gnu99
-pipe -Wall -Wextra -Wno-
On Fri, Dec 12, 2014 at 12:24 AM, Lennart Poettering
wrote:
> On Thu, 11.12.14 23:01, Umut Tezduyar Lindskog ([email protected]) wrote:
>
>> Trying to build 218 but I am getting undefined reference error. The
>> source code of bus-error.c mentions that gcc magically maps these
>> variables but not
Hi,
On Fri, Dec 12, 2014 at 7:56 AM, Matthias Urlichs wrote:
> Hi,
>
> Lennart:
>>
>> The idea is that any .c file linked into a binary can define
>> additional maps, and we collect them all simply by iterating through
>> __start_BUS_ERROR_MAP to __stop_BUS_ERROR_MAP.
>>
> Unless there are none o
What do you think about the following transformations:
[FDBEntry] => [FDBNeigh]
FDBControlled=> FDBCleanTable
VLAN => VLANId
?
When FDBCleanTable is set to yes, networkd will clean the existing FDB entries
for current port and FDBCleanTable will ha
33 matches
Mail list logo
