barry-devel — Development discussion mailing list

Re: [Barry-devel] WinCE port of Barry

[Chris F. <cd...@fo...>]

On Mon, Jul 16, 2012 at 12:10:28PM +0100, Toby Gray wrote:
> I noticed a couple of issues with routing of data and sequence packets 
> early on in channel setup if the device sends data to the PC quickly. I 
> fixed these in 
> https://github.com/tobygray/barry/commit/ebbdf4c9d5868a69d636119da354547918c70e1a 
> and 
> https://github.com/tobygray/barry/commit/6dff36f6c2cd1ef2c0006af2baebbf5ee0c0c291


I'm not overly keen on the TransferInterest() function.  For one it
requires the non-scoped version of the scope_lock class, which I haven't
merged.  And for another, it adds a new call point for callbacks.

Ideally, callbacks should occur from the same thread that calls DoRead,
whatever application thread is doing that main processing.  I don't
think it is guaranteed that the worker thread will call TransferInterest().
In fact, I think it is likely that it won't.

Is there a way to avoid TransferInterest completely?  The application is
in control of its read thread, and so is the raw channel code, if I'm
not mistaken.  Is there no way to drain the incoming queue before we
transfer interest to a callback?

Thanks,
- Chris

P.S.  I haven't heard much from you in response to my queries.  If you're
	just busy, that's ok, but if you're waiting for something from me,
	please do let me know. :-)  I've merged all I can so far.

Re: [Barry-devel] WinCE port of Barry

[Chris F. <cd...@fo...>]

On Mon, Jul 16, 2012 at 12:10:28PM +0100, Toby Gray wrote:
> The rest of the commits are a combination of changes to the code to fix 
> warnings or errors from the Microsoft compiler. If the commit messages 
> aren't detailed enough for any of these then let me know and I'll fill 
> in the gaps (and update the commit messages).

I'm merging in the obvious fixes into master, and the changes that I think
might need to wait until version 0.19.0 (due to abi changes, etc), I've put
in a new branch v0.19.0.  Expect that branch to be rebased on master
periodically.  I'm not quite done yet.

You should be able to rebase your branch onto the v0.19.0 branch to see
what I haven't processed yet.


Some questions:

1)

Can you explain why you need a lock() member in scoped_lock?
The idea behind scoped_lock is to force its use in a scoped section,
to prevent forgotten unlocks and to make the sections obvious.

Was there a real need for it?




2)

Author: Toby Gray <tob...@re...>
Date:   Thu Jun 7 15:46:53 2012 +0100

    lib: Fixing incorrect forward declaration of ProbeResult as a struct, it's r
eally a class.

diff --git a/src/controller.h b/src/controller.h
index 8e3ba85..41727c7 100644
--- a/src/controller.h
+++ b/src/controller.h
@@ -32,7 +32,7 @@ namespace Barry {
 
 // forward declarations
 class SocketRoutingQueue;
-class ProbeResult;
+struct ProbeResult;
 
 class PrivateControllerData;
 

Is this a problem with the Microsoft compiler?  I believe that strictly
speaking, according to the C++ spec, class and struct can be used
interchangeably.

Thanks,
- Chris

Re: [Barry-devel] WinCE port of Barry

[Chris F. <cd...@fo...>]

On Mon, Jul 16, 2012 at 12:10:28PM +0100, Toby Gray wrote:
> Hi,
> 
> I've been working on a port of Barry to WinCE. It's currently sitting in 
> the "wince" branch on my github:
> https://github.com/tobygray/barry/tree/wince

Thanks Toby!  Looks like a fair bit of code... I'll probably have more
comments after I review it more closely.


> The main commit which adds WinCE support is 
> https://github.com/tobygray/barry/commit/d660a40f21b823510e5b81113f20fe4af3c3974a. 
> This adds a wince directory in the root to contain the build files and 
> implementations of some functions not present on WinCE, such as getopt and 
> sleep. I have a feeling that these headers and source code should probably 
> be moved into /src, to go near pre-existing support code such as 
> getpwuidandroid.cc. Would that make sense?
> 
> I have already done similarily for configfile.cc, splitting it up into 
> common code, code for unix systems and code for win32 systems in 
> https://github.com/tobygray/barry/commit/36131b090c3d6c1c34af441b40868b3b094fa66b

With all the headers in wince/, I'm tempted to try to keep wince-specific
code in its own directory, since it will likely be larger than a simple
file here or there like android.

None of Barry is specifically written with '/' vs. '\' in mind, so you
kind of have your work cut out for you, in those spots. :-)  Fortunately,
most of that code is in the GUI code, I think.  I would sincerely like to
keep such things as low level and out of the way as possible, so I like
what you've done with configfile.cc so far.

What do you think of creating a static library in wince/ which is linked
to the main library when building for Windows?  Maybe that's what you're
doing already.


> As WinCE doesn't have tr1 support I had to change how the shared_ptr 
> support in Barry was referenced. Instead of directly referencing 
> tr1::shared_ptr, I changes this so that there is Barry::tr1::shared_ptr 
> which is provided by boost::shared_ptr on WinCE and by tr1::shared_ptr 
> on all pre-existing platforms.
> 
> This was done in 
> https://github.com/tobygray/barry/commit/b4a70d9f7feedaa52bebe46d78e7dce880e73b74. 
> I'm not entirely happy with this, especially as it changes the external API 
> for libbarry, but I couldn't think of an alternative solution.

I think it's better to go in the other direction.  For systems that don't
have tr1, then:

namespace std {
	namespace tr1 {
		using boost::shared_ptr;
	}
}

I hope that's possible. :-)  It might even prevent the need to bump to 0.19.


> I added support for brawchannel to read and write the channel data over 
> TCP, instead of STDIN and STDOUT as WinCE doesn't have great terminal 
> support. This has made tools/brawchannel.cc a bit of a mess of #ifdef 
> WIN32. I think the best thing to do is to split it into 
> tools/brawchannel.cc, tools/brawchannel_unix.cc and 
> tools/brawchannel_win32.cc. Does that make sense?

Yes, avoid #ifdefs if at all possible, please. :-)


More comments as I read through the code.

Thanks!
- Chris

[Barry-devel] WinCE port of Barry

[Toby G. <tob...@re...>]

Hi,

I've been working on a port of Barry to WinCE. It's currently sitting in 
the "wince" branch on my github:
https://github.com/tobygray/barry/tree/wince

I don't think it's currently in a state to merge back into barry as I've 
made a few changes which I'm not entirely sure about if they are the 
best thing to do.

The main commit which adds WinCE support is 
https://github.com/tobygray/barry/commit/d660a40f21b823510e5b81113f20fe4af3c3974a. 
This adds a wince directory in the root to contain the build files and 
implementations of some functions not present on WinCE, such as getopt 
and sleep. I have a feeling that these headers and source code should 
probably be moved into /src, to go near pre-existing support code such 
as getpwuidandroid.cc. Would that make sense?

