config4gnu-developer — Config4GNU developers list

Re: [Config4gnu-developer] Problem with sigc++

[C. G. <c.g...@tu...>]

Am Mittwoch, 28. Januar 2004 16:26 schrieb Jason Long:
> It's nice to see this resolved. Perhaps this question should be added to
> the FAQ...

Not sure if the following lines are enough.
It's easy to go to http://linuxwiki.de/Config4Gnu/EnglishFAQ and click on edit 
at the bottom.

There should probably be a little more explanation about the problem than 
there is now:
---
Q: emit clashes with the QT emit !!!

A: simply put the include to sigc++ BEFORE the includes for QT :)

See: http://mail.gnome.org/archives/gnome-kde-list/1999-July/msg00012.html
---

[Config4gnu-developer] Future

[Pierre S. <pi...@so...>]

Hi guys,

I have started a KDE configuration tool but it seems harder than I 
expected :)
I did the bad choice to think a filesystem-like view would be a good 
idea, but I discovered the "folders" can have several properties... so 
using the kio_slaves way is not a good solution probably.

I tried the expand method of the CfgObject => does not seems to work :(
I will try with the CVS version soon.

Furthermore, I successfully compiled the gtkmm configuration tool, but 
it crashes everytime at launch. I will install gtk with debug symbols if 
I am strong enough. Anyway, a friend of mine would like to contribute as 
well maybe, I am trying to convince him.

A first step would be to add comments in the code I think, it would be a 
good idea even if the names of the methods are explicit :)
I will try to add some comments while looking further in the code and I 
will send you my patches.

My friend will probably join as well, so tell us what parts of the lib 
need work since you will have more manpower.

What are your plans ?

Feel free to contact me by IM as well: bad...@ja...

Best Regards.

Pierre Souchay

Re: [Config4gnu-developer] Problem with sigc++

[Jason L. <JL...@me...>]

It's nice to see this resolved. Perhaps this question should be added to the
FAQ...
Jason


>>> Pierre SOUCHAY <pi...@so...> 1/28/04 10:19:16 AM >>>
Hi again,

Ok, I was right in my previous mail...
See: http://mail.gnome.org/archives/gnome-kde-list/1999-July/msg00012.html


emit clashes with the QT emit !!!

The solution explained in the archive is correct, simply put the include 
to sigc++ BEFORE the includes for QT :)

Yet Another Problem Solved :)

I also plan to create a documentation for config4gnu to write frontends 
since the documentation is missing. I will send you the document as soon 
as finished.

Best Regards.

Pierre Souchay

Jason Long wrote:
> Unfortunately, I don't recall seeing the compiler errors you're having.
My
> first thought is that it is incompatible with version 3.3 of gcc, but
that
> seems unlikely.
> 
> I guess my suggestion would be to create a cpp file that only includes
> sigc++.h and see if the compiler errors go away...
> e.g.
> test.cpp:
> =============
> #include <sigc++.h>
> =============
> 
> Furthermore, you could try including the sigc++.h header before you
include
> Config4GNU headers and see if that changes the errors you're getting.
> 
> Now, about your problem with the gtkmm client. Are you getting the same
> errors with that as well?
> 
> Jason
> 
> 
> 
>>>>pi...@so... 1/27/04 8:25:02 AM >>>
> 
> Hi,
> 
> I have compiled config4gnu on my debian testing with gcc3.3 and it 
> works. I use sigc++-1.2 (debian package) and would like to create a 
> client for KDE.
> 
> I know sigc++ is not your library, but maybe you already had similar 
> issues (see at the bottom).
> 
> I cannot compile your gtkmm client neither.
> 
> Best Regards.
> 
> Thanks.
> 
> Pierre Souchay
> 
> 
> In file included from /usr/include/sigc++-1.2/sigc++/sigc++.h:27,
>                   from 
> /home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/CfgObject.h:9,
>                   from 
> /home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/FrontendHelper.h:4,
>                   from konfig4gnu_part.cpp:15:
> /usr/include/sigc++-1.2/sigc++/signal.h:167: error: declaration does not
>     declare anything
> /usr/include/sigc++-1.2/sigc++/signal.h:167: error: parse error before
`)'
>     token
> /usr/include/sigc++-1.2/sigc++/signal.h:171: error: ISO C++ forbids
> defining
>     types within return type
> /usr/include/sigc++-1.2/sigc++/signal.h:171: error: syntax error before
`
>     operator'
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: ISO C++ forbids 
> declaration
>     of `operator()' with no type
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: `int
> SigC::operator()()'
>     must be a nonstatic member function
> /usr/include/sigc++-1.2/sigc++/signal.h: In function `int 
> SigC::operator()()':
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: `impl_' undeclared 
> (first
>     use this function)
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: (Each undeclared 
> identifier
>     is reported only once for each function it appears in.)
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: `emit_' undeclared 
> (first
>     use this function)
> /usr/include/sigc++-1.2/sigc++/signal.h: At global scope:
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: ISO C++ forbids 
> declaration
>     of `Signal0' with no type
> /usr/include/sigc++-1.2/sigc++/signal.h: In function `int
> SigC::Signal0()':
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: `int
SigC::Signal0()'
>     redeclared as different kind of symbol
> /usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous declaration

