ncftool manpage
by Serge Hallyn
I added nothing of value here, just turned the 'ncftool help' output
into a ncftool.1 manpage.
thanks,
-serge
.TH NCFTOOL 1 "December 20, 2011"
.SH NAME
ncftool \- Network configuration tool
.SH SYNOPSIS
.B ncftool [options]
.SH DESCRIPTION
ncftool is a command line utility to configure networking.
.SH OPTIONS
.TP
.B list [\-\-macs] [\-\-all] [\-\-inactive]
List the currently configured toplevel network interfaces
.br
.BR [\-\-macs]
show MAC addresses
.br
.BR [\-\-all]
show all (up & down) interfaces
.br
.BR [\-\-inactive]
show only inactive (down) interfaces
.TP
.B dumpxml [\-\-mac] [\-\-live] <name>
Dump the XML description of an interface
.br
.BR [\-\-mac]
interpret the name as MAC address
.br
.BR [\-\-life]
include information about the live interface
.br
.BR <name>
the name of the interface
.TP
.B define <xmlfile>
Define - define an interface from an XML file
.br
.BR <xmlfile>
file containing the XML description of the interface
.TP
.B undefine <iface>
Remove the configuration of an interface
.br
.BR <iface>
the name of the interface
.TP
.B ifup <iface>
Bring up an interface
.br
.BR <iface>
the name of the interface
.TP
.B ifdown <iface>
Bring down an interface
.br
.BR <iface>
the name of the interface
.TP
.B change-begin
Mark the beginning of a set of revertible network config changes
.TP
.B change-commit
Commit (makes permanent) of a set of network config changes
.TP
.B change-rollback
Rollback (revert) a set of network config changes
.TP
.B help [<command>]
List all commands or print details about one command
.br
.BR <command>
If specified, list help about the listed command. Otherwise list all commands.
.TP
.B quit
Exit the program
.TP
.SH SEE ALSO
.BR interfaces (5)
.SH AUTHOR
Serge Hallyn <serge.hallyn(a)ubuntu.com>
11 years, 8 months
netcf patches for debian (v2)
by Serge E. Hallyn
Hi,
Thanks Eric and Laine for your earlier comments. Here is a small
set of 3 cleaner patches which are enough to make netcf build on
debian. (patches on top of git head). I will try my hand at
the autoconf magic needed for libnl support next.
thanks,
-serge
11 years, 9 months
[PATCH 0/5] Initial FreeBSD Support Patches
by Sean Bruno
Its round 1 of our patchsets here in FreeBSD land. This more or less
stubs out the code for FreeBSD support. We will flush out that code in
following patchsets.
11 years, 10 months
[PATCH] Add bundled(gnulib) to RPM specfile
by Laine Stump
According to Fedora guidelines, because we bundle gnulib we
need to add a virtual Provides: bundled(gnulib).
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Requirement...
---
netcf.spec.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/netcf.spec.in b/netcf.spec.in
index cec69c1..234561b 100644
--- a/netcf.spec.in
+++ b/netcf.spec.in
@@ -14,6 +14,8 @@ BuildRequires: libxml2-devel libxslt-devel
BuildRequires: libnl-devel
Requires: %{name}-libs = %{version}-%{release}
+Provides: bundled(gnulib)
+
%description
Netcf is a library used to modify the network configuration of a
system. Network configurations are expressed in a platform-independent
--
1.7.10.1
11 years, 11 months
Re: [netcf-devel] Preparing for freebsd support pull request
by Laine Stump
On 05/14/2012 12:38 PM, Sean Bruno wrote:
> On Thu, 2012-05-10 at 17:53 -0700, Laine Stump wrote:
>> On 05/10/2012 08:07 PM, Sean Bruno wrote:
>>> So, Hiren and I are approaching our first milestone, where we think that
>>> we're feature complete for freebsd. We're working out a few details at
>>> the moment, but its starting to look good.
>>>
>>> In order for you guys to pull from us, what's the standard process for
>>> us to follow such that you can review, accept(and/or reject) and pull
>>> from our tree.
>>>
>>> I assume there's some kind of "generate review-able patches" guidelines
>>> we should follow to make your lives easy.
>> Pretty simple, really - just make sure your patches are on a local git
>> branch that's based off the fedorahosted master branch, and use git
>> send-email --compose -<# of patches>, giving the introductory message
>> the subject [PATCH 0/<# of patches>] <something descriptive> and a short
>> overview.
>>
>> A series of small patches is much better than a single monolithic patch.
>> Especially - if you've done any refactoring of the existing code to make
>> your code fit in better, it would be better to put that first in a
>> separate patch (such that applying it would have 0 functional effect),
>> then your port-specific stuff in later patches.
>>
>> ______________________________________
> Since my git-foo is pretty weak, I'm pretty conservative here.
>
> Should I branch another copy of the the project repo (yours) and apply
> patches from our repo to the new copy and then send the patches from
> that via git-send-email()?
If, when you say "our repo", you mean a git repo that was initially
based from ours, then you can directly do git send-email from that.
Otherwise, here's a full synopsis of the steps that would give you
patches in the right format, while not messing up the "master" branch of
a checkout from the main repo:
git clone git://git.fedorahosted.org/netcf.git
cd netcf
git checkout -b mybranch
(make changes)
git add [modified files]
git commit (with useful commit log message)
[repeat steps 4-6 as needed]
git send email --compose -<number of patches>
(this way, you can later "git checkout master && git pull")
11 years, 11 months
Preparing for freebsd support pull request
by Sean Bruno
So, Hiren and I are approaching our first milestone, where we think that
we're feature complete for freebsd. We're working out a few details at
the moment, but its starting to look good.
In order for you guys to pull from us, what's the standard process for
us to follow such that you can review, accept(and/or reject) and pull
from our tree.
I assume there's some kind of "generate review-able patches" guidelines
we should follow to make your lives easy.
Sean
11 years, 11 months