I have already done similarily for configfile.cc, splitting it up into 
common code, code for unix systems and code for win32 systems in 
https://github.com/tobygray/barry/commit/36131b090c3d6c1c34af441b40868b3b094fa66b

As WinCE doesn't have tr1 support I had to change how the shared_ptr 
support in Barry was referenced. Instead of directly referencing 
tr1::shared_ptr, I changes this so that there is Barry::tr1::shared_ptr 
which is provided by boost::shared_ptr on WinCE and by tr1::shared_ptr 
on all pre-existing platforms.

This was done in 
https://github.com/tobygray/barry/commit/b4a70d9f7feedaa52bebe46d78e7dce880e73b74. 
I'm not entirely happy with this, especially as it changes the external 
API for libbarry, but I couldn't think of an alternative solution.

I added support for brawchannel to read and write the channel data over 
TCP, instead of STDIN and STDOUT as WinCE doesn't have great terminal 
support. This has made tools/brawchannel.cc a bit of a mess of #ifdef 
WIN32. I think the best thing to do is to split it into 
tools/brawchannel.cc, tools/brawchannel_unix.cc and 
tools/brawchannel_win32.cc. Does that make sense?

I noticed a couple of issues with routing of data and sequence packets 
early on in channel setup if the device sends data to the PC quickly. I 
fixed these in 
https://github.com/tobygray/barry/commit/ebbdf4c9d5868a69d636119da354547918c70e1a 
and 
https://github.com/tobygray/barry/commit/6dff36f6c2cd1ef2c0006af2baebbf5ee0c0c291

The rest of the commits are a combination of changes to the code to fix 
warnings or errors from the Microsoft compiler. If the commit messages 
aren't detailed enough for any of these then let me know and I'll fill 
in the gaps (and update the commit messages).

Regards,

Toby

Re: [Barry-devel] Barry-0.18.3 on openSUSE-12.1

[Bojan V. <boj...@ho...>]

Hi Chris

Yes, kdesu or gnomesu are both graphical front ends for executing
command as another user, usually root.

Rgds
Bojan

On Uto, 2012-07-10 at 16:50 -0400, Chris Frey wrote:
> Upon checking my notes, it seems kdesu is the way it is done on openSUSE.
> Is this true in your experience?
> 
> Thanks,
> - Chris
> 
> 
> On Tue, Jul 10, 2012 at 04:40:52PM -0400, Chris Frey wrote:
> > Hi Bojan,
> > 
> > Thanks very much for your patches.  I'll take some time to go through them.
> > 
> > It would be really nice if it were possible to avoid compiling beesu
> > specifically for openSUSE.  Do you know of any similar program which
> > is available by default in the openSUSE repositories?  That's what I'd
> > really like to use, and that should only require a ./configure option
> > change in the spec file, instead of compiling a whole new dependency.
> > 
> > How does openSUSE request the root password when doing system changes?
> > 
> > Thanks,
> > - Chris
> > 
> > P.S.  Would you mind if we continued this conversation on the barry-devel
> > mailing list?  It is fairly low traffic these days, and would give others
> > the opportunity to help us find the best solution.
> > 
> > 
> > On Tue, Jul 10, 2012 at 10:33:05AM +0200, Bojan Vondra wrote:
> > > Hello Chris
> > > 
> > > Sorry for this little delay, I took time to do some test on Barry. I
> > > compiled barry (with all options) having beesu installed on my system
> > > (openSUSE 12.1, both i586 and x86_64). 
> > > 
> > > beesu compiles without any problem, I took source rpm and spec file from Fedora16 distribution.
> > > Desktop option needs wxWidgets-devel to compile.
> > > 
> > > Playing with barrydesktop I noticed few things:
> > > - Browse Database: if I edit Calendar entry, pressing OK on Calendar Event window kills barrydesktop. 
> > > Same thing if I try to add entry, hitting OK on Calendar Event kills barrydesktop and same think when I try 
> > > to delete entry: barrydesktop is killed when Yes button on dialog is pressed. NOTE: no international characters
> > > are used in Calendar.
> > > - Sync: for me, using KDEPIM works without any issues so far, but syncing with Evolution 3 eventually runs
> > > into some errors, which, I believe, lie in configuration of calendar.ics file. If you wish, I could induce
> > > these errors and report file back to you.
> > > 
> > > Regarding other packages, I can't build osynctools and msynctools, others are built OK.
> > > 
> > > I use Blacknerry Curve 8300 and 8520.
> > > 
> > > Best regards
> > > Bojan
> > > 
> > > 
> > > 
> > > 
> > > On Pet, 2012-07-06 at 20:02 -0400, Chris Frey wrote:
> > > > Hi Bojan!
> > > > 
> > > > Thanks very much for your work on this.  I have some of the build system
> > > > setup for making openSUSE packages, but haven't gotten to testing things,
> > > > nor making the tweaks needed to the source and spec files.  So I'm very
> > > > grateful for your testing work.
> > > > 
> > > > It's probably better if I build the packages so you don't have to do it
> > > > on each release.  If you could send me all your patches, that would be great.
> > > > 
> > > > Did you run into any issue with the guisu option in building the Desktop?
> > > > Did you use gksu?  beesu?
> > > > 
> > > > Thanks!
> > > > - Chris
> > > > 
> > > > 
> > > > On Fri, Jul 06, 2012 at 09:05:50PM +0200, Bojan Vondra wrote:
> > > > > Hello
> > > > > 
> > > > > Thanks for this useful program. I managed to build Barry-0.18.3 on 
> > > > > openSUSE-12.1 and I want to submit RPMs (about 40M including i586, x86_64 and 
> > > > > SRPMs), but I don't know how to do that. 
> > > > > 
> > > > > Due to differences of the openSUSE wxwidgets I had to slightly modify calls to 
> > > > > functions Print, ShortPrint and barryevrbose in SyncStatusDlg.cc.
> > > > > 
> > > > > My compiler complains about ambiguity on these functions when the input 
> > > > > argument is just string, e.g. I had to modify funtion
> > > > > 
> > > > > Print("No more devices to sync.", *wxBLACK);
> > > > > 
> > > > > to
> > > > > 
> > > > > Print(string("No more devices to sync."), *wxBLACK);
> > > > > 
> > > > > I hope that this is OK (anyway, it works on my computer and I tested it using 
> > > > > KDEPIM and Evolution3 plugin). I marked lines that I changed with my name.
> > > > > 
> > > > > Best regards
> > > > > Bojan Vondra
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 

Re: [Barry-devel] linberry's source code

[Chris F. <cd...@fo...>]