> of `
>     template<class R, class Marsh> class SigC::Signal0'
> /usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous
non-function
>     declaration `template<class R, class Marsh> class SigC::Signal0'
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: conflicts with
> function
>     declaration `int SigC::Signal0()'
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: only constructors 
> take base
>     initializers
> /usr/include/sigc++-1.2/sigc++/signal.h:176: confused by earlier errors,

> bailing out
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn 
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li... 
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer 
> 

Re: [Config4gnu-developer] Problem with sigc++

[Pierre S. <pi...@so...>]

Hi again,

Ok, I was right in my previous mail...
See: http://mail.gnome.org/archives/gnome-kde-list/1999-July/msg00012.html

emit clashes with the QT emit !!!

The solution explained in the archive is correct, simply put the include 
to sigc++ BEFORE the includes for QT :)

Yet Another Problem Solved :)

I also plan to create a documentation for config4gnu to write frontends 
since the documentation is missing. I will send you the document as soon 
as finished.

Best Regards.

Pierre Souchay

Jason Long wrote:
> Unfortunately, I don't recall seeing the compiler errors you're having. My
> first thought is that it is incompatible with version 3.3 of gcc, but that
> seems unlikely.
> 
> I guess my suggestion would be to create a cpp file that only includes
> sigc++.h and see if the compiler errors go away...
> e.g.
> test.cpp:
> =============
> #include <sigc++.h>
> =============
> 
> Furthermore, you could try including the sigc++.h header before you include
> Config4GNU headers and see if that changes the errors you're getting.
> 
> Now, about your problem with the gtkmm client. Are you getting the same
> errors with that as well?
> 
> Jason
> 
> 
> 
>>>>pi...@so... 1/27/04 8:25:02 AM >>>
> 
> Hi,
> 
> I have compiled config4gnu on my debian testing with gcc3.3 and it 
> works. I use sigc++-1.2 (debian package) and would like to create a 
> client for KDE.
> 
> I know sigc++ is not your library, but maybe you already had similar 
> issues (see at the bottom).
> 
> I cannot compile your gtkmm client neither.
> 
> Best Regards.
> 
> Thanks.
> 
> Pierre Souchay
> 
> 
> In file included from /usr/include/sigc++-1.2/sigc++/sigc++.h:27,
>                   from 
> /home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/CfgObject.h:9,
>                   from 
> /home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/FrontendHelper.h:4,
>                   from konfig4gnu_part.cpp:15:
> /usr/include/sigc++-1.2/sigc++/signal.h:167: error: declaration does not
>     declare anything
> /usr/include/sigc++-1.2/sigc++/signal.h:167: error: parse error before `)'
>     token
> /usr/include/sigc++-1.2/sigc++/signal.h:171: error: ISO C++ forbids
> defining
>     types within return type
> /usr/include/sigc++-1.2/sigc++/signal.h:171: error: syntax error before `
>     operator'
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: ISO C++ forbids 
> declaration
>     of `operator()' with no type
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: `int
> SigC::operator()()'
>     must be a nonstatic member function
> /usr/include/sigc++-1.2/sigc++/signal.h: In function `int 
> SigC::operator()()':
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: `impl_' undeclared 
> (first
>     use this function)
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: (Each undeclared 
> identifier
>     is reported only once for each function it appears in.)
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: `emit_' undeclared 
> (first
>     use this function)
> /usr/include/sigc++-1.2/sigc++/signal.h: At global scope:
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: ISO C++ forbids 
> declaration
>     of `Signal0' with no type
> /usr/include/sigc++-1.2/sigc++/signal.h: In function `int
> SigC::Signal0()':
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: `int SigC::Signal0()'
>     redeclared as different kind of symbol
> /usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous declaration 
> of `
>     template<class R, class Marsh> class SigC::Signal0'
> /usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous non-function
>     declaration `template<class R, class Marsh> class SigC::Signal0'
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: conflicts with
> function
>     declaration `int SigC::Signal0()'
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: only constructors 
> take base
>     initializers
> /usr/include/sigc++-1.2/sigc++/signal.h:176: confused by earlier errors, 
> bailing out
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn 
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li... 
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
> 

Re: [Config4gnu-developer] Problem with sigc++

[Pierre S. <pi...@so...>]

Hi Jason,

Jason Long wrote:
> Unfortunately, I don't recall seeing the compiler errors you're having. My
> first thought is that it is incompatible with version 3.3 of gcc, but that
> seems unlikely.
Yes.

> 
> I guess my suggestion would be to create a cpp file that only includes
> sigc++.h and see if the compiler errors go away...
> e.g.
> test.cpp:
> =============
> #include <sigc++.h>
> =============
OK, it works...

What does not work is the following:

$ cat test.cpp
#include <qobject.h>
#include <FrontendHelper.h>


int main(int argc, char **argv){
         return 0;
}
$ gcc-3.3 -DHAVE_CONFIG_H -I. -I/usr/share/qt3/include -I. -I.. 
-I/opt/include -I/usr/lib/sigc++-1.2/include -I/usr/include/sigc++-1.2 
-I/home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu test.cpp -o /dev/null
In file included from /usr/include/sigc++-1.2/sigc++/sigc++.h:27,
                  from 
/home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/CfgObject.h:9,
                  from 
/home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/FrontendHelper.h:4,
                  from test.cpp:2:
/usr/include/sigc++-1.2/sigc++/signal.h:167: error: declaration does not
    declare anything
/usr/include/sigc++-1.2/sigc++/signal.h:167: error: parse error before `)'
    token
/usr/include/sigc++-1.2/sigc++/signal.h:171: error: ISO C++ forbids defining
    types within return type
/usr/include/sigc++-1.2/sigc++/signal.h:171: error: syntax error before `
    operator'
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: ISO C++ forbids 
declaration
    of `operator()' with no type
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: `int SigC::operator()()'
    must be a nonstatic member function
/usr/include/sigc++-1.2/sigc++/signal.h: In function `int 
SigC::operator()()':
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: `impl_' undeclared 
(first
    use this function)
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: (Each undeclared 
identifier
    is reported only once for each function it appears in.)
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: `emit_' undeclared 
(first
    use this function)
/usr/include/sigc++-1.2/sigc++/signal.h: At global scope:
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: ISO C++ forbids 
declaration
    of `Signal0' with no type
/usr/include/sigc++-1.2/sigc++/signal.h: In function `int SigC::Signal0()':
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: `int SigC::Signal0()'
    redeclared as different kind of symbol
/usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous declaration 
of `
    template<class R, class Marsh> class SigC::Signal0'
/usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous non-function
    declaration `template<class R, class Marsh> class SigC::Signal0'
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: conflicts with function
    declaration `int SigC::Signal0()'
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: only constructors 
take base
    initializers
/usr/include/sigc++-1.2/sigc++/signal.h:176: confused by earlier errors, 
bailing out

----------


In fact, the compiler is confused when I try to include qt and sigc++ !!

Need more investigations... if I remove the line:
#include <qobject.h>

It works... funny. I think it is related to the method emit, but the 
compiler is confused.

emit exist in QT and sigc++ it seems...

Have any idea ?

Thanks for your feedback.

Best Regards.

Pierre Souchay

> 
> Furthermore, you could try including the sigc++.h header before you include
> Config4GNU headers and see if that changes the errors you're getting.
> 
> Now, about your problem with the gtkmm client. Are you getting the same
> errors with that as well?

No other kinds of errors related to gtkmm... but I think I just don't 
have all the needed libraries.
> 
> Jason
> 
> 
> 
>>>>pi...@so... 1/27/04 8:25:02 AM >>>
> 
> Hi,
> 
> I have compiled config4gnu on my debian testing with gcc3.3 and it 
> works. I use sigc++-1.2 (debian package) and would like to create a 
> client for KDE.
> 
> I know sigc++ is not your library, but maybe you already had similar 
> issues (see at the bottom).
> 
> I cannot compile your gtkmm client neither.
> 
> Best Regards.
> 
> Thanks.
> 
> Pierre Souchay
> 
> 
> In file included from /usr/include/sigc++-1.2/sigc++/sigc++.h:27,
>                   from 
> /home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/CfgObject.h:9,
>                   from 
> /home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/FrontendHelper.h:4,
>                   from konfig4gnu_part.cpp:15:
> /usr/include/sigc++-1.2/sigc++/signal.h:167: error: declaration does not
>     declare anything
> /usr/include/sigc++-1.2/sigc++/signal.h:167: error: parse error before `)'
>     token
> /usr/include/sigc++-1.2/sigc++/signal.h:171: error: ISO C++ forbids
> defining
>     types within return type
> /usr/include/sigc++-1.2/sigc++/signal.h:171: error: syntax error before `
>     operator'
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: ISO C++ forbids 
> declaration
>     of `operator()' with no type
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: `int
> SigC::operator()()'
>     must be a nonstatic member function
> /usr/include/sigc++-1.2/sigc++/signal.h: In function `int 
> SigC::operator()()':
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: `impl_' undeclared 
> (first
>     use this function)
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: (Each undeclared 
> identifier
>     is reported only once for each function it appears in.)
> /usr/include/sigc++-1.2/sigc++/signal.h:172: error: `emit_' undeclared 
> (first
>     use this function)
> /usr/include/sigc++-1.2/sigc++/signal.h: At global scope:
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: ISO C++ forbids 
> declaration
>     of `Signal0' with no type
> /usr/include/sigc++-1.2/sigc++/signal.h: In function `int
> SigC::Signal0()':
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: `int SigC::Signal0()'
>     redeclared as different kind of symbol
> /usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous declaration 
> of `
>     template<class R, class Marsh> class SigC::Signal0'
> /usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous non-function
>     declaration `template<class R, class Marsh> class SigC::Signal0'
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: conflicts with
> function
>     declaration `int SigC::Signal0()'
> /usr/include/sigc++-1.2/sigc++/signal.h:175: error: only constructors 
> take base
>     initializers
> /usr/include/sigc++-1.2/sigc++/signal.h:176: confused by earlier errors, 
> bailing out
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn 
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li... 
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
> 

[Config4gnu-developer] Re: [devel] KNetworkConf

[Jason L. <JL...@me...>]

Confirmed... there are no meta-config definition for network config files
available at this time.
Jason


>>> c.g...@tu... 1/26/04 9:14:35 AM >>>

Thanks for  the links Juan Luis.

> I have looked at GFG site but didn't find any info about configuring the
> network, only about configuring servers like apache, samba,etc. Could
you
> point me into the right place please?

I'll try and CC the CFG list.

Generally all settings are kept in config files. The network config too. To

make those setings accessible with CFG it needs meta-config definitions for

those network config files. A meta-config file says which syntax parser 
backend CFG has to use to access a particular config -file or -database.
The 
meta-config file then describes the options available in the file and 
associates them into properties of "configuration nodes" in the CFG 
representation. Finaly the meta-config definition also tells CFG how to 
activate changes in the running system.

Additionally the meta-config files can define forms and wizard logic for 
setting of mulipe properties in CFG in frontends.

Now for example Debian and Mandrake use different "network" packages and 
config files. In the future both packages (the .deb and .rpm in which they

are distributed) should come with meta-config files included. Their 
meta-config files will have some differences but the representation of the

settings in CFG (IPs, netmasks etc.) is exactly the same.

AFAIK there is unfortunately no meta-config definition for network config 
files available yet.

Has somebody on the list done somthing in this direction?

Listmembers please check out the Feature requests on sf.net I would also
like 
to see a little more info on how to put CFG to use with additional packages

(contribute meta-configs).


> Anyway, I'll have to look if it's worth the effort to migrate to CFG, as
> GST seems to be doing the things knetworkconf needs pretty well. In any
> case I don't think it should be too hard to migrate to CFG if needed.

Great if it is not too hard to do. For the moment in your place I would
also 
stick to GST, and get a little familiar with CFG concepts since I too think

the more modular framework is the way to go for the future. It has many 
advantages especially for development, distribution and maintanance.


All the best,
Christian



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn 
_______________________________________________
Config4gnu-developer mailing list
Con...@li... 
https://lists.sourceforge.net/lists/listinfo/config4gnu-developer

Re: [Config4gnu-developer] Problem with sigc++

[Jason L. <JL...@me...>]

Unfortunately, I don't recall seeing the compiler errors you're having. My
first thought is that it is incompatible with version 3.3 of gcc, but that
seems unlikely.

I guess my suggestion would be to create a cpp file that only includes
sigc++.h and see if the compiler errors go away...
e.g.
test.cpp:
=============
#include <sigc++.h>
=============

Furthermore, you could try including the sigc++.h header before you include
Config4GNU headers and see if that changes the errors you're getting.

Now, about your problem with the gtkmm client. Are you getting the same
errors with that as well?

Jason


>>> pi...@so... 1/27/04 8:25:02 AM >>>
Hi,

I have compiled config4gnu on my debian testing with gcc3.3 and it 
works. I use sigc++-1.2 (debian package) and would like to create a 
client for KDE.

I know sigc++ is not your library, but maybe you already had similar 
issues (see at the bottom).

I cannot compile your gtkmm client neither.

Best Regards.

Thanks.

Pierre Souchay


In file included from /usr/include/sigc++-1.2/sigc++/sigc++.h:27,
                  from 
/home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/CfgObject.h:9,
                  from 
/home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/FrontendHelper.h:4,
                  from konfig4gnu_part.cpp:15:
/usr/include/sigc++-1.2/sigc++/signal.h:167: error: declaration does not
    declare anything
/usr/include/sigc++-1.2/sigc++/signal.h:167: error: parse error before `)'
    token
/usr/include/sigc++-1.2/sigc++/signal.h:171: error: ISO C++ forbids
defining
    types within return type
/usr/include/sigc++-1.2/sigc++/signal.h:171: error: syntax error before `
    operator'
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: ISO C++ forbids 
declaration
    of `operator()' with no type
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: `int
SigC::operator()()'
    must be a nonstatic member function
