Re: [Wengophone-devel] news from wengo
Hi Tanguy,Tanguy Krotoff wrote: On Jan 29, 2008 10:44 PM, Vadim Lebedev [EMAIL PROTECTED] wrote: I'm sure that we don't want to start a flame war, I'm sure that in some aspects git is better than mercurial The choice of mercuriual is based on follownig: 1) At mbdsys we're using mostly Mercurial so it is easier for us 2) I was one of early contributors to Mercurial so i know the internals much better tha those of git 3) I've good contacts in mercurial developper community so problem solving will be easier flame war != argumentation What does it bring to contributors? Why is it better to subversion? In my experience ditributed VCS are better suited for decentralsed dev than centralised VCS For more details i refer you to: http://hgbook.red-bean.com/hgbookch1.html#x5-130001.4 Do we need the functionnalities mercurial brings? Is it easy to use under Windows? (since from what I see the only few contributors/developpers that use OpenWengo are mostly under Windows...) One of the reasons MBDSYS choose mercurial over git 3 years ago is because at the time git was unavailabe for windows... since than the situation became better with this respect but still it seem that mercurail has advanatge on this front: http://tortoisehg.sourceforge.net/ Another advantage is availablity of this: http://hgbook.red-bean.com/hgbookch1.html Some people use already git ect... If somebody REALLY want to use git i think we can arrange for some kind of gateway (but a little bit later) Change is good in general, but not every change. If you want mercurial because it is only better for YOU or because it is cool, fine. But then it is a dictature, not an open project :p (ok it has been like this for a while...) Well Tanguy as you know i was raised in Soviet Union, so, naturally i'm inclined toward dictature :) I've already started construction of couple of Gulag outfits to intern there developpers who don't like my opnions Tanguy what would be your sugestion about subproject/submodule structure Would you volunteer to be maintainer of any subsytem? Thanks Vadim ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] patchset wengophone-2.2 (r13252)
Hi Andreas!
On 27.01.2008 13:35, Andreas Schneider wrote:
Smaller patches than one big file would be nice.
Ok. I'll do that with the next patches (most probably after the tests
with Thomas revision 13255).
Additional notes on my patchset:
- libs/3rdparty/qt4/CMakeLists.txt
Since a version of Qt 4.x the DLLs of the lib are now ending with a 4.
I have changed that accordingly.
Are you sure that this is the case for all released Qt version. Maybe the
others should stay in the code. I think if the file doesn't exist, it would
stop to work.
No. I am not sure when this was changed. I see three options:
- Find out in which version this was changed and let the CMake handle
this two versions
- Some kind of if-file-exists in the CMake-File...
- Depend the project on Qt 4.3.3 (starting with revision 13255)
What do you think?
- libs/owutil/util/CMakeLists.txt
- libs/webcam/CMakeLists.txt
- wifo/phapi-util/CMakeLists.txt
The lib files of these projects are not created without these definitions.
I think this should be wrapped in an
if (WIN32)
endif (WIN32)
Ok.
- owbuild/owbuild/OWCreateProjectBinary.cmake
This was tricky and I am still not absolutly sure about it. This patch
now enables the post-build-copy-process to copy the DLL and PDB files
from the correct directory (by taking the right buildtype (debug vs.
release) into account). Maybe someone can take a special look at this
one. Thanks!
Yes, the files should be copied to the build type directory (release, debug)
Fine.
- wengophone/src/buildid/CMakeLists.txt
The Preprocessor Definition DD_BUILDID had two LL at the end (I
don't know why) but they should be an integer. The patch fixes that.
#define FOO 42LL means that FOO is a long long.
Current date and time is for example 20070127132638, this doesn't fit into an
integer you need a 64bit variable. That's why the function in
wengophone/src/WengoPhoneBuildId.cpp returns a long long.
const unsigned long long WengoPhoneBuildId::getBuildId() {
return DD_BUILDID;
}
So #define DD_BUILDID 2007012713263LL is right!
Hmm... Strange. I've just recompiled owbuildid. Now it seems to work
with these LL at the end (with an warning though).
But thanks for clearifing this issue.
I have still one more questions:
At the beginning of build process I get:
-- Rebuild All started: Project: owbuildid, Configuration: Debug Win32
--
Deleting intermediate and output files for project 'owbuildid', configuration
'Debug|Win32'
Building Custom Rule C:/Projects/wp-2.2/wengophone/src/buildid/CMakeLists.txt
Subversion (svn) command line not found, it is recommended to install it
-- OS: Windows-5.0
-- Processor: x86
-- Compiler: C:/Program Files/Microsoft Visual Studio 8/VC/bin/cl.exe
-- Build type: Debug
-- Build tool: C:/PROGRA~1/MICROS~3/Common7/IDE/VCExpress.exe
-- Build directory: C:/Projects/wp-2.2/build/debug
-- svn revision: 13253
-- Time:
[snip]
I believe the date-time used by the BUILDID comes from the time field
which - in my case - is empty. What do I have to do get that value?
It seems that OWGetCurrentDateTime.cmake respectivly a output in
getcurrentdatetime.cpp but I fail to decode what's going on in
there. (Looks like the cpp is compiled and run out of the
cmake-build-process; does that work under Windows?)
(Just for reference: I always had the svn revision 0 until I installed
the command-line version of subversion. After that the svn revision
was detected correctly.)
- wifo/owsl/src/core/owsl_address.c
OWSL_FUNC_DEF (which is definded as __declspec(dllimport)) is already
set in the header. No need to do that again.
- wifo/phapi/CMakeLists.txt
There two patches in here...
1. The lib file is not created without this definition.
Should be wrapped into if (WIN32)
Ok.
2. The Visual C++ compiler option -D do strip the quotes on the
command line[2] so this must be handled by a define in phapi.c.
That's bad, have you tried to escape them? There should be another way to do
that.
-DWENGOPHONE_UA=\wengo/v1/wengophoneng/wengo/rev${SVN_REVISION}/trunk/\
or
-DWENGOPHONE_UA='wengo/v1/wengophoneng/wengo/rev${SVN_REVISION}/trunk/'
or
-DWENGOPHONE_UA='wengo/v1/wengophoneng/wengo/rev${SVN_REVISION}/trunk/'
Yeah, I also do not like this solution. I've tried your suggestions
and a lot of other things but I was not able to get around it. Any
Visual C++-Crack who knows how to fix that?
- wifo/phapi/phapi.c
This is the second part of the -D-compiler-option problem of Visual
C++. I was not able to get the SVN-Revision into it so it's set to 0.
If somebody knows how to fix that (and knows how to include the svn
command line in the build process) please let me / us know. Thanks!
See above
Yes. I seems I need help by someone who knows what to do... Google
also did not bring up any workarounds.
- wifo/phapi/test/client/wlm_password.h
Altough I think this is just a test-project and not critical for
wengophone I tried to fix this. I
[Wengophone-devel] Re: build error in owutil
Hi Chris!
On 29.01.2008 02:58, Chris Botor wrote:
Did you encounter this on owutil build?
Oh yes! owutil was a tricky part of the build. Let's see if this is
actually the same I've encountered...
-- Rebuild All started: Project: owutil, Configuration: Debug Win32 --
[snip]
Linking to lib file: boost_signals-vc80-mt-gd-1_34_1.lib
Linking to lib file: boost_thread-vc80-mt-gd-1_34_1.lib
..\..\..\..\libs\owutil\util\src\Date.cpp(27) : warning C4996:
'localtime' was declared deprecated
C:\Program Files\Microsoft Visual Studio
8\VC\include\time.inl(114) : see declaration of 'localtime'
Message: 'This function or variable may be unsafe. Consider
using localtime_s instead. To disable deprecation, use
_CRT_SECURE_NO_DEPRECATE. See online help for details.'
CountryList.cpp
Base64.cpp
Generating Code...
Compiling manifest to resources...
Linking...
LINK : Debug\owutil.dll not found or not built by the last incremental
link; performing full link
Hmm.. Here it seems, that owutil.lib is missing. Did you double-check
that libs/owutil/util/CMakeLists.txt has the following lines in it:
ow_add_private_definitions(
-DOWUTIL_DLL
-DBUILD_OWUTIL_DLL
)
(They should be added by my patchset though...)
Embedding manifest...
Performing Post-Build Event...
Error copying file (if different) from
C:/Project/wengophone-2.2/build/libs/owutil/util/owutil.dll to
C:/Project/wengophone-2.2/build/debug/.
Error copying file (if different) from
C:/Project/wengophone-2.2/build/libs/owutil/util/owutil.pdb to
C:/Project/wengophone-2.2/build/debug/.
Project : error PRJ0019: A tool returned an error code from
Here it seems that the owbuild/owbuild/OWCreateProjectBinary.cmake
patch has not been applied. owutil.dll and owutil.pdb (and
owutil.lib) should be located in build/libs/owutil/util/debug/ (to be
precise in build/libs/owutil/util/${CMAKE_BUILD_TYPE} )
Could you double check that?
HTH HAND
- Darsha
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] some thoughts on submitting patches
Hi!
After the (first) patchset I've submitted on this list for openwengo
I was looking around for some guidelines on how to submit patches
correctly.
I was not able to find any information about submitting patches
neither in the openwengo-wiki nor in the archives of the
mailling-list. Did I miss something?
If found some guides from other projects:
[1] http://kerneltrap.org/Linux/Email_Clients_and_Patches
[2] http://winmerge.org/Wiki/Submit_Patch
[3] http://www.linuxfromscratch.org/patches/submit.html
[4]
http://sunsite.ualberta.ca/Documentation/Misc/perl-5.6.1/Porting/patching.html
In fact they can be summed up by these questions:
- How to create the patch?
- What should be the filename of the patch?
- How is the patch submitted?
The first question should be easy to answer:
- Use svn diff or create a patch with TortoiseSVN (or even use diff
-u)
The second question is not that easy. My suggestion (if anybody
cares):
- {OrigFilename}_r{svnrevision}_{patchName}-{patchVersion}.diff|patch
The third question is also not as easy as it seems:
As Attachment?
* gzipped?
* zipped?
* text?
Inline?
What should be the subject?
[PATCH] - {OrigFilename}_r{svnrevision}_{patchName}-{patchVersion}
I also like the idea of [3] of adding a patch header on each patch,
but I may be wrong.
What do you maintainer and longtime contributors think? Is that too
much overkill or would you like to stick to some guidelines? I would
love to hear your opinions. Thank you!
Greetings,
- Darsha
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] some thoughts on submitting patches
Hi,
I think it is better to submit is as an attachment because mail programs
has an effect on the file.
Chris
On Jan 31, 2008 1:33 AM, Darshaka Pathirana [EMAIL PROTECTED] wrote:
Hi!
After the (first) patchset I've submitted on this list for openwengo
I was looking around for some guidelines on how to submit patches
correctly.
I was not able to find any information about submitting patches
neither in the openwengo-wiki nor in the archives of the
mailling-list. Did I miss something?
If found some guides from other projects:
[1] http://kerneltrap.org/Linux/Email_Clients_and_Patches
[2] http://winmerge.org/Wiki/Submit_Patch
[3] http://www.linuxfromscratch.org/patches/submit.html
[4]
http://sunsite.ualberta.ca/Documentation/Misc/perl-5.6.1/Porting/patching.html
In fact they can be summed up by these questions:
- How to create the patch?
- What should be the filename of the patch?
- How is the patch submitted?
The first question should be easy to answer:
- Use svn diff or create a patch with TortoiseSVN (or even use diff
-u)
The second question is not that easy. My suggestion (if anybody
cares):
- {OrigFilename}_r{svnrevision}_{patchName}-{patchVersion}.diff|patch
The third question is also not as easy as it seems:
As Attachment?
* gzipped?
* zipped?
* text?
Inline?
What should be the subject?
[PATCH] - {OrigFilename}_r{svnrevision}_{patchName}-{patchVersion}
I also like the idea of [3] of adding a patch header on each patch,
but I may be wrong.
What do you maintainer and longtime contributors think? Is that too
much overkill or would you like to stick to some guidelines? I would
love to hear your opinions. Thank you!
Greetings,
- Darsha
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Openwengo REPO conversion
Hi Vadim! On 25.01.2008 20:18, Vadim Lebedev wrote: I' Independently i'm struggling with the fact that mercurial does not support subprojects so i'd like to pickup your brains for suggestions on how to organize mercurial repos for the openwengo project I would like to help you but unfortunatly I am not (yet) completely aware of the full source code. If you're able to give me some hints and tell me what YOU mean by subprojects, that would be really helpfull. I also have some questions regarding the code policy: - The openwengo-project holds internal copies of the source code of a various number of libraries. Will that change? Is that (still) a good idea? - If splitting up the project, will the history of each file remain? - maybe more... Greetings, - Darsha ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] patchset wengophone-2.2 (r13252)
Darshaka Pathirana wrote:
Hi Andreas!
Hi Darshaka,
- wengophone/src/buildid/CMakeLists.txt
The Preprocessor Definition DD_BUILDID had two LL at the end (I
don't know why) but they should be an integer. The patch fixes that.
#define FOO 42LL means that FOO is a long long.
Current date and time is for example 20070127132638, this doesn't fit into an
integer you need a 64bit variable. That's why the function in
wengophone/src/WengoPhoneBuildId.cpp returns a long long.
const unsigned long long WengoPhoneBuildId::getBuildId() {
return DD_BUILDID;
}
So #define DD_BUILDID 2007012713263LL is right!
Hmm... Strange. I've just recompiled owbuildid. Now it seems to work
with these LL at the end (with an warning though).
But thanks for clearifing this issue.
I have still one more questions:
At the beginning of build process I get:
-- Rebuild All started: Project: owbuildid, Configuration: Debug Win32
--
Deleting intermediate and output files for project 'owbuildid', configuration
'Debug|Win32'
Building Custom Rule C:/Projects/wp-2.2/wengophone/src/buildid/CMakeLists.txt
Subversion (svn) command line not found, it is recommended to install it
-- OS: Windows-5.0
-- Processor: x86
-- Compiler: C:/Program Files/Microsoft Visual Studio 8/VC/bin/cl.exe
-- Build type: Debug
-- Build tool: C:/PROGRA~1/MICROS~3/Common7/IDE/VCExpress.exe
-- Build directory: C:/Projects/wp-2.2/build/debug
-- svn revision: 13253
-- Time:
[snip]
I believe the date-time used by the BUILDID comes from the time field
which - in my case - is empty. What do I have to do get that value?
It seems that OWGetCurrentDateTime.cmake respectivly a output in
getcurrentdatetime.cpp but I fail to decode what's going on in
there. (Looks like the cpp is compiled and run out of the
cmake-build-process; does that work under Windows?)
I'm not a windows user. If you're on windows, you're on your own :)
(Just for reference: I always had the svn revision 0 until I installed
the command-line version of subversion. After that the svn revision
was detected correctly.)
Yes, that's how it is designed.
2. The Visual C++ compiler option -D do strip the quotes on the
command line[2] so this must be handled by a define in phapi.c.
That's bad, have you tried to escape them? There should be another way to do
that.
-DWENGOPHONE_UA=\wengo/v1/wengophoneng/wengo/rev${SVN_REVISION}/trunk/\
or
-DWENGOPHONE_UA='wengo/v1/wengophoneng/wengo/rev${SVN_REVISION}/trunk/'
or
-DWENGOPHONE_UA='wengo/v1/wengophoneng/wengo/rev${SVN_REVISION}/trunk/'
Yeah, I also do not like this solution. I've tried your suggestions
and a lot of other things but I was not able to get around it. Any
Visual C++-Crack who knows how to fix that?
We should create config.h files instead of passing defines via the
commandline. Maybe you want to do that :)
config.h.cmake and ConfigureChecks.cmake is needed. See srtp.
I'll take Thomas' latest revision and work on that one. After that I
will come back and let the patches be reviewed again...
That would be great. It would be great if Thomas would attend to this
discussion :)
Greetings,
- Darsha
-- andreas
--
http://www.cynapses.org/ - cybernetic synapses
signature.asc
Description: OpenPGP digital signature
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Openwengo REPO conversion
Darshaka Pathirana wrote: Hi Vadim! On 25.01.2008 20:18, Vadim Lebedev wrote: I' Independently i'm struggling with the fact that mercurial does not support subprojects so i'd like to pickup your brains for suggestions on how to organize mercurial repos for the openwengo project I would like to help you but unfortunatly I am not (yet) completely aware of the full source code. If you're able to give me some hints and tell me what YOU mean by subprojects, that would be really helpfull. I also have some questions regarding the code policy: - The openwengo-project holds internal copies of the source code of a various number of libraries. Will that change? Is that (still) a good idea? Subprojects are for example owutil (ow macros for cmake), webcam, util etc. Everything which is a external in subversion atm. 2.2 has no externals afaik. - If splitting up the project, will the history of each file remain? I know only git and it imports the whole history of each file. I think hg will do the same. - maybe more... Greetings, - Darsha -- andreas -- http://www.cynapses.org/ - cybernetic synapses signature.asc Description: OpenPGP digital signature ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] some thoughts on submitting patches
Darshaka Pathirana wrote:
Hi!
After the (first) patchset I've submitted on this list for openwengo
I was looking around for some guidelines on how to submit patches
correctly.
I was not able to find any information about submitting patches
neither in the openwengo-wiki nor in the archives of the
mailling-list. Did I miss something?
If found some guides from other projects:
[1] http://kerneltrap.org/Linux/Email_Clients_and_Patches
[2] http://winmerge.org/Wiki/Submit_Patch
[3] http://www.linuxfromscratch.org/patches/submit.html
[4]
http://sunsite.ualberta.ca/Documentation/Misc/perl-5.6.1/Porting/patching.html
In fact they can be summed up by these questions:
- How to create the patch?
- What should be the filename of the patch?
- How is the patch submitted?
The first question should be easy to answer:
- Use svn diff or create a patch with TortoiseSVN (or even use diff
-u)
The second question is not that easy. My suggestion (if anybody
cares):
- {OrigFilename}_r{svnrevision}_{patchName}-{patchVersion}.diff|patch
The third question is also not as easy as it seems:
As Attachment?
* gzipped?
* zipped?
* text?
Inline?
What should be the subject?
[PATCH] - {OrigFilename}_r{svnrevision}_{patchName}-{patchVersion}
I also like the idea of [3] of adding a patch header on each patch,
but I may be wrong.
What do you maintainer and longtime contributors think? Is that too
much overkill or would you like to stick to some guidelines? I would
love to hear your opinions. Thank you!
Greetings,
- Darsha
Folks as we're going to to switch to mercuririal i suggest you read:
http://www.selenic.com/mercurial/wiki/index.cgi/PatchbombExtension
I think it will be the best way to submit the patches for review
Thanks
Vadim
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] some thoughts on submitting patches
Darshaka Pathirana wrote:
Hi!
Hello,
- How to create the patch?
svn diff file foo.patch
if you fix a bug in N source files of a module use.
svn diff file..fileN foo.patch
Don't submit everything as one big patch.
- What should be the filename of the patch?
I name them after the subject.
fix_gcc43_warnings.patch for example
- How is the patch submitted?
Attach them to a bug or add them as an attachement to an email.
The first question should be easy to answer:
- Use svn diff or create a patch with TortoiseSVN (or even use diff
-u)
The second question is not that easy. My suggestion (if anybody
cares):
- {OrigFilename}_r{svnrevision}_{patchName}-{patchVersion}.diff|patch
The third question is also not as easy as it seems:
As Attachment?
attachement
What should be the subject?
[PATCH] - {OrigFilename}_r{svnrevision}_{patchName}-{patchVersion}
[PATCH] - Subject of the patch
Git has a special approach for commit messages, I think it is the same for hg.
The first line is a summary of the patch, max 60 chars. Then an empty line and
a description of the patch.
I also like the idea of [3] of adding a patch header on each patch,
but I may be wrong.
Yes, this makes it easier for the reviewer. I do that normally. With git you do
git-format-patch origin/master
and you get what you want. I hope hg can do the same.
What do you maintainer and longtime contributors think? Is that too
much overkill or would you like to stick to some guidelines? I would
love to hear your opinions. Thank you!
git does everything which you asked for. Hopefully hg behaves the same. The
important thing is that you write good commit messages.
Greetings,
- Darsha
-- andreas
--
http://www.cynapses.org/ - cybernetic synapses
signature.asc
Description: OpenPGP digital signature
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Openwengo REPO conversion
Andreas Schneider wrote: Darshaka Pathirana wrote: Hi Vadim! On 25.01.2008 20:18, Vadim Lebedev wrote: I' Independently i'm struggling with the fact that mercurial does not support subprojects so i'd like to pickup your brains for suggestions on how to organize mercurial repos for the openwengo project I would like to help you but unfortunatly I am not (yet) completely aware of the full source code. If you're able to give me some hints and tell me what YOU mean by subprojects, that would be really helpfull. I also have some questions regarding the code policy: - The openwengo-project holds internal copies of the source code of a various number of libraries. Will that change? Is that (still) a good idea? Subprojects are for example owutil (ow macros for cmake), webcam, util etc. Everything which is a external in subversion atm. 2.2 has no externals afaik. - If splitting up the project, will the history of each file remain? I know only git and it imports the whole history of each file. I think hg will do the same. The problem is that full conversion of svn to mercurial generates repository of 300 Mb (Orginal SVN is 700MB) It is not practical i believe. So i'm tending toward approach of not importing history, ands simply start from the current state of 2.2 branch and trunk Thanks Vadim - maybe more... Greetings, - Darsha -- andreas ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-deve ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Openwengo REPO conversion
On Jan 30, 2008 6:59 PM, Darshaka Pathirana [EMAIL PROTECTED] wrote: - The openwengo-project holds internal copies of the source code of a various number of libraries. Will that change? Is that (still) a good idea? It was done for helping developing under Windows (and MacOSX in some way). checkout svn, install Visual, boost, Qt and voila - everything was compiling without other steps. A http server (or maybe better, another hg repo) can be used to store already compiled binaries of external libraries. wifo still contains forked libraries (osip, exosip, ortp...) I think this is the most urgent thing to do about libraries. -- Tanguy Krotoff [EMAIL PROTECTED] +33 6 68 42 70 24 ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Link Error in some modules
I kept on having this error on some modules any one has a fix on this? -- Build files have been written to: C:/Project/wengophone-2.2/build Compiling... desktopservice.cpp Compiling manifest to resources... Linking... LINK : fatal error LNK1104: cannot open file 'QtUiToolsd.lib' Build log was saved at file://c:\Project\wengophone-2.2\build\libs\qtutil\tests\desktopservice.dir\Debug\BuildLog.htm desktopservice - 1 error(s), 0 warning(s) == Rebuild All: 0 succeeded, 1 failed, 0 skipped == Hi Darsha, yeah some how the tortoise did not patch all the files, kinda weird Chris ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Openwengo REPO conversion
On Wed, Jan 30, 2008 at 07:40:02PM +0100, Vadim Lebedev wrote: The problem is that full conversion of svn to mercurial generates repository of 300 Mb (Orginal SVN is 700MB) It is not practical i believe. Hmm, I'd say size shouldn't matter too much. I'm in favour of retaining all the history. These days 300 MB isn't much (fits on a CD ;-) On Wed, Jan 30, 2008 at 06:59:49PM +0100, Darshaka Pathirana wrote: On 25.01.2008 20:18, Vadim Lebedev wrote: Independently i'm struggling with the fact that mercurial does not support subprojects so i'd like to pickup your brains for suggestions on how to organize mercurial repos for the openwengo project I would like to help you but unfortunatly I am not (yet) completely aware of the full source code. If you're able to give me some hints and tell me what YOU mean by subprojects, that would be really helpfull. That disclaimer applies for me, too. - If splitting up the project, will the history of each file remain? If you split the project into sub-projects and later refactor something, then files might move from one sub-project to another. In that case history for the moved files is probably lost (or can hg retain history when moving from one repo to another? I know svn can't.). So this *might* mean that we're back to old CVS days when moving files for restructuring the repo can't be done in certain cases (umm in *all* cases for cvs :-)... So when really deciding to split, future refactoring should be kept in mind. Whats wrong with keeping a big project with subdirectories containing individual subprojects? Just my .02 Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting Fax: +43/2243/26465-23 Reichergasse 131www: http://www.runtux.com A-3411 Weidling email: [EMAIL PROTECTED] osAlliance member email: [EMAIL PROTECTED] ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Openwengo REPO conversion
Ralf Schlatterbeck wrote: On Wed, Jan 30, 2008 at 07:40:02PM +0100, Vadim Lebedev wrote: The problem is that full conversion of svn to mercurial generates repository of 300 Mb (Orginal SVN is 700MB) It is not practical i believe. Hmm, I'd say size shouldn't matter too much. I'm in favour of retaining all the history. These days 300 MB isn't much (fits on a CD ;-) The problem, is that in DVCS's like mercurial when you create a branch you clone the whole stuff. So it quickly becomes expensive. That said we can keep the SVN version indefinitly in Read Only mode for reference or i can publish folly converted mercurial repo for browsing Thanks Vadim ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Link-Problem with Debian multimedia libs
Hi I'm trying to build wengo 2.2 branch against etch packages from http://www.debian-multimedia.org (newer multimedia packages not found in core debian etch) and fail with missing symbols on the final linking. (Thanks to Darsha for helping out with cmake details). Missing symbols are img_resample_init, img_resample, img_resample_close, img_convert normally found (in stock debian) in libavcodec installed from libavcodec-dev. Is this a change in libavcodec api that wengo hasn't followed yet? Should I go back to the debian etch libs (which *do* have these symbols)? Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting Fax: +43/2243/26465-23 Reichergasse 131www: http://www.runtux.com A-3411 Weidling email: [EMAIL PROTECTED] osAlliance member email: [EMAIL PROTECTED] ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Link-Problem with Debian multimedia libs
Ralf Schlatterbeck wrote: Hi I'm trying to build wengo 2.2 branch against etch packages from http://www.debian-multimedia.org (newer multimedia packages not found in core debian etch) and fail with missing symbols on the final linking. (Thanks to Darsha for helping out with cmake details). Missing symbols are img_resample_init, img_resample, img_resample_close, img_convert normally found (in stock debian) in libavcodec installed from libavcodec-dev. Is this a change in libavcodec api that wengo hasn't followed yet? Should I go back to the debian etch libs (which *do* have these symbols)? ffmpeg api has changed you need libswscale and swscale.h Ralf -- andreas -- http://www.cynapses.org/ - cybernetic synapses signature.asc Description: OpenPGP digital signature ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] Openwengo REPO conversion
Andreas Schneider wrote: Vadim Lebedev wrote: Andreas Schneider wrote: Darshaka Pathirana wrote: Hi Vadim! On 25.01.2008 20:18, Vadim Lebedev wrote: I' Independently i'm struggling with the fact that mercurial does not support subprojects so i'd like to pickup your brains for suggestions on how to organize mercurial repos for the openwengo project I would like to help you but unfortunatly I am not (yet) completely aware of the full source code. If you're able to give me some hints and tell me what YOU mean by subprojects, that would be really helpfull. I also have some questions regarding the code policy: - The openwengo-project holds internal copies of the source code of a various number of libraries. Will that change? Is that (still) a good idea? Subprojects are for example owutil (ow macros for cmake), webcam, util etc. Everything which is a external in subversion atm. 2.2 has no externals afaik. - If splitting up the project, will the history of each file remain? I know only git and it imports the whole history of each file. I think hg will do the same. The problem is that full conversion of svn to mercurial generates repository of 300 Mb (Orginal SVN is 700MB) It is not practical i believe. Only one branch or of the whole repo? My wengophone git repo of the the 2.2 branch has 88 Mb. Whole repo 2.2 Branch in mercurial is around 80 MB That's just fine with the whole history. It would be much smaller without the binary-libs. Yes... Vadim ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] patchset wengophone-2.2 (r13252)
Andreas Schneider wrote: Darshaka Pathirana wrote: I'll take Thomas' latest revision and work on that one. After that I will come back and let the patches be reviewed again... That would be great. It would be great if Thomas would attend to this discussion :) I committed some modifications on wifo which are inspired from Darsha's ones. But I don't work on Windows and I have never built WengoPhone with MS Visual 2005. When I will have time, I will try it and I will give you feedbacks. -- Thomas ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] wengophone 2.1.2 dmg crashed on MacOsX 10.5
Hi, group I got wengophone crashed on my new macbook. here is the report: Process: WengoPhone [379] Path: /Volumes/WengoPhone/WengoPhone.app/Contents/MacOS/WengoPhone Identifier: com.openwengo.WengoPhone Version: ??? (2.1.2) Code Type: X86 (Native) Parent Process: launchd [74] Date/Time: 2008-01-30 22:05:41.905 +0800 OS Version: Mac OS X 10.5 (9A3115a) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x Crashed Thread: 0 Thread 0 Crashed: 0 QtCore0x01d188d1 QLocale::name() const + 61 1 com.openwengo.WengoPhone 0x000203d2 QtLanguage::getLocaleFileName() + 164 2 com.openwengo.WengoPhone 0x00020690 QtLanguage::getQtLocaleFileName() + 28 3 com.openwengo.WengoPhone 0x0002071f QtLanguage::loadLanguageFromConfig() + 49 4 com.openwengo.WengoPhone 0x0002157c QtLanguage::QtLanguage(QObject*) + 314 5 com.openwengo.WengoPhone 0x00016e82 QtWengoPhone::initThreadSafe() + 94 6 com.openwengo.WengoPhone 0x00266937 boost::_bi::bind_tvoid, boost::_mfi::mf0void, QtWengoPhone, boost::_bi::list1boost::_bi::valueQtWengoPhone* ::operator()() + 43 7 com.openwengo.WengoPhone 0x00266a63 boost::function0void, std::allocatorvoid ::operator()() const + 75 8 com.openwengo.WengoPhone 0x00093384 QObjectThreadSafe::event(QEvent*) + 34 9 QtGui 0x01f172f9 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 319 10 QtGui 0x01f1caa3 QApplication::notify(QObject*, QEvent*) + 1197 11 QtCore0x01d6bf04 QCoreApplication::sendPostedEvents(QObject*, int) + 586 12 QtGui 0x01f562c9 QEventDispatcherMac::processEvents(QFlagsQEventLoop::ProcessEventsFlag) + 335 13 QtCore0x01d69b85 QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) + 55 14 QtCore0x01d69dce QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) + 146 15 QtCore0x01d6d181 QCoreApplication::exec() + 179 16 com.openwengo.WengoPhone 0x000151d8 main + 1728 17 com.openwengo.WengoPhone 0x994a _start + 216we 18 com.openwengo.WengoPhone 0x9871 start + 41 ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