On Tue, Jul 10, 2012 at 07:47:11PM -0430, Israel Marrero wrote:
> excuseme the file is  linberryB.rbp in the root of the tarball

Thanks.  I see it now... unfortunately I don't have realstudio yet, so
it's a little hard to read. :-)

In the linberryB.rbp file, you write:

	Linberry Desktop Manager

	Is an alternative to RIM Blackberry Desktop manager . It has been
	designed for ubuntu, but maybe	work on other Linux distributions.

	Linberry was designed by Israel Marrero (PuntoAzul)
	isr...@ho... and has released the first alpha in
	December 2010.

	The author allows the use of this software without any warranty
	and is not responsible for damage that may cause the software
	to any device or PC, use it at your own risk!

	- LinBerry DM is a software created by Israel Marrero.
	- BlackBerry is a trademark of Research In Motion Inc.
	-Tux is the official Linux mascot created by Larry Ewing

	Acknowledgements:
	* To Jehova, the lord of Universe, without Him nothing is possible.
	* To Yelitze My wife, my son Misael and my parents Marcelina
	and Tito for standme always.
	* to my friend Erik Muoz, brother: you're always there when I needed
	your help.

	For more information go to the official site linberry:
		http://linberry.webcindario.com
	Los Teques, December 11, 2010, Miranda Venezuela


LinBerry, RIM, BlackBerry, and even Tux are mentioned, but Barry is nowhere
to be seen, and there is no link to http://netdirect.ca/barry even in
the acknowledgements above.  Please add an explanation that the low level
communication is done by Barry, and include the URL.

There is no copyright file in the .deb package where licenses are usually
mentioned.  If you want a good starting point for one, you can find it
here:

	http://repo.or.cz/w/barry.git/blob/HEAD:/debian/copyright

Even the man pages that do exist in the source tarball have been changed,
with no clarification as to the origin of the code.  The pppob.1 manpage,
for example, renames the URL in such a way that it does not work anymore.
This is the case for many of the URLs that remain.

Why rename it and call it your own?  Would you not be somewhat offended
if I did the same to you?

If the library was renamed back to Barry in your project, it should
be possible to make the linberry GUI work with even the latest Barry
library with little effort, and you could enjoy the upstream bugfixes
that come for free, based on the Barry community's efforts.  I see that
you are using Barry 0.16, when Barry 0.18.3 is available.

It would be better if you joined us, and became part of the Barry community.
But you need to acknowledge our work in order for that to happen.  I wish
to acknowledge your work as well, but it is difficult when it is all mixed
together and you claim full authorship of LinBerry while renaming our code.

- Chris

Re: [Barry-devel] linberry's source code

[Chris F. <cd...@fo...>]

On Tue, Jul 10, 2012 at 10:52:57PM +0000, Israel Marrero M  wrote:
> Everithing  you need to see and compile  the source of linbeery is in
> the tarball but for the ide you need a professional license of realstudio
> 2011 r4.1 for linux.

Didn't know that, thanks.


> there in the root of the tarball is de rbl file: Linberry.rbl

The only *.rbl files I can find are:

	~/linberry/Source$ find . -name "*.rbl"
	./traducciones lingua/linberry2frances.rbl
	./traducciones lingua/linberry2ingles.rbl
	./traducciones lingua/linberry2aleman~.rbl
	./traducciones lingua/linberry2italiano.rbl
	./traducciones lingua/linberry2protugues~.rbl
	./traducciones lingua/linberry2protugues.rbl
	./traducciones lingua/linberry2aleman.rbl
	./traducciones lingua/linberry2italiano~.rbl


> Other parts  are in phyton compiled with cxfreezze, but there is the source.

The only *.py files I can see are under the "Blackberry modem/bbtether/"
directory.  Are these the files you mean?

Is there a different source tarball that I missed?

Thanks,
- Chris

Re: [Barry-devel] linberry's source code

[Chris F. <cd...@fo...>]

On Tue, Jul 10, 2012 at 11:03:41PM +0000, Israel Marrero M  wrote:
> The libtar, is the same project of the libtar for debian... I have no
> make modifications. I Just use the binary
> 
> Is included as a patch for the ubuntu libtar beacause an error on
> backup... But is the same libtar for debian

Good to know, thanks.


> Excuse my english is not good.

No problem.

- Chris

Re: [Barry-devel] linberry's source code

[Chris F. <cd...@fo...>]

Hi Israel,

I've finally had time to take a look at the source code you've released
so far, for linberry beta2.  Unfortunately, it does not appear to contain
everything needed to build linberry completely from source.

I found some source code to bbtether (now known as Barry4All)
and I found Barry's source code included, which was merely renamed to
"linberry"... both the library name and the C++ namespaces were renamed,
but the code was mostly the same.

I found a 20MB linberry binary in the .deb release package, which does
not match the 17MB linberry binary in the Source tarball.  It is unclear
how to rebuild that binary from the source tarball, since there are no
Makefiles included, except the ones copied from Barry.  Nor can I find
the source files to that large binary.

I found a libtar.so library under the patch directory, but there is no
source code included to show what was patched.

In fact, there are a lot of .so files, but the source code to them appears
to be missing.  Some of these .so files are linked to Barry as well, which
is GPL.

I grabbed the Source tarball from the link on your website here:

	http://linberry.webcindario.com/pages/descargar.html

which gave me the download link here:

	http://www.mediafire.com/?7411qssiabhjbvc

If there is another source tarball available which includes the complete
sources for linberry, I would be happy to know about it.

Sadly, the Source tarball currently released (at least the one I could
find) is not satisfactory to meet GPL requirements.  The supporting
linberry libraries are still linked to Barry source code, even if it
was just renamed to "linberry".

It is unfortunate that Barry could not be used here in the way it was
intended: as a supporting library for further open source applications
which interface with the BlackBerry.  Instead, a lot of duplication
has been done, unnecessarily.  It is unnecessary to hide the fact that
Barry was used to build linberry, by renaming it; and it adds to your
own maintenance burden, having to maintain your own copy of Barry as well.
It benefits neither Barry nor linberry to have such a duplication of effort.

It appears you have the beginnings of a really nice open source project,
and it would be to the benefit of your own users to release the linberry
sources as required by the GPL.

In the hope of a mutually beneficial resolution, I look forward to the
release of the complete linberry sources.

Sincerely,
- Chris