/usr/include/sigc++-1.2/sigc++/signal.h: In function `int 
SigC::operator()()':
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: `impl_' undeclared 
(first
    use this function)
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: (Each undeclared 
identifier
    is reported only once for each function it appears in.)
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: `emit_' undeclared 
(first
    use this function)
/usr/include/sigc++-1.2/sigc++/signal.h: At global scope:
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: ISO C++ forbids 
declaration
    of `Signal0' with no type
/usr/include/sigc++-1.2/sigc++/signal.h: In function `int
SigC::Signal0()':
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: `int SigC::Signal0()'
    redeclared as different kind of symbol
/usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous declaration 
of `
    template<class R, class Marsh> class SigC::Signal0'
/usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous non-function
    declaration `template<class R, class Marsh> class SigC::Signal0'
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: conflicts with
function
    declaration `int SigC::Signal0()'
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: only constructors 
take base
    initializers
/usr/include/sigc++-1.2/sigc++/signal.h:176: confused by earlier errors, 
bailing out



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn 
_______________________________________________
Config4gnu-developer mailing list
Con...@li... 
https://lists.sourceforge.net/lists/listinfo/config4gnu-developer

[Config4gnu-developer] Problem with sigc++

[Pierre S. <pi...@so...>]

Hi,

I have compiled config4gnu on my debian testing with gcc3.3 and it 
works. I use sigc++-1.2 (debian package) and would like to create a 
client for KDE.

I know sigc++ is not your library, but maybe you already had similar 
issues (see at the bottom).

I cannot compile your gtkmm client neither.

Best Regards.

Thanks.

Pierre Souchay


In file included from /usr/include/sigc++-1.2/sigc++/sigc++.h:27,
                  from 
/home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/CfgObject.h:9,
                  from 
/home/pierre/apps/config4gnu-0.1.8/src/libconfig4gnu/FrontendHelper.h:4,
                  from konfig4gnu_part.cpp:15:
/usr/include/sigc++-1.2/sigc++/signal.h:167: error: declaration does not
    declare anything
/usr/include/sigc++-1.2/sigc++/signal.h:167: error: parse error before `)'
    token
/usr/include/sigc++-1.2/sigc++/signal.h:171: error: ISO C++ forbids defining
    types within return type
/usr/include/sigc++-1.2/sigc++/signal.h:171: error: syntax error before `
    operator'
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: ISO C++ forbids 
declaration
    of `operator()' with no type
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: `int SigC::operator()()'
    must be a nonstatic member function
/usr/include/sigc++-1.2/sigc++/signal.h: In function `int 
SigC::operator()()':
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: `impl_' undeclared 
(first
    use this function)
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: (Each undeclared 
identifier
    is reported only once for each function it appears in.)
/usr/include/sigc++-1.2/sigc++/signal.h:172: error: `emit_' undeclared 
(first
    use this function)
/usr/include/sigc++-1.2/sigc++/signal.h: At global scope:
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: ISO C++ forbids 
declaration
    of `Signal0' with no type
/usr/include/sigc++-1.2/sigc++/signal.h: In function `int SigC::Signal0()':
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: `int SigC::Signal0()'
    redeclared as different kind of symbol
/usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous declaration 
of `
    template<class R, class Marsh> class SigC::Signal0'
/usr/include/sigc++-1.2/sigc++/signal.h:144: error: previous non-function
    declaration `template<class R, class Marsh> class SigC::Signal0'
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: conflicts with function
    declaration `int SigC::Signal0()'
/usr/include/sigc++-1.2/sigc++/signal.h:175: error: only constructors 
take base
    initializers
/usr/include/sigc++-1.2/sigc++/signal.h:176: confused by earlier errors, 
bailing out

[Config4gnu-developer] Re: [devel] KNetworkConf

[C. G. <c.g...@tu...>]

Thanks for  the links Juan Luis.

> I have looked at GFG site but didn't find any info about configuring the
> network, only about configuring servers like apache, samba,etc. Could you
> point me into the right place please?

I'll try and CC the CFG list.

Generally all settings are kept in config files. The network config too. To 
make those setings accessible with CFG it needs meta-config definitions for 
those network config files. A meta-config file says which syntax parser 
backend CFG has to use to access a particular config -file or -database. The 
meta-config file then describes the options available in the file and 
associates them into properties of "configuration nodes" in the CFG 
representation. Finaly the meta-config definition also tells CFG how to 
activate changes in the running system.

Additionally the meta-config files can define forms and wizard logic for 
setting of mulipe properties in CFG in frontends.

Now for example Debian and Mandrake use different "network" packages and 
config files. In the future both packages (the .deb and .rpm in which they 
are distributed) should come with meta-config files included. Their 
meta-config files will have some differences but the representation of the 
settings in CFG (IPs, netmasks etc.) is exactly the same.

AFAIK there is unfortunately no meta-config definition for network config 
files available yet.

Has somebody on the list done somthing in this direction?

Listmembers please check out the Feature requests on sf.net I would also like 
to see a little more info on how to put CFG to use with additional packages 
(contribute meta-configs).


> Anyway, I'll have to look if it's worth the effort to migrate to CFG, as
> GST seems to be doing the things knetworkconf needs pretty well. In any
> case I don't think it should be too hard to migrate to CFG if needed.

Great if it is not too hard to do. For the moment in your place I would also 
stick to GST, and get a little familiar with CFG concepts since I too think 
the more modular framework is the way to go for the future. It has many 
advantages especially for development, distribution and maintanance.


All the best,
Christian

Re: [Config4gnu-developer] My WBEM obsession

[<p.c...@ar...>]

> Lately I've been spending a large proportion of my free coding time working
> on WBEM and configuration. I felt it was necessary to share what I've been
> working on to find out if anyone else finds it as interesting as I do :).

Thank you for your info. 
I don't know much about WBEM, but here are my general thoughts:

WBEM seems an interesting approach, however commercial and not community driven.
WBEM seems to be just another way for config representation and modification,
it has also a XML representation spec.
Currently CFG uses an own XML format for that that can include help texts,
comments, forms, wizards. In the future more maybe added, for example icons etc.

CFG will need to use one format natively that can accomplish all
requirements for CFG goals. 

In order to provide other formats "interface frontends" can do
the translation between CFGs format and others like LDAP, WBEM etc.

In order to access and modify other formats CFG would need a backend (parser)
for that. With them configurations in LDAP, WBEM or others can be browsed
and modified though CFG.


OK, now to CFGs native format. I think it needs to be a free standard.
(No threat of patent bombs, possibility to get something upstream etc.)
If the current handling of XML data is seen as not so nice D-BUS
http://freedesktop.org/Software/dbus can be a nice common way to pass
parts of the XML representation back and forth. (see tutorial)