On Fri, Jun 15, 2012 at 05:56:15PM -0400, Chris Frey wrote:
> Hi Israel,
> 
> That's great news.  I look forward to seeing the source code soon.
> 
> Thanks,
> - Chris
> 
> 
> On Fri, Jun 15, 2012 at 03:42:07AM -0430, Israel Marrero wrote:
> > Dear Chris
> > 
> > In the next 48 hours (+/-) the beta2 of linberry will be released, At 
> > the same time the source code will be releasing on the website
> > 
> > Thanks and regards
> > 
> > Israel
> > 
> > 
> > El 23/04/12 17:15, Chris Frey escribi?:
> > >Hi,
> > >
> > >I am the project lead of the Barry project and I was told about your
> > >project linberry yesterday.
> > >
> > >As far as I can tell, your project webpage is at:
> > >
> > >	http://linberry.webcindario.com/pages/acercade.html
> > >
> > >I took a look at the beta1 deb, but I am unable to find the source code
> > >to linberry, and I would be interested in seeing it, since it is linked
> > >against the Barry library, which is released under the GPL license.
> > >
> > >Barry is purposely written as a library, so I am glad that it is
> > >actually being used that way.  But it is intentionally released under
> > >the GPL, not the LGPL, so that programs built with it must also release
> > >their source code.
> > >
> > >Is the source code available on the web, and I just missed it?  If I missed
> > >it, please direct me to the right page.
> > >
> > >If you don't have the source code available on the web, that's fine.
> > >You can email it to me directly instead.
> > >
> > >You can find more information about GPL source release requirements here:
> > >
> > >	http://gpl-violations.org/faq/sourcecode-faq.html
> > >
> > >I look forward to hearing from you.  It would be great if our projects
> > >could work together, and I'm always looking for feedback on the Barry
> > >API, in order to improve it.
> > >
> > >Thanks,
> > >- Chris
> > >
> > >
> > >

Re: [Barry-devel] barry-0.18.2 patch for BB Bold (9930)

[Chris F. <cd...@fo...>]

On Mon, Jun 25, 2012 at 04:59:47PM -0400, Chris Frey wrote:
> Thanks Kurt!  I've created a new branch on repo.or.cz/w/barry.git called
> "ipmodemfix".  Would you be able to test this to make sure it fixes your
> issue on the Bold?  The line numbers from your patch didn't quite
> line up.

Hi Kurt,

Have you had a chance to test this?  Are you able to build from git, or
do you need a tarball?

Thanks,
- Chris

Re: [Barry-devel] barry-0.18.2 patch for BB Bold (9930)

[Chris F. <cd...@fo...>]

On Sun, Jun 24, 2012 at 06:24:12PM -0400, me...@ro... wrote:
> Chris:
> 
> I run Gentoo Linux ~x86, and first used barry with the original BB on
> XmBlackberry + barry-0.16,
> later upgrading to a Curve with barry-0.17.x (and -0.18.x as well), and
> now the Bold.
> 
> Patch to fix 'timeout after send passwd':
> 
> File: src/m_ipmodem.cc, lines 172+
> 
> -- m_dev.BulkRead(read_ep, data);
> -- ddout("IPModem: Start Response Packet:\n" << data);
> ++ 		try {
> ++ 			m_dev.BulkRead(read_ep, data);
> ++			ddout("IPModem: Start Response Packet:\n" << data);
> ++		}
> ++		catch( Usb::Timeout &to ) {
> ++			// do nothing on timeouts
> ++			ddout("IPModem: Start Response Timeout");
> ++		}
> 
> Effect of code: allow Timeout response for 'Re-send Start Request'.

Thanks Kurt!  I've created a new branch on repo.or.cz/w/barry.git called
"ipmodemfix".  Would you be able to test this to make sure it fixes your
issue on the Bold?  The line numbers from your patch didn't quite
line up.


> there is also a problem in desktop/ModemDlg.cc, that I can't fix w/o your
> help..
> 
> my suggested fix is something along the lines of:
> 
> File: desktop/src/ModemDlg.cc, lines 270+
> 
> -- string need_sudo;
> ++ #ifndef BARRYDESKTOP_SYSTEM_GUI_SU
> ++ #define BARRYDESKTOP_SYSTEM_GUI_SU ""
> ++ #endif
> ++ 	string need_sudo = string(BARRYDESKTOP_SYSTEM_GUI_SU " ");
> 
> Effect of code: when user .configure --with-guisu=<path>, this override
> will occur

I'm unclear what the exact issue is here... in the ModemDlg.cc code, there are
3 states.  One state is for when pppd can be run by the end user.  The
other two states both use the GUI_SU setting from configure.  Ideally,
a GUI_SU should not be required, if system permissions are set correctly,
but some systems prefer not having a setuid pppd, so both modes are needed.

On systems that do have a setuid pppd, the goal is to avoid prompting for a
root password every time, since it is not needed.  But perhaps I got the
permissions tests wrong in the code.

What particular error do you get?  How does it behave for you?

Thanks,
- Chris

Re: [Barry-devel] linberry's source code

[Chris F. <cd...@fo...>]

Hi Israel,

That's great news.  I look forward to seeing the source code soon.

Thanks,
- Chris


On Fri, Jun 15, 2012 at 03:42:07AM -0430, Israel Marrero wrote:
> Dear Chris
> 
> In the next 48 hours (+/-) the beta2 of linberry will be released, At 
> the same time the source code will be releasing on the website
> 
> Thanks and regards
> 
> Israel
> 
> 
> El 23/04/12 17:15, Chris Frey escribió:
> >Hi,
> >
> >I am the project lead of the Barry project and I was told about your
> >project linberry yesterday.
> >
> >As far as I can tell, your project webpage is at:
> >
> >	http://linberry.webcindario.com/pages/acercade.html
> >
> >I took a look at the beta1 deb, but I am unable to find the source code
> >to linberry, and I would be interested in seeing it, since it is linked
> >against the Barry library, which is released under the GPL license.
> >
> >Barry is purposely written as a library, so I am glad that it is
> >actually being used that way.  But it is intentionally released under
> >the GPL, not the LGPL, so that programs built with it must also release
> >their source code.
> >
> >Is the source code available on the web, and I just missed it?  If I missed
> >it, please direct me to the right page.
> >
> >If you don't have the source code available on the web, that's fine.
> >You can email it to me directly instead.
> >
> >You can find more information about GPL source release requirements here:
> >
> >	http://gpl-violations.org/faq/sourcecode-faq.html
> >
> >I look forward to hearing from you.  It would be great if our projects
> >could work together, and I'm always looking for feedback on the Barry
> >API, in order to improve it.
> >
> >Thanks,
> >- Chris
> >
> >
> >

Re: [Barry-devel] adding Spanish translation

[Chris F. <cd...@fo...>]

On Tue, Jun 12, 2012 at 11:29:12PM -0300, Cesar Ballardini wrote:
> 2012/6/12 Chris Frey <cd...@fo...>:
> > On Tue, Jun 12, 2012 at 07:13:11AM -0300, Cesar Ballardini wrote:
> [...]
> > I've attached the latest barry-backup.pot file.
> 
> Attached the barry-backup-es.po from barry-backup.pot and  es.po from
> po/barry.pot
> 
> Consider it a preview.  I need to build the software and test the GUI
> to see if the translations are appropiate.

Thanks!  I've added it to git, so you should be able just build from there
for your testing.  Please send a patch or update if you need to tweak it.

I only found the barry-backup es.po file atttached, not the barry one.

- Chris

[Barry-devel] adding Spanish translation

[Chris F. <cd...@fo...>]

On Tue, Jun 12, 2012 at 07:13:11AM -0300, Cesar Ballardini wrote:
> 2012/6/11 Chris Frey <cd...@fo...>:
> > To that end, would you be interested in helping me do a spanish translation
> > for the Barry tools and GUI? ?I could send you the files with various
> > strings in them, and you could translate them for me and send them back,
> > when you have time.
> 
> I will be my pleasure. Please send me as soon you can.  I don't
> remember the code now, are you using gettext?

Yes, we're using gettext, but so far, really only the Backup GUI is
sufficiently done.

I've attached the latest barry-backup.pot file.

If you are interested, the command line tools, man pages, and the Desktop GUI,
should all be done, but you'll have to wait on me as I go through that code
doing the conversion.

I assume you won't mind waiting.:-)

Anyway, we can start with the backup GUI.  You can browse the Barry source
code at http://repo.or.cz/w/barry.git and the code related to the .pot file
is under gui/src/.

Thanks!
- Chris

Re: [Barry-devel] Cross compiling barry for MIPS Architecture

[Chris F. <cd...@fo...>]

On Thu, May 31, 2012 at 08:46:11PM +0200, Nicolas wrote:
> Warning, MIPS are little endian & big endian. They are able to do the
> both modes.
> 
> So the autotools can't determine the endianness. 

In my tests with the GNU toolchains at least, autotools' endian checks
did succeed.  Whether that will end up with valid binaries, I don't know
since I don't have MIPS hardware to test on.  It also appeared that
the two different compilers (mips and mipsel) had different endianness.

Surely this is a compiler level issue, no?  Is it normal for a single
compiler to produce a MIPS binary that runs in both big and little endian
modes?  I don't have enough MIPS experience to know, but that would be
a surprise to me.

- Chris

Re: [Barry-devel] Cross compiling barry for MIPS Architecture

[Nicolas <pr...@fr...>]

Le lundi 28 mai 2012 à 16:45 +0530, Rajendra a écrit :
> Hi.
> 
> I am trying to cross compile barry package for MIPS architecture.
> To do this, i run the configure command  as 
> 
> ./configure --host=mips-linux
> --prefix=/home/rajendra/maxim-ic/rajendra_fs/
> 
> But end of configure i got the error as
> 
> checking whether byte ordering is bigendian... unknown
> configure: error: unknown endianness
> presetting ac_cv_c_bigendian=no (or yes) will help
> 
> For your clear understanding im attaching my terminal log.
> So kindly suggest me, what could be the problem for the above error.

Warning, MIPS are little endian & big endian. They are able to do the
both modes.

So the autotools can't determine the endianness. 

But you can impose the big endian or little endian mode.

You can also patch your toolchain to work only in an endian mode.

Regards,

Nicolas

Re: [Barry-devel] Cross compiling barry for MIPS Architecture

[Chris F. <cd...@fo...>]

On Tue, May 29, 2012 at 10:11:31AM +0530, Rajendra wrote:
> Hi Chris,
> 
> Thanks for your response.
> 
> I am using barry official release version: barry-0.15
                                                     ^^

Have you tried the latest release: barry-0.18.3?

That's what I've been testing with.

- Chris

Re: [Barry-devel] Cross compiling barry for MIPS Architecture

[Rajendra <raj...@ca...>]

Hi Chris,

Thanks for your response.

I am using barry official release version: barry-0.15
                     autoconf version: autoconf (GNU Autoconf) 2.61
                     Toolchain: mipsel-linux-uclibc-

i tried with ./configure --host=mips-linux-uclibc 
--prefix=/home/rajendra/maxim-ic/rajendra_fs/
but no use i got same endian error.

Regards,
Rajendra.

On Tuesday 29 May 2012 05:34 AM, Chris Frey wrote:
> On Mon, May 28, 2012 at 05:59:25PM -0400, Chris Frey wrote:
>> I'll have to try setting up a mips cross compiler here and see if I
>> can reproduce it.
> Ok, I've tested the autoconf stuff on Debian Squeeze (stable) using
> the emdebian.org toolchain packages, and I'm unable to reproduce the
> endian error.
>
> I used the following configure line:
>
> 	./configure --host=mips-linux-gnu --prefix=/tmp/rootdir-mips
>
> It might be a distro issue, or maybe it depends on which autoconf version
> you're using.  Did you rebuild configure yourself, or are you using the
> official Barry release tarballs?
>
> What distro are you using?
>
> Thanks,
> - Chris
>

Re: [Barry-devel] Cross compiling barry for MIPS Architecture

[Chris F. <cd...@fo...>]

On Mon, May 28, 2012 at 05:59:25PM -0400, Chris Frey wrote:
> I'll have to try setting up a mips cross compiler here and see if I
> can reproduce it.

Ok, I've tested the autoconf stuff on Debian Squeeze (stable) using
the emdebian.org toolchain packages, and I'm unable to reproduce the
endian error.

I used the following configure line:

	./configure --host=mips-linux-gnu --prefix=/tmp/rootdir-mips

It might be a distro issue, or maybe it depends on which autoconf version
you're using.  Did you rebuild configure yourself, or are you using the
official Barry release tarballs?

What distro are you using?

Thanks,
- Chris

Re: [Barry-devel] Cross compiling barry for MIPS Architecture

[Chris F. <cd...@fo...>]

On Mon, May 28, 2012 at 04:45:29PM +0530, Rajendra wrote:
> Hi.
> 
> I am trying to cross compile barry package for MIPS architecture.
> To do this, i run the configure command  as
> 
> ./configure --host=mips-linux --prefix=/home/rajendra/maxim-ic/rajendra_fs/
> 
> But end of configure i got the error as
> 
> *checking whether byte ordering is bigendian... unknown
> configure: error: unknown endianness
> presetting ac_cv_c_bigendian=no (or yes) will help

Hi Rajendra,

Thanks for your report.  It is hard to tell from the log you gave,
but I think more clues would be in the config.log file.

I'll have to try setting up a mips cross compiler here and see if I
can reproduce it.

- Chris

[Barry-devel] Cross compiling barry for MIPS Architecture

[Rajendra <raj...@ca...>]

rajendra@rajendra:~/maxim-ic/barry/barry$ ./configure --host=mips-linux --without-zlib --prefix=/home/rajendra/maxim-ic/rajendra_fs/

configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for mips-linux-strip... no
checking for strip... strip
checking for style of include used by make... GNU
checking for mips-linux-gcc... mipsel-linux-uclibc-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether mipsel-linux-uclibc-gcc accepts -g... yes
checking for mipsel-linux-uclibc-gcc option to accept ISO C89... none needed
checking dependency style of mipsel-linux-uclibc-gcc... gcc3
checking how to run the C preprocessor... mipsel-linux-uclibc-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for AIX... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking build system type... i686-pc-linux-gnu
checking host system type... mips-unknown-linux-gnu
checking for ld used by GCC... mipsel-linux-uclibc-ld
checking if the linker (mipsel-linux-uclibc-ld) is GNU ld... yes
checking for shared library run path origin... done
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... no
checking for iconv... no, consider installing GNU libiconv
checking for GNU gettext in libintl... no
checking whether to use NLS... no
checking for mips-linux-gcc... (cached) mipsel-linux-uclibc-gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether mipsel-linux-uclibc-gcc accepts -g... (cached) yes
checking for mipsel-linux-uclibc-gcc option to accept ISO C89... (cached) none needed
checking dependency style of mipsel-linux-uclibc-gcc... (cached) gcc3
checking whether we are using the GNU C++ compiler... no
checking whether mipsel-linux-uclibc-cpp accepts -g... no
checking dependency style of mipsel-linux-uclibc-cpp... none
checking whether make sets $(MAKE)... (cached) yes
checking for a sed that does not truncate output... /bin/sed
checking for ld used by mipsel-linux-uclibc-gcc... mipsel-linux-uclibc-ld
checking if the linker (mipsel-linux-uclibc-ld) is GNU ld... yes
checking for mipsel-linux-uclibc-ld option to reload object files... -r
checking for BSD-compatible nm... nm
checking whether ln -s works... yes
checking how to recognize dependent libraries... pass_all
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... /lib/cpp
checking for mips-linux-g77... no
checking for mips-linux-xlf... no
checking for mips-linux-f77... no
checking for mips-linux-frt... no
checking for mips-linux-pgf77... no
checking for mips-linux-cf77... no
checking for mips-linux-fort77... no
checking for mips-linux-fl32... no
checking for mips-linux-af77... no
checking for mips-linux-xlf90... no
checking for mips-linux-f90... no
checking for mips-linux-pgf90... no
checking for mips-linux-pghpf... no
checking for mips-linux-epcf90... no
checking for mips-linux-gfortran... no
checking for mips-linux-g95... no
checking for mips-linux-xlf95... no
checking for mips-linux-f95... no
checking for mips-linux-fort... no
checking for mips-linux-ifort... no
checking for mips-linux-ifc... no
checking for mips-linux-efc... no
checking for mips-linux-pgf95... no
checking for mips-linux-lf95... no
checking for mips-linux-ftn... no
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for xlf95... no
checking for f95... no
checking for fort... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 98304
checking command to parse nm output from mipsel-linux-uclibc-gcc object... ok
checking for objdir... .libs
checking for mips-linux-ar... no
checking for ar... ar
configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet.  If you think this
configuration is useful to you, please write to aut...@gn....
checking for mips-linux-ranlib... no
checking for ranlib... ranlib
checking for mips-linux-strip... strip
checking if mipsel-linux-uclibc-gcc supports -fno-rtti -fno-exceptions... no
checking for mipsel-linux-uclibc-gcc option to produce PIC... -fPIC
checking if mipsel-linux-uclibc-gcc PIC flag -fPIC works... yes
checking if mipsel-linux-uclibc-gcc static flag -static works... yes
checking if mipsel-linux-uclibc-gcc supports -c -o file.o... yes
checking whether the mipsel-linux-uclibc-gcc linker (mipsel-linux-uclibc-ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking whether the mipsel-linux-uclibc-cpp linker (mipsel-linux-uclibc-ld) supports shared libraries... yes
libtool.m4: error: problem compiling CXX test program
checking for mipsel-linux-uclibc-cpp option to produce PIC... 
checking if mipsel-linux-uclibc-cpp static flag  works... no
checking if mipsel-linux-uclibc-cpp supports -c -o file.o... no
checking whether the mipsel-linux-uclibc-cpp linker (mipsel-linux-uclibc-ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
(cached) (cached) checking how to hardcode library paths into programs... unsupported
appending configuration tag "F77" to libtool
checking for a sed that does not truncate output... /bin/sed
checking whether the C compiler accepts the -fvisibility=hidden flag... yes
checking whether the C++ compiler accepts the -fvisibility=hidden flag... no
Guessing libtar location... may not compile...
checking for tar_open in -ltar... no
configure: Libtar NOT found, disabling libbarrybackup
Guessing zlib location... may not compile...
checking for mips-linux-pkg-config... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBUSB... yes
configure: using BOOST library... no
checking for FUSE... no
FUSE library not found, skipping fuse module.
checking for GLIB2... no
GLIB 2.0 not found, skipping sync library.
checking for main in -lpthread... no
checking for crc32 in -lz... no
*****************************************************************
WARNING: zlib not found... packed .cod files will fail crc checks
*****************************************************************
checking for LIBXMLXX... no
*****************************************************************
WARNING: libxml++ not found... ALX parser not included
*****************************************************************
checking for iconv... (cached) no, consider installing GNU libiconv
checking for dirent.h that defines DIR... no
checking for sys/ndir.h that defines DIR... no
checking for sys/dir.h that defines DIR... no
checking for ndir.h that defines DIR... no
checking for library containing opendir... no
checking for ANSI C header files... (cached) yes
checking assert.h usability... no
checking assert.h presence... yes
configure: WARNING: assert.h: present but cannot be compiled
configure: WARNING: assert.h:     check for missing prerequisite headers?
configure: WARNING: assert.h: see the Autoconf documentation
configure: WARNING: assert.h:     section "Present But Cannot Be Compiled"
configure: WARNING: assert.h: proceeding with the preprocessor's result
configure: WARNING: assert.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to bar...@li... ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for assert.h... yes
checking for stdint.h... (cached) yes
checking time.h usability... no
checking time.h presence... yes
configure: WARNING: time.h: present but cannot be compiled
configure: WARNING: time.h:     check for missing prerequisite headers?
configure: WARNING: time.h: see the Autoconf documentation
configure: WARNING: time.h:     section "Present But Cannot Be Compiled"
configure: WARNING: time.h: proceeding with the preprocessor's result
configure: WARNING: time.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to bar...@li... ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for time.h... yes
checking whether time.h and sys/time.h may both be included... no
checking whether struct tm is in sys/time.h or time.h... sys/time.h
checking for working strnlen... no
checking whether closedir returns void... yes
checking whether mipsel-linux-uclibc-gcc needs -traditional... no
checking sys/select.h usability... no
checking sys/select.h presence... yes
configure: WARNING: sys/select.h: present but cannot be compiled
configure: WARNING: sys/select.h:     check for missing prerequisite headers?
configure: WARNING: sys/select.h: see the Autoconf documentation
configure: WARNING: sys/select.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/select.h: proceeding with the preprocessor's result
configure: WARNING: sys/select.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to bar...@li... ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for sys/select.h... yes
checking sys/socket.h usability... no
checking sys/socket.h presence... yes
configure: WARNING: sys/socket.h: present but cannot be compiled
configure: WARNING: sys/socket.h:     check for missing prerequisite headers?
configure: WARNING: sys/socket.h: see the Autoconf documentation
configure: WARNING: sys/socket.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/socket.h: proceeding with the preprocessor's result
configure: WARNING: sys/socket.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------------ ##
configure: WARNING:     ## Report this to bar...@li... ##
configure: WARNING:     ## ------------------------------------------------ ##
checking for sys/socket.h... yes
checking types of arguments for select... int,int *,struct timeval *
checking for bzero... no
checking for gettimeofday... no
checking for memset... no
checking for select... no
checking for strcasecmp... no
checking for strchr... no
checking for strerror... no
checking for strtol... no
checking for strtoul... no
checking whether byte ordering is bigendian... unknown
configure: error: unknown endianness
presetting ac_cv_c_bigendian=no (or yes) will help
rajendra@rajendra:~/maxim-ic/barry/barry$ 

[Barry-devel] Barry Desktop version 0.18.3 released

[Chris F. <cd...@fo...>]

The Barry development team is pleased to announce the release of
version 0.18.3.  Source and binary packages are available for immediate
download at the URLs below.

Barry is an Open Source application that provides a Desktop GUI,
synchronization, backup, restore, program management, and raw channel
support for BlackBerry devices.

Barry is primarily developed on Linux, but is intended as a cross platform
library and application set, targeting Linux, BSD, 32/64bit, and
big/little endian systems.  The command line utilities have been reported
to work on Mac OSX and Windows using Cygwin and libusb.

(Note: versions 0.18.1 and 0.18.2 were source-only releases for Debian.)

What's New?
-----------

This release contains some exciting new features:

	* Fedora 14 and 16 yum support

	* Ubuntu 12.04 binary packages, with apt repository

	* Added Evolution3 opensync plugin support to Desktop
	  (now both evolution2 and evolution3 plugins supported)

	* Made Evolution plugin configuration in the Desktop much more
	  flexible and forgiving

	* Added ability to import and export vcard and vevent objects
	  directly into and out of the device, using the Desktop GUI
	  (Address Book, Calendar, Memos, and Tasks supported)

	* New libtar0 binary packages available on Ubuntu
	  to fix FORTIFY_SOURCE crashes

	* Library features and bugfixes:
		- MimeDump template class to library
		- pkg-config now properly uses libbarry-18 for
		  the library name instead of libbarry-0

	* Fixed parsing and syncing of recurring calendar items

	* Fixed the opensync vformat plugin to recognize lower case
	  parameter values, which fixes a sync issue with evolution


Download:
---------

Binary packages (32 and 64bit) and sources are available on SourceForge for
the following distros:

        Debian stable (squeeze)
        Ubuntu 10.04, 11.04, 11.10, 12.04
        Fedora 14, 16

        http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/



Apt Repository:
---------------

Apt users can also install Barry by adding the following to sources.list:

        deb http://download.barry.netdirect.ca/barry-0.18.3/ squeeze main

        or

        deb http://download.barry.netdirect.ca/barry-latest/ squeeze main

Replace "squeeze" with ubuntu1004, ubuntu1104, ubuntu1110, or ubuntu1204
as needed.  The GPG key can be found on the public key servers.
Its fingerprint is:

        82DE DE11 74C1 0EA7 C55D  5679 3B52 35AE B6C2 250E


Yum Repository:
---------------

Fedora users can create a new barry.repo file in /etc/yum.repos.d/ with
the following contents:

	[Barry]
	name=Barry for Fedora $releasever - $basearch
	failovermethod=priority
	baseurl=http://download.barry.netdirect.ca/barry-latest/dists/fedora$releasever/i686/
	enabled=1
	metadata_expire=7d
	gpgcheck=1
	gpgkey=http://download.barry.netdirect.ca/barry-latest/dists/fedora$releasever/i686/RPM-GPG-KEY-barry

	[Barry-source]
	name=Barry sources for Fedora $releasever - Source
	failovermethod=priority
	baseurl=http://download.barry.netdirect.ca/barry-latest/dists/fedora$releasever/source-i686/
	enabled=1
	metadata_expire=7d
	gpgcheck=1
	gpgkey=http://download.barry.netdirect.ca/barry-latest/dists/fedora$releasever/source-i686/RPM-GPG-KEY-barry



Documentation:
--------------

The Barry documentation is available online at the usual place:

        http://netdirect.ca/barry

Documentation updates to better reflect version 0.18.x are planned.
Stay tuned.


Please report any bugs or problems you have to the barry-devel mailing list.
Also, please report which features you are most interested in.

Enjoy!



CREDITS:

Contributors in this release: (alphabetical order by last name)
        intrigeri                       - debian packaging
	Nicolas VIVIEN			- the evolution3 plugin itself




Chris Frey (63):
      doc: version bump to 0.18.0 in main index page
      doc: updated ReleaseChecklist.txt
      Use version strings from configure instead of hardcoded
      debian: removed hardcoded libbarry18 from plugin control files
      desktop: removed some commented code
      desktop: added support for evo3-sync plugin
      desktop: made all Plugin class members virtual
      maint: enable evo3-sync plugin builds in binary-meta scripts
      maint: removed libopensync-devel from fedora depscript
      desktop: fixed Evolution3 class pointer return override
      desktop: use os4x's osync_error_print_stack() for more detailed error msgs
      debian: fixed syntax errors for debian/copyright
      maint: renamed RPM GPG key filename from -binary-meta to -barry
      Barry version 0.18.1 (debian sid release)
      maint: updated 32 and 64bit build scripts for Ubuntu support
      maint: added proper sample of Barry yum repo file for Fedora
      maint: added apt conf file for ubuntu 12.04
      debian: changed copyright fields to avoid UTF-8 characters, with formatting
      debian: split vformat.{h,c} into separate items, to avoid any syntax issues
      debian: clarified Source field
      doc: added comment in src/fifoargs.cc regarding its security assumptions
      debian: beefed up some control descriptions to avoid lintian warnings
      debian: added new lintian overrides for sid builds
      Barry version 0.18.1-2 (debian sid release)
      debian: removed trailing colon from copyright Files line
      debian: added ${misc:Depends} to binary packages since we use debhelper
      Barry version 0.18.1-3 (debian sid release)
      Version: fixed pkg-config files to use major version 18 instead of old 0
      doc: updated ReleaseChecklist.txt to include .pc file versioning
      Barry version 0.18.2
      lib: moved mimedump.h from tools/ into the library (mimeio.h)
      desktop: added Import and Export buttons to Browse mode (MIME vcard support)
      maint: added XML configs for ABI checking: 0.17.2, 0.18.0, 0.18.2, 0.18.3
      doc: more updates to ReleaseChecklist.txt
      Barry version 0.18.3
      debian: fixed .lintian-overrides, making them less version specific
      maint: added deb-libtar target to all Ubuntu bm builds
      maint: added rpmclean to Fedora and openSUSE rpm builds
      doc: updated ReleaseChecklist.txt yet again
      maint: changed abi checker script to use git tags instead of tarballs
      debian: barrydesktop binary package recommends barrybackup-gui
      maint: added hint on gpg-agent usage to signing scripts
      desktop: change SyncStatusDlg to resizeable
      desktop: fixed SyncStatusDlg resize bug
      debian/rpm: fixed desktop and backup menu icon names and .desktop config
      lib: fixed parsing of recurring VEVENTS: DAILY and interval support
      doc: updated ReleaseChecklist.txt
      desktop: fixed bug where menu's Rename Device option got incorrectly disabled
      desktop: fixed bug that deleted device name if saving an unconnected sync cfg
      desktop: added concept of configured PST type mask
      desktop: fixed Evolution config writing, setting enabled only if URL is present
      desktop: EvoCfgDlg: add default path option, and show current cfg better
      lib: added DaysInMonth() utility function
      lib: fixed Interval handling, in case of negative input value
      lib: added warning checks for unsupported recursion fields in vevent.cc
      lib: improved error message reporting in vevent.cc
      lib: fixed RecurBase class's Dump output, to use decimal numbers
      lib: remove some of the copious calls to localtime_r() in vevent.cc
      lib: replace month normalization code with mktime() in vevent.cc
      lib: added handling and checks for negative VEVENT recurrence values
      Revert "debian: added support for hardened builds"
      doc: updated ReleaseChecklist.txt
      lib: added NICKNAME support to vcard, and therefore to sync as well

intrigeri (1):
      Reformat debian/copyright to suit informal style habits.

Re: [Barry-devel] Evolution3 sync support added in git

[Nicolas <pr...@fr...>]

Le mardi 08 mai 2012 à 02:24 -0400, Chris Frey a écrit :
> On Mon, May 07, 2012 at 11:23:32AM +0100, Nicolas wrote:
> > I have done some workarounds only for OwnCloud.
> > 
> > For BlackBerry mobiles :
> > 
> > OwnCloud
> >   CalDAV  <=> Evolution <=> Evo3-sync <=> OpenSync <=> barry-sync
> >     &
> >   CardDAV
> > 
> > 
> > And for PlayBook, I have (need workaround into OwnCloud)
> > 
> > OwnCloud
> >   CalDAV
> >     &     <=> PlayBook
> >   CardDAV
> > 
> > 
> > And all my client (Evolution, Thunderbird or RoundCube) I use, as
> > PlayBook, caldav & carddav directly.
> 
> Hmmmmm... that BlackBerry sync process looks like it's going through
> a lot of steps to reach OwnCloud.  Although syncing to Evolution is
> pretty handy.  I think you can even access Google Calendar through it.
>
> Since Barry can produce vcard style data, is there an opportunity to
> make Barry more friendly with OwnCloud?

To sync blackberry mobile with caldav/carddav, we can use a
carddav/caldav plugin for opensync. caldav plugin exists already but I
think that the code isn't updated.

It could be an other solution. But today, it works well. I don't need
more.

I'll wait the next blackberry mobile generation that works as playbook
(so with caldav/cardav native support).

> Are you using the PlayBook as a UI client merely to access the cloud data,
> or does the PlayBook have the ability to sync contact data directly to itself?

With PlayBook I can access only to cardav/caldav features provided by
owncloud. So contacts and events are synced without addons. But, I can't
use it for data (files, documents...) ! But I'm writing a client for it.

Regards,

Nicolas

Re: [Barry-devel] Evolution3 sync support added in git

[Chris F. <cd...@fo...>]

On Mon, May 07, 2012 at 11:23:32AM +0100, Nicolas wrote:
> I have done some workarounds only for OwnCloud.
> 
> For BlackBerry mobiles :
> 
> OwnCloud
>   CalDAV  <=> Evolution <=> Evo3-sync <=> OpenSync <=> barry-sync
>     &
>   CardDAV
> 
> 
> And for PlayBook, I have (need workaround into OwnCloud)
> 
> OwnCloud
>   CalDAV
>     &     <=> PlayBook
>   CardDAV
> 
> 
> And all my client (Evolution, Thunderbird or RoundCube) I use, as
> PlayBook, caldav & carddav directly.

Hmmmmm... that BlackBerry sync process looks like it's going through
a lot of steps to reach OwnCloud.  Although syncing to Evolution is
pretty handy.  I think you can even access Google Calendar through it.

Since Barry can produce vcard style data, is there an opportunity to
make Barry more friendly with OwnCloud?

Are you using the PlayBook as a UI client merely to access the cloud data,
or does the PlayBook have the ability to sync contact data directly to itself?

Thanks,
- Chris

Re: [Barry-devel] Evolution3 sync support added in git

[Nicolas <pr...@fr...>]

Le dimanche 06 mai 2012 à 16:57 -0400, Chris Frey a écrit :
> On Sun, May 06, 2012 at 07:02:13PM +0200, Nicolas wrote:
> > Here, it used every days without issue. Work and tested on debian 
> sid
> > and on last fedora release (in using metapackage to build deb/rpm).
>
> Excellent.  I did find a potential segfault bug in the evo3-sync 
> plugin
> which the latest git fixes.
>
>
> > NB: for opencloud, we need still some workarounds that I can 
> provide if
> > need.
>
> Workarounds in Barry or opensync?  I'm interested in either.
>
> Thanks,
> - Chris

Sorry not opencloud but owncloud :)


I have done some workarounds only for OwnCloud.

For BlackBerry mobiles :

OwnCloud
  CalDAV  <=> Evolution <=> Evo3-sync <=> OpenSync <=> barry-sync
    &
  CardDAV


And for PlayBook, I have (need workaround into OwnCloud)

OwnCloud
  CalDAV
    &     <=> PlayBook
  CardDAV


And all my client (Evolution, Thunderbird or RoundCube) I use, as
PlayBook, caldav & carddav directly.


Regards,

Nicolas