Of course there could be some standardization between projects. Projects
with similar XML formats include KDSs .cfg files and ROXs options.xml
GST also?

Re: [Config4gnu-developer] important negatives to adress ASAP

[<p.c...@ar...>]

> > 4) There is more to configuring a running system than just editing
> > config
> > files. What about starting/stopping daemons? Creating and clean up of
> > user
> > accounts? querying the status of services?
 
> This is one of the reasons I've been looking at different approaches,
> including CORBA and WBEM. There are ways these things can be accomplished
> by
> continuing to pass XML back and forth, but it just starts to get clunky in
> my opinion.

My guess is that the init process itself will undergo some renewal
in the future as it is definitely too slow in startup and limited anyway.

On the other hand I don't think CFG needs or should expose this
functionality to frontends explicitly. It just needs to activate a change
commited by a frontend transparently according to the meta-config entity
affected.
For CFG this will probably just need to be a little command line to execute.

Managing user accounts is editing /etc/passwd and activation with useradd/del
with some additional meta-variables like "delete homedir of removed user".

Managing the startup configuration of services itself (sys V) would primarily
need a /etc/init.d directory parser for CFG.


> > 5) The real work is not parsing of writing files, it is doing all the
> > little jobs like finding
> > out where exactly each distro stores their network config for example and
> > in what format.

> [...]The idea is that
> once we made [file access]easy and had other parts of the framework in
> place,
> then we would go around and add support for many distributions and
> applications.

Most of this should not be necessary in the end, packages for particular
distributions ship with meta data tailored to their distro (file location).
In what format that distro stores its network config is irrelevant because
it is accassible through CFG in the same way on all distros. (CFG
network support meta-data comes with the distributions network package.
(Or with the CFG package itself in the meantime.))



All in all I think CFG has already been magnificently thought through and mostly needs some employment now to make its beauty more obvious.

Assuming a little polish for release and third party meta-data additions is done.

 

[Config4gnu-developer] My WBEM obsession

[Jason L. <JL...@me...>]

Lately I've been spending a large proportion of my free coding time working
on WBEM and configuration. I felt it was necessary to share what I've been
working on to find out if anyone else finds it as interesting as I do :).

I have prepared a web page, complete with information about WBEM,
screenshots, and download links. Enjoy.

http://jason.long.name/config4gnu-wbem/index.html


If you try to download/install the software yourself, I wouldn't be
terribly surprised if you encounter problems. I encountered several issues
when I did several weeks ago, and I couldn't remember them all to give
appropriate warnings in my directions. So, please feel free to ask me about
any issues you encounter... it may be something that I encountered myself
and know how to fix.

Jason Long

Re: [Config4gnu-developer] important negatives to adress ASAP

[Jason L. <JL...@me...>]

These are all very good points. In fact, they very much echo a lot of my
concerns about the project. I'll try to comment on some of those points...

> 2) Development seems to have stopped or slowed considerably.

Agreed. Actually, I've been doing coding but it's on my side-project
playing with WBEM. I'll send a separate email explaining what I've been
doing with that.

> 3) Yet another dependency.

It is. Finding the balance between not reinventing the wheel and not having
unnecessary dependencies is difficult. I have already stated that I'm tired
of the Xerces dependency (XML library) and would like to use the more
commonly installed libxml2 library instead. Unfortunately, the two libraries
use significantly different APIs, so it will require a bit of coding to do
that.

> 4) There is more to configuring a running system than just editing
config
> files. What about starting/stopping daemons? Creating and clean up of
user
> accounts? querying the status of services?

This is one of the reasons I've been looking at different approaches,
including CORBA and WBEM. There are ways these things can be accomplished by
continuing to pass XML back and forth, but it just starts to get clunky in
my opinion.

> 5) The real work is not parsing of writing files, it is doing all the
little jobs like finding
> out where exactly each distro stores their network config for example and
in what
> format. See point 1).

That is true. However, there needs to be some sort of established framework
for doing the parsing and writing of files. I'm not sure if one exists. So,
Config4GNU got started with the intention of making it easy to
programmatically implement changes to configuration files without worrying
about what format the configuration file is in. I know the libconf project
started out the same way, using some different techniques. The idea is that
once we made that part easy and had other parts of the framework in place,
then we would go around and add support for many distributions and
applications.

> 6) I can't imagine that hacking on a new framework/code base written in
C
> and Perl, and then trying to get everything working across 3 different
> languages is going to be faster or easier than just continuing to code in
Python.

Our parsers, written in Perl, currently link to our main Config4GNU
library, written in C++. Sometimes I'm amazed this actually works. And I
have to imagine that it will be difficult trying to port it to some other
platforms, where the C++ compiler acts differently or shared libraries act
differently...

Working completely in one language has its advantages, for sure. However,
it seems all too common that things get reimplemented in a given language
rather than use existing libraries/modules written in other languages. This
is because the work to link those different languages together (and the
resulting dependency issues) is much more work than just reimplementing the
code.

One of my goals with the Config4GNU project (I can't remember if this is
actually listed on the website) is to create a system where people can write
various parts of the system (parsers, front-ends, etc.) in whatever language
they prefer or need to do the task. Configuration files are not always
stored in text files on the local system. Sometimes you might actually need
to load a library in order to read/write configuration of a specific sort.
If you tie yourself to a certain language, you may have to reimplement that
library to get at that configuration.

Unfortunately, Config4GNU's way of programming language independence is
very limited. In my opinion it is going to take quite some time to truely
attain the kind of programming language independence that I would like to
see.

--

Ok, this email is getting a little long. Peter, your suggestion about
having a development weekend is great. That's exactly the sort of think that
I personally would need to help feel more focused and optimistic about this
project. Justin-- what are the chances we could actually make time to get
together and do some coding? :)

Jason




>>> p.c...@ar... 1/16/04 10:30:26 AM >>>

Hi,

I think the feedback gave a valuable insight into how CFG in perceived.
Some
things have to be dealt with coding some with information. I can't code
but I can start a wiki page on freedesktop.org end of next month. I can
adress some points, but for other things I would need some base for a
start.

A good idea I saw at the skolelinux project is to schedule a
development weekend. It showed ppl realy like to hook up and work
together even meet if possible rather than just kind of
lonely, individually.

Planning a weekend aiming for a test-suite release, some examples,
and basic notes on how to add support (meta-data) for more apps can be a
good idea. (Maybe additionally providing staticaly linked binaries for
easy testing  might be a viable workaround for the moment as long as
some depreciated dependencies can't be removed)

 
> 1) Incomplete, the framework appears to exist but without backends and
>  support for the things that need to do right, it's not very helpful.

=> Testing release with a meta-data directory standard for additions,
plus an initial quick guide how to support additional apps? (Also
continous collaboration of testers and users on improving that guide
on the wiki and documenting experiences.)


RFC on the following points. Are they just not perceived right? What is
actually already solved in CFG?

> 2) Development seems to have stopped or slowed considerably.
> 
> 3) Yet another dependency.
> 
> 4) There is more to configuring a running system than just editing
config
> files. What about starting/stopping daemons? Creating and clean up of
user
> accounts? querying the status of services?
> 
> 5) The real work is not parsing of writing files, it is doing all the
> little
> jobs like finding out where exactly each distro stores their network
config
> for example and in what format. See point 1).
> 
> and finally:
> 
> 6) I can't imagine that hacking on a new framework/code base written in
C
> and
> Perl, and then trying to get everything working across 3 different
> languages
> is going to be faster or easier than just continuing to code in Python.







-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn 
_______________________________________________
Config4gnu-developer mailing list
Con...@li... 
https://lists.sourceforge.net/lists/listinfo/config4gnu-developer

Re: [Config4gnu-developer] important negatives to adress ASAP

[<p.c...@ar...>]

Hi,

I think the feedback gave a valuable insight into how CFG in perceived. Some
things have to be dealt with coding some with information. I can't code
but I can start a wiki page on freedesktop.org end of next month. I can
adress some points, but for other things I would need some base for a
start.

A good idea I saw at the skolelinux project is to schedule a
development weekend. It showed ppl realy like to hook up and work
together even meet if possible rather than just kind of
lonely, individually.

Planning a weekend aiming for a test-suite release, some examples,
and basic notes on how to add support (meta-data) for more apps can be a
good idea. (Maybe additionally providing staticaly linked binaries for
easy testing  might be a viable workaround for the moment as long as
some depreciated dependencies can't be removed)

 
> 1) Incomplete, the framework appears to exist but without backends and
>  support for the things that need to do right, it's not very helpful.

=> Testing release with a meta-data directory standard for additions,
plus an initial quick guide how to support additional apps? (Also
continous collaboration of testers and users on improving that guide
on the wiki and documenting experiences.)


RFC on the following points. Are they just not perceived right? What is
actually already solved in CFG?

> 2) Development seems to have stopped or slowed considerably.
> 
> 3) Yet another dependency.
> 
> 4) There is more to configuring a running system than just editing config
> files. What about starting/stopping daemons? Creating and clean up of user
> accounts? querying the status of services?
> 
> 5) The real work is not parsing of writing files, it is doing all the
> little
> jobs like finding out where exactly each distro stores their network config
> for example and in what format. See point 1).
> 
> and finally:
> 
> 6) I can't imagine that hacking on a new framework/code base written in C
> and
> Perl, and then trying to get everything working across 3 different
> languages
> is going to be faster or easier than just continuing to code in Python.

[Config4gnu-developer] important negatives to adress ASAP

[C. G. <c.g...@tu...>]

Hello,
here is, as I think a very valuable feedback from somebody who looked into CFG 
but choose to reimplement from scratch anyway.


Subject: Re: Don't implement config functionality (hardcoding Config Tools)
Date: Donnerstag, 15. Januar 2004 21:59
To: kde...@kd...
----------  
> _Even_ if config4gnu would not present more than keys and values to
> frontends, or if a programmer does not want to make use of the provided
> forms and wizard
> stuctures, it is still beneficial to use config4gnu as backend.

Yes, it would be.

> If you don't think so and are working on or intending to write and maintain 
> a config tool, I think the time spent grasping how well config4gnu is
> designed is very worthwhile can actually save a real lot of time in the
> long run. The more fun part of implementing cool frontends can stay but the
> work implementing specifics should be put and shared in the CFG layer
> between apps.

I've had a good look at CFG over the last few days.

My position is this: I've got a User&Group util that depends on libuser.
libuser is only used on Redhat and Mandrake at the moment, and doesn't appear
to be developed much these days. (It doesn't even have a real home page, just
CVS). It is also sub-1.0. So I'm thinking of replacing it with something else
(probably python code). I also have a daemon/system service util that works
well on Mandrake and needs to be ported to Debian. (It looks easy enough
judging from Knoppix). I also have a mount util that is half done (/etc/fstab
is no problem, most of the work in GUI based). Those are the kinds of
problems that I'm facing.

My conclusions about CFG:

1) Incomplete, the framework appears to exist but without backends and
 support for the things that need to do right, it's not very helpful.

2) Development seems to have stopped or slowed considerably.

3) Yet another dependency.

4) There is more to configuring a running system than just editing config
files. What about starting/stopping daemons? Creating and clean up of user
accounts? querying the status of services?

5) The real work is not parsing of writing files, it is doing all the little
jobs like finding out where exactly each distro stores their network config
for example and in what format. See point 1).

and finally:

6) I can't imagine that hacking on a new framework/code base written in C and
Perl, and then trying to get everything working across 3 different languages
is going to be faster or easier than just continuing to code in Python.

cheers, thanks for your input though.

--
Simon Edwards             | Guarddog Firewall
si...@si...       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."

-------------------------------------------------------

[Config4gnu-developer] Re: [rox-devel] menu-click configure an App

[<p.c...@ar...>]

Thomas Leonard wrote:
> On Wed, Jan 07, 2004 at 12:41:14AM +0100, p.c...@ar... wrote:
> > 
> > Hello! 
> > Would anybody like to have a "Configure" menu entry for appropriate apps
> > and like to hack on config4gnu for that?
> > 
> > Config4gnu (or CFG for short) takes a meta-config-definition file for an
> > app and can then be used with generic fronteds (command line, GUI, etc.)
> > to configure every option of that app.
> 
> We already have a similar system (Options.xml) which describes the GUI for
> the options. What is the advantage to using C4G for this?

Amazing, no matter how sweet the candy one wants, rox has already got it! ;-)

(Looking through the wiki I also liked AppDirs, see my other post)

Seriously though, nice Options!

I will try to provide a rough comparison to CFG:

As CFGs primarily focus is on configuring arbitrary system settings or services it offers support for different config file formats. In a CFG XML meta-config-definition file (analogous to Options.xml) there is also a file format specified. For example "INI-style" for smb.conf (samba fileserver). CFGs meta-config-definition files do not primarily define the GUI but the config file semantics and which syntax parser to use.

If used in applications like the rox-options the analogous to rox.setup_app_options() in CFG would, in this example, accesses the settings in /etc/smb.conf.

To general configuration tool frondends all config files known by CFG are presented on a per option grained level in an XML-tree no matter what format the file has and where it resides. Each option with possible values, defaults, comments and optionally additional info from man pages etc. Multipurpose Frondends are basically only XML editors that comunicate with CFGs middlelayer. See the screenshots:
http://config4gnu.sourceforge.net/screenshots
A speciality are forms and wizards that can be defined in meta-config-definitons to describe a generic GUI or wizards to create new configuration entities like for example new samba shares.

-Peter




CFG Project Goals
-------------

- Provide multiple interfaces (command line, web-based, GUI, LDAP, etc.) that allow users/admins to modify configuration, with relevant documentation (man pages, etc.) integrated into the interface.

- Allow developers to easily create configuration interfaces for their software which will be automatically recognized by our system when the software is installed.

- Standardize the different types of configuration files (INI-style, flat/delimited text, Apache-style, etc.) and provide parsers and unparsers for all styles.

- Include ways for different OS's and distributions to tailor the system to their needs.

- Retain the native human-editable config files in /etc as the authoritative copy of system configuration and avoid mangling comments and indentation.

- Create a system which is general enough to allow a high level of flexibility but also specialized enough so that the specific task of configuration can be done efficiently.



Advantages of the CFG Project
-----------------------

 Everyone knows there are many other configuration tools for Linux, the most popular of which are Webmin and Linuxconf. Each distribution also often creates their own config tools, and many software projects provide config tools (SWAT for Samba, etc.). This results in duplicated work and inconsistent, buggy interfaces that constantly need to be re-written. 


The CFG Project changes this. Our system is based a three-tier approach with a powerful and flexible middle layer that handles the details and joins the backends which parse and unparse the config files with the frontends which provide various ways for users to edit their configuration. All this is done using XML to exchange data and the behavior is controlled by special meta-configuration files which determine how the middle layer behaves for each specific configuration task. 


That means in order to alter or extend our system, you simply add a new or updated meta-configuration file and the system recognizes it automatically without having to recompile or re-write any parts of the layers themselves. In that sense, software developers may think of our system as a type of sophisticated API they can use to configure their software. We plan to create tools to make it easy for developers to write meta-configuration files for existing software. 


End users never need to worry about all of this, since we hope software projects and distributions will take some or all of the responsibility for maintaining the meta-configuration files once the initial versions have been created by us. Users will only see a single consistent interface using their choice of frontends, while still being able to edit the config files by hand at times. 

Re: [Config4gnu-developer] Looking at WBEM again

[Jason L. <JL...@me...>]

I'm sorry you didn't get any response to your earlier questions. I have been
very inconsistent with keeping up with the mailing list. If I have time
later today I'll go back and see if it's something I can respond to.

Concerning the current CFG... I'm definitely not ready to just "scrap" it
in favor of something different. However, it is true that I haven't been
working on it for a while, and I'm personally not sure what I want to do
with it next. One thing Justin and I have discussed is using a different XML
parser so we can lose the Xerces dependency. For instance, libxml2 is an
alternate parser that has a much wider install base. It would make it easier
for people to get started with the project because it would be one less
dependency to satisfy.

Jason


>>> "C. Gatzemeier" <c.g...@tu...> 1/8/04 7:36:28 PM >>>
Am Donnerstag, 8. Januar 2004 19:26 schrieb Jason Long:
> I just wanted to comment on what I've been up to lately...
>
> Currently I'm revisiting the idea of using WBEM, [...] using
> WBEM would require a radically different middle layer and front-end than
> the current Config4GNU project has.

Hmmm, good to know someone is at least thinking of CFG. I aked a few
questions 
trying to contribute some meta config definitions  some time ago and saw
some 
more questions with no response. 

That said, it feels like you want to scrap CFG for version 2 before
becoming a 
little more testable and releasable.

Re: [Config4gnu-developer] Looking at WBEM again

[C. G. <c.g...@tu...>]

Am Donnerstag, 8. Januar 2004 19:26 schrieb Jason Long:
> I just wanted to comment on what I've been up to lately...
>
> Currently I'm revisiting the idea of using WBEM, [...] using
> WBEM would require a radically different middle layer and front-end than
> the current Config4GNU project has.

Hmmm, good to know someone is at least thinking of CFG. I aked a few questions 
trying to contribute some meta config definitions  some time ago and saw some 
more questions with no response. 

That said, it feels like you want to scrap CFG for version 2 before becoming a 
little more testable and releasable.

[Config4gnu-developer] Looking at WBEM again

[Jason L. <JL...@me...>]

I just wanted to comment on what I've been up to lately...

Currently I'm revisiting the idea of using WBEM (see
http://www.dmtf.org/standards/wbem) for configuration. I had stumbled
across IBM's SBLIM project (http://www-124.ibm.com/sblim/) and found out
that it's possible to write WBEM providers in Perl. Unfortunately, using
WBEM would require a radically different middle layer and front-end than the
current Config4GNU project has.

Jason

Re: [Config4gnu-developer] Meeting to discuss short-term goals

[<p.c...@ar...>]

 
> 6) what projects to try to get support/collaboration with

A new idea might be hardware detection or autoconfigure projects. They generally need to do something with configfiles, too. Haven't been involved with this but discover, kudzu, or even debconf seem to be potential projects.

They could ease their config editing using CFG. Additionally debconf's stored settings could become accessible from CFG frontends. Or might there even be a better way to combine debconf and cfg? 

Re: [Config4gnu-developer] Meeting to discuss short-term goals

[<p.c...@ar...>]

> Jason and I have decided to hold a meeting to discuss our goals for the next
> couple of months.  I think we're at a pretty important point where we need
> to get certain things moving or we'll miss out on some great opportunities.

That is really great. I would like to just add some thought here.

> 3) exactly what roles we want to try to encourage other people to help out
> with (i.e., communicating w/ other projects, website upkeep, testing w/
> various config files, development, etc.)

I guess mostly someone needs to feel an itch in the first place. The good thing with using a wiki is that if someone asks a question on the list and you or anybody else can answer quickly the person can at the same time be kindly asked to document it in the wiki if it was of help for him. Likely they will do it, it is not hard at all. This way answering emails can improve documentation directly and be itself encouraged more, too.

To get an idea see the FAQ that is available and editable at http://linuxwiki.org/Config4Gnu/EnglishFAQ for now. Same could be done with HOWTOs etc.

(To be able to easily convert "plain" wiki content to html, docbook, tex etc. ReStucturedText wikis i.e. http://www.zwiki.org or conversion tools might be interesting.)

> 5) features we NEED to have vs features we WANT to have.  We need to get CFG
> completely usable asap, fancy features we personally would like to see
> should wait until thats accomplished, as painful as that may be.

Good, that is what i personaly feel is the most pressing. Release of 0.4.0 (to follow the popular scheme ;-) or higher if you feel like it for people to use,  test and write meta-defs and thereby asking questions and giving experience. A little more how-to might be necessary for a start though (->wiki again).

> 
> 6) what projects to try to get support/collaboration with

I looked at the autopackage projected mentioned here earlier for a distribution neutral package format. Is cfg meta-data already able to be used in such a way? Distribution specific things like /etc/sysconfig/network or whatever will still have to include their meta-data in their own distributions package (deb, rpm, etc.).

However for basic distribution specific things like the network config do you see a way to harmonize at least the way they are configured within cfg? Say, to have the same nodes and properties in the xml representation. All the different distros have mostly the same options i.e. IP, Network, Mask, or auto (DHCP) etc. anyway.

cheers,
-Peter

Re: [Config4gnu-developer] Meeting to discuss short-term goals

[C. G. <c.g...@tu...>]

Hello everybody,

Thanks for posting a list of goals to discuss, and I would like to put some 
ideas on the table.
Maybe it is possible to let the project be a little more self organizing in 
some way by freshing up the website a litte (don't think it needs to change 
much, actually think it is pretty good) enhancing:

- graspability of the Project

A nice website example for a transparent development process and status I saw 
is the http://autopackage.org project, their website can give good ideas. 
(For example nice FAQ, coloured schedule, changelog, distinguish users/
developers informational needs (even before stable 1.0), ...)

- give some more orientation to help:

1. Classic Documentation (i.e. the good docs and specs that are already on the 
website)
2. community information repository (wiki),
3. bug/rfe tracking
4. Discussion  (Mailinglist/gmane-news)

The overall idea beeing to inform the interested and make it as easy as 
possible to contibute (wiki or feedback being the easy entry line to cross). 
And ask for it in a direct way

A more genaral article that might be interesting to skim:
http://www.onlamp.com/pub/a/onlamp/2003/12/11/myths.html


> Unless we can find a good/cheap way to get voice to/from other people
> (relatively easy if its just 1 other person), we're thinking we'll just
> discuss amongst ourselves, and then write up a summary of the meeting for
> everyone to digest & comment on.

Great. Looking forward to it

Oh, and I would like to hope there are some more people out there who would 
like to make some first cfg meta-config definitions for new apps. I was not 
able to do it yet, hence I asked before. Would you say it could be done 
without programming experience (just the xml-definitions part) at all?

All the best,
Christian

[Config4gnu-developer] Meeting to discuss short-term goals

[Justin Y. <ju...@sk...>]

First, Peter, thank you for your enthusiasm for CFG.  Keep it coming.  I assure you that both myself and Jason get excited about it, and its very encouraging to see others feel the same.

Jason and I have decided to hold a meeting to discuss our goals for the next couple of months.  I think we're at a pretty important point where we need to get certain things moving or we'll miss out on some great opportunities.  

Since Jason and I live about a mile or so apart, we're probably going to have it face-to-face.  However, we'd also like to get input from other people interested in CFG's future.  If any such people are in the Mechanicsburg, PA area, let one/both of us know and maybe we can figure something out for a slightly larger meeting.

Unless we can find a good/cheap way to get voice to/from other people (relatively easy if its just 1 other person), we're thinking we'll just discuss amongst ourselves, and then write up a summary of the meeting for everyone to digest & comment on.

If anyone would like to suggest ideas or things that should be addressed, I'd say post them to the list and we'll include them in our discussion and put responses as part of our meeting summary.

Some things we're planning on talking about:

1) getting CFG cleaned up so it can be used & installed by more or less normal users.

2) dependencies, mainly what XML library/libraries to use, whether to try to allow perl modules to parse XML w/o main CFG library (there are some logistical issues w/ our current design here)

3) exactly what roles we want to try to encourage other people to help out with (i.e., communicating w/ other projects, website upkeep, testing w/ various config files, development, etc.)

4) coordination of CVS (code/website) commits, specifically tracking changes once commit rights are given out to others who are significantly contributing (i.e., Peter)

5) features we NEED to have vs features we WANT to have.  We need to get CFG completely usable asap, fancy features we personally would like to see should wait until thats accomplished, as painful as that may be.

6) what projects to try to get support/collaboration with


Justin


On Fri, 12 Dec 2003 16:13:17 +0100 (CET)
p.c...@ar... wrote:

> 
> Hi,
> look at the debian wiki they too think about cfg and would look
> forward to it. Please let us not seem like rejecting any incoming
> interest or being stalled. http://wiki.debian.net/index.cgi?DebConf 
> 
> IMHO priority should really be to push CFG now. Testability and
> usability contributeability. Document how to easily write a basic
> meta-config-definition and get CFG support.
> 
> To make it easier for all to do somthing for the project we could use
> a wiki somewhere. For example the FAQs I submitted last week could be
> gathered there in a contributing way much easier and with less hassle
> for you. Any ideas about a proper location?
> 
> -Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 


-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

[Config4gnu-developer] First actual message in news.gmane.org

[<p.c...@ar...>]

Actually, _this_ will be the first message to go to gmane.org (just got the confirmation).

From now on config4gnu-develper is accessible via browser or your favorite newsgroup-client from news.gmane.org! gmane.comp.sysutils.cfg.devel is fully searchable has anti-spam measures and more. (see http://gmane.org)

A listadmin should add the old messages to gmane when the Archive on Sourcforge with all messages up to today gets available. It is simple and described at http://gmane.org/import.php

After that please update the website to point to gmane instead of sf, too.

cheers,
-Peter

Re: [Config4gnu-developer] sf.net mailinglist archive not functional, add to gmane.org

[<p.c...@ar...>]

Hi,

The config4gnu-developer list has been added to gmane.org.
It is available as group gmane.comp.sysutils.cfg.devel

All messages are Accessible via web or newsreaders now! Fully searchable and with anti-spam measures. (see http://gmane.org)

When the Archive on Sourcforge with all messages up to today gets available a listadmin should  add the old messages to gmane. It is simple and described at http://gmane.org/import.php

After that please update the website to point to gmane instead of sf, too.

cheers,
-Peter