SynCE 0.12

[Jonny Lamb]

Hi all,

SynCE 0.12 is out. There would be comic names for SynCE releases, but
we're just too solemn for that kind of thing.

What's new
==========

There has been steady progress with this release. I will not summarize
here -- check out the SVN logs. The roadmap for this release and its
status can be found at:

http://synce.org/moin/SynceRoadmap

As you can see, most things were implemented. Other than that, you'll
have to dig deeper yourself, sorry!

If you have any big cool ideas about the future of SynCE, its direction,
and any feature you'd love to have around, let us know. We will not
promise anything, but are interested to hear your thoughts!

New files and their md5sums
===========================

80aa988bb37e40066abf204c6a8d6f7a librapi2-0.12.tar.gz
867b29f88df6a7706c2a4b2bda658c9e librra-0.12.tar.gz
fd473d3deceda7912af4427dede1736f libsynce-0.12.tar.gz
03c833e4adb5ec17d32ac338cf1a6d18 odccm-0.12.tar.gz
b460273d980c6ce0289f0beca9484f78 synce-gnomevfs-0.12.tar.gz
06c7fe3d2b9c130cd485272d6756f599 synce-hal-0.2.tar.gz
8ea4995167ae8a5014eb9504bde51281 synce-kpm-0.12.tar.gz
2886545a8f7a029063b9b5f804806e23 sync-engine-0.12.tar.gz

You can find these files on your favourite SourceForge mirror. These
will also turn up in distribution repositories some time soon. I'll try
and get them into Debian soon, but I severely doubt they'll make Lenny.

Missing files
=============

I did not release synce-trayicon or gvfs because their Makefiles are broken
and I couldn't create a dist tarball. Once this is fixed, I'll be more
than happy to release!

I did not release kde-rapip{,-kde4} because I was unsure whether it was
wanted. I had a quick look through synce-devel archives and noticed that
when I asked this question, I got no answer. If you want it released,
tell me.

Development notices
===================

For all new releases I will *not* be bumping the requirements on any
libraries inside configure.ac files. I could be wrong, but I feel that
they aren't being updated properly, so I'm upping the deps on every
release, which is probably rather unnecessary. If you implement
something in a module which requires the development version of, say,
libsynce, depend on the current version + 1.

Although, this now does depend on setting the library versions
"correctly". The way it should be done AFAIK, as I pointed out to Guido
today, is that once a, say, 0.1 release is done and tarballs are
released, the version number in configure.ac should be increased. This
helps with the previous case of deps, and it also makes it clear if
someone is running an development version.

I will try and get this done soon, but I'm very busy at the moment.

Credits
=======

I know I'm going to miss people off here so I'm sorry. The big guns of
SynCE these days are Mark Ellis, Guido Diepen, John Gow, John Carr,
recently Tejas Guruswamy, and more.. If you see any of these people
around, be sure to thank them for their excellent work.

A special thanks to Mark Ellis who seems to be driving the project these
days with his great checkins! Keep it up! :-)

The end
=======

That's it. Contact me if you need anything, etc.

Regards,

[Adam Williamson]

Post by Jonny Lamb
Hi all,
SynCE 0.12 is out. There would be comic names for SynCE releases, but
we're just too solemn for that kind of thing.

Thanks for this! Packages will hit Mandriva repos soon.

Quick note: I think kpm-hal.diff should be removed from
trunk/hal/patches in SVN, as it appears to have been committed to kpm
0.12.

[Adam Williamson]

Post by Adam Williamson

Post by Jonny Lamb
Hi all,
SynCE 0.12 is out. There would be comic names for SynCE releases, but
we're just too solemn for that kind of thing.

Thanks for this! Packages will hit Mandriva repos soon.

Oh dear.

Why did synce-hal get versioned 0.2, out of sync with all other
components?

I packaged it from SVN before any release was made, and assumed 0.11.1
for the version (figuring the first official release would be 0.12 or
0.13 or whatever the rest of synce was at at the time). Now if I want to
package this stable release I'll have to use an Epoch tag, which is
excessively ugly and avoided wherever possible.

I don't suppose there's any chance it could be re-versioned 0.12?

[John Carr]

Post by Adam Williamson

Post by Adam Williamson

Post by Jonny Lamb
Hi all,
SynCE 0.12 is out. There would be comic names for SynCE releases, but
we're just too solemn for that kind of thing.

Thanks for this! Packages will hit Mandriva repos soon.

Oh dear.
Why did synce-hal get versioned 0.2, out of sync with all other
components?
I packaged it from SVN before any release was made, and assumed 0.11.1
for the version (figuring the first official release would be 0.12 or
0.13 or whatever the rest of synce was at at the time). Now if I want to
package this stable release I'll have to use an Epoch tag, which is
excessively ugly and avoided wherever possible.
I don't suppose there's any chance it could be re-versioned 0.12?
--
adamw

+1 on versioning it in line with odccm in future, as it is basically a
souped up odccm rather than something from scratch... And its not like odccm
has gone through as many versions as libsynce, either. Its also nice for the
core components to be in step with each other for clarities sake.

It would also be nice if we packaged this in favor of odccm this time
around, and started to phase out odccm.

John

[Adam Williamson]

Post by John Carr
+1 on versioning it in line with odccm in future, as it is basically a
souped up odccm rather than something from scratch... And its not like
odccm has gone through as many versions as libsynce, either. Its also
nice for the core components to be in step with each other for
clarities sake.
It would also be nice if we packaged this in favor of odccm this time
around, and started to phase out odccm.

For now I'll package another 'svn snapshot' (even if it's identical to
0.2) and keep versioning it 0.11.1, to avoid using an epoch - hopefully
it can get re-versioned to 0.12 and then there won't be a problem.

I already killed odccm in Mandriva development distro (Cooker) several
weeks back. It's all HAL now. Once I've tested both WM2003 and WM5+ in
Cooker to my satisfaction, I'll backport the whole bundle to 2008
Spring's /backports repository.

[Jonny Lamb]

Post by Adam Williamson
For now I'll package another 'svn snapshot' (even if it's identical to
0.2) and keep versioning it 0.11.1, to avoid using an epoch - hopefully
it can get re-versioned to 0.12 and then there won't be a problem.

synce-hal 0.11.1 does not exist. It would be much more wise to use the
correct version number, for obvious reasons. Using an epoch cannot be
that hard. If it is, then I'd say there's something wrong with your
packaging system (I am going on what one must do with epochs in Debian;
they are frightfully easy to use).

[Adam Williamson]

Post by Jonny Lamb

Post by Adam Williamson
For now I'll package another 'svn snapshot' (even if it's identical to
0.2) and keep versioning it 0.11.1, to avoid using an epoch - hopefully
it can get re-versioned to 0.12 and then there won't be a problem.

synce-hal 0.11.1 does not exist. It would be much more wise to use the
correct version number, for obvious reasons. Using an epoch cannot be
that hard. If it is, then I'd say there's something wrong with your
packaging system (I am going on what one must do with epochs in Debian;
they are frightfully easy to use).

They're not hard to use from the packager's perspective, but they screw
up the versioning forever more (to a casual glance it will look like
it's version 0.2, but it's 'really' version 1:0.2, and that's what
you'll have to use for comparisons) as it can't ever be removed again.
That's why we avoid the use of epochs wherever possible.

You're right that there was always a VERSION file which specified 0.1,
though - I must have missed that. Sorry :\

[Jonny Lamb]

Post by Adam Williamson
They're not hard to use from the packager's perspective, but they screw
up the versioning forever more (to a casual glance it will look like
it's version 0.2, but it's 'really' version 1:0.2, and that's what
you'll have to use for comparisons) as it can't ever be removed again.
That's why we avoid the use of epochs wherever possible.

Well, sorry to be harsh, but this is just not my problem. You ignored
the version number for some unspecified reason.

The next version will be 0.13.

[Adam Williamson]

Post by Jonny Lamb

Post by Adam Williamson
They're not hard to use from the packager's perspective, but they screw
up the versioning forever more (to a casual glance it will look like
it's version 0.2, but it's 'really' version 1:0.2, and that's what
you'll have to use for comparisons) as it can't ever be removed again.
That's why we avoid the use of epochs wherever possible.

Well, sorry to be harsh, but this is just not my problem. You ignored
the version number for some unspecified reason.

Thanks for the selective quoting: it was hardly unspecified. The very
next paragraph explained that it was just a mistake.

[Jonny Lamb]

[Please don't CC me in replies. I read lists I write to. Also, please
don't cross-post.]

Post by Adam Williamson
Why did synce-hal get versioned 0.2, out of sync with all other
components?

Because the author versioned it originally 0.1. 0.2 is a clear
progression from 0.1.

Post by Adam Williamson
I packaged it from SVN before any release was made, and assumed 0.11.1
for the version (figuring the first official release would be 0.12 or
0.13 or whatever the rest of synce was at at the time). Now if I want to
package this stable release I'll have to use an Epoch tag, which is
excessively ugly and avoided wherever possible.

This was a mistake on your part. There is nothing to say that every
SynCE module will have exactly the same version number. pywbxml and
librtfcomp have different version numbers, for example. You will have to
use an epoch tag.

Post by Adam Williamson
I don't suppose there's any chance it could be re-versioned 0.12?

No. I'll change it for the next release so it's in sync with the other
modules but this really isn't my problem.

[Mark Ellis]

Post by Adam Williamson
Thanks for this! Packages will hit Mandriva repos soon.
Quick note: I think kpm-hal.diff should be removed from
trunk/hal/patches in SVN, as it appears to have been committed to kpm
0.12.
--

Nuts, forgot about that, it will disappear soon....

Mark

[Adam Williamson]

Post by Mark Ellis

Post by Adam Williamson
Thanks for this! Packages will hit Mandriva repos soon.
Quick note: I think kpm-hal.diff should be removed from
trunk/hal/patches in SVN, as it appears to have been committed to kpm
0.12.
--

Nuts, forgot about that, it will disappear soon....

One more thing :) Should we switch synce-trayicon to use hal as its
default dccm rather than odccm? seems like hal-dccm is the wave of the
future.

I just attempted to patch this in Mandriva - is just changing the
default in the .schema file enough, or is more needed?

[Mark Ellis]

Post by Adam Williamson

Post by Mark Ellis

Post by Adam Williamson
Thanks for this! Packages will hit Mandriva repos soon.
Quick note: I think kpm-hal.diff should be removed from
trunk/hal/patches in SVN, as it appears to have been committed to kpm
0.12.
--

Nuts, forgot about that, it will disappear soon....

One more thing :) Should we switch synce-trayicon to use hal as its
default dccm rather than odccm? seems like hal-dccm is the wave of the
future.

Probably :)

Post by Adam Williamson
I just attempted to patch this in Mandriva - is just changing the
default in the .schema file enough, or is more needed?
--

Your mission should you choose to accept it...

synce-trayicon.c, lines 795 to 805

Fiddling around with that should work, shout if it doesn't.

If in mandriva you've basically dropped odccm, then yes it should be
default. I'm not sure about the main 0.12 release, still time to think
while we get the make dist think sorted.

Mark

[Mark Ellis]

Post by Mark Ellis

Post by Adam Williamson

Post by Mark Ellis

Post by Adam Williamson
Thanks for this! Packages will hit Mandriva repos soon.
Quick note: I think kpm-hal.diff should be removed from
trunk/hal/patches in SVN, as it appears to have been committed to kpm
0.12.
--

Nuts, forgot about that, it will disappear soon....

One more thing :) Should we switch synce-trayicon to use hal as its
default dccm rather than odccm? seems like hal-dccm is the wave of the
future.

Probably :)

Post by Adam Williamson
I just attempted to patch this in Mandriva - is just changing the
default in the .schema file enough, or is more needed?
--

Your mission should you choose to accept it...
synce-trayicon.c, lines 795 to 805
Fiddling around with that should work, shout if it doesn't.

Actually that's rubbish isn't it, I wrote that part while I was still
getting back into gnome. I'll try and improve that for 0.13.

Post by Mark Ellis
If in mandriva you've basically dropped odccm, then yes it should be
default. I'm not sure about the main 0.12 release, still time to think
while we get the make dist think sorted.
Mark

[Mark Ellis]

Post by Mark Ellis

Post by Mark Ellis

Post by Adam Williamson

Post by Mark Ellis

Post by Adam Williamson
Thanks for this! Packages will hit Mandriva repos soon.
Quick note: I think kpm-hal.diff should be removed from
trunk/hal/patches in SVN, as it appears to have been committed to kpm
0.12.
--

Nuts, forgot about that, it will disappear soon....

One more thing :) Should we switch synce-trayicon to use hal as its
default dccm rather than odccm? seems like hal-dccm is the wave of the
future.

Probably :)

Post by Adam Williamson
I just attempted to patch this in Mandriva - is just changing the
default in the .schema file enough, or is more needed?
--

Your mission should you choose to accept it...
synce-trayicon.c, lines 795 to 805
Fiddling around with that should work, shout if it doesn't.

Actually that's rubbish isn't it, I wrote that part while I was still
getting back into gnome. I'll try and improve that for 0.13.

Post by Mark Ellis
If in mandriva you've basically dropped odccm, then yes it should be
default. I'm not sure about the main 0.12 release, still time to think
while we get the make dist think sorted.
Mark

Addendum to my previous comments. Yes, if you change the default in the
schema, it will work. Because there is a default, it will override the
rubbish bit of code.

Apologies for the confusion :)

Mark

[Adam Williamson]

Post by Mark Ellis

Post by Mark Ellis
If in mandriva you've basically dropped odccm, then yes it should be
default. I'm not sure about the main 0.12 release, still time to think
while we get the make dist think sorted.
Mark

Addendum to my previous comments. Yes, if you change the default in the
schema, it will work. Because there is a default, it will override the
rubbish bit of code.
Apologies for the confusion :)

Roger. I thought that might be the case but I patched both in the end,
anyway. At least it'll cover any odd eventuality.

I can send the patch but it's hardly worth it, the changes are
ridiculously logical of course.

[Mark Ellis]

Post by Adam Williamson

Post by Mark Ellis

Post by Mark Ellis
If in mandriva you've basically dropped odccm, then yes it should be
default. I'm not sure about the main 0.12 release, still time to think
while we get the make dist think sorted.
Mark

Addendum to my previous comments. Yes, if you change the default in the
schema, it will work. Because there is a default, it will override the
rubbish bit of code.
Apologies for the confusion :)

Roger. I thought that might be the case but I patched both in the end,
anyway. At least it'll cover any odd eventuality.
I can send the patch but it's hardly worth it, the changes are
ridiculously logical of course.
--

That's cool. I'm going to fix it up properly anyway, so the only default
comes from the schema.

Mark

[Mark Ellis]

Post by Jonny Lamb
Hi all,
SynCE 0.12 is out. There would be comic names for SynCE releases, but
we're just too solemn for that kind of thing.

<grin>

Post by Jonny Lamb
What's new
==========
There has been steady progress with this release. I will not summarize
here -- check out the SVN logs. The roadmap for this release and its
http://synce.org/moin/SynceRoadmap

I have kernel questions, but that's another thread.

Post by Jonny Lamb
As you can see, most things were implemented. Other than that, you'll
have to dig deeper yourself, sorry!
If you have any big cool ideas about the future of SynCE, its direction,
and any feature you'd love to have around, let us know. We will not
promise anything, but are interested to hear your thoughts!
New files and their md5sums
===========================
80aa988bb37e40066abf204c6a8d6f7a librapi2-0.12.tar.gz
867b29f88df6a7706c2a4b2bda658c9e librra-0.12.tar.gz
fd473d3deceda7912af4427dede1736f libsynce-0.12.tar.gz
03c833e4adb5ec17d32ac338cf1a6d18 odccm-0.12.tar.gz
b460273d980c6ce0289f0beca9484f78 synce-gnomevfs-0.12.tar.gz
06c7fe3d2b9c130cd485272d6756f599 synce-hal-0.2.tar.gz
8ea4995167ae8a5014eb9504bde51281 synce-kpm-0.12.tar.gz
2886545a8f7a029063b9b5f804806e23 sync-engine-0.12.tar.gz
You can find these files on your favourite SourceForge mirror. These
will also turn up in distribution repositories some time soon. I'll try
and get them into Debian soon, but I severely doubt they'll make Lenny.
Missing files
=============
I did not release synce-trayicon or gvfs because their Makefiles are broken
and I couldn't create a dist tarball. Once this is fixed, I'll be more
than happy to release!

What happened with trayicon ? I keep forgetting to test make dist...

gvfs I don't know what to do with yet.

Post by Jonny Lamb
I did not release kde-rapip{,-kde4} because I was unsure whether it was
wanted. I had a quick look through synce-devel archives and noticed that
when I asked this question, I got no answer. If you want it released,
tell me.

I'd say yes, but packagers will have to bear in mind to make it
conflict
with synce-kde.

Post by Jonny Lamb
Development notices
===================
For all new releases I will *not* be bumping the requirements on any
libraries inside configure.ac files. I could be wrong, but I feel that
they aren't being updated properly, so I'm upping the deps on every
release, which is probably rather unnecessary. If you implement
something in a module which requires the development version of, say,
libsynce, depend on the current version + 1.
Although, this now does depend on setting the library versions
"correctly". The way it should be done AFAIK, as I pointed out to Guido
today, is that once a, say, 0.1 release is done and tarballs are
released, the version number in configure.ac should be increased. This
helps with the previous case of deps, and it also makes it clear if
someone is running an development version.
I will try and get this done soon, but I'm very busy at the moment.

Agreed. I've often made commits that depend on something else since the
last release, with no way to make that clear. Maybe we should only bump
the version in svn after something has been committed, otherwise we
imply changes that haven't happened. Too complicated ?

Mark

[Jonny Lamb]

Post by Mark Ellis
What happened with trayicon ? I keep forgetting to test make dist...

% make dist
make: *** No rule to make target `intltool-merge.in', needed by distdir'. Stop.

Good luck debugging intltool. :-)

Post by Mark Ellis
gvfs I don't know what to do with yet.

Take your time. I can guess that both you and I aren't too fussed about
distribution inclusion, as GVFS isn't being included in Lenny.

Post by Mark Ellis
Agreed. I've often made commits that depend on something else since the
last release, with no way to make that clear. Maybe we should only bump
the version in svn after something has been committed, otherwise we
imply changes that haven't happened. Too complicated ?

I don't /quite/ understand what you mean, but I propose this workflow:

The last release of tool x is, for the sake of this example, 0.1. x
depends on liby, which had a 0.1 release recently. When working on these
modules, the version in configure.ac (or VERSION) should be 0.2. The
exact number /should/ be the version that will next be released, but
it's not a big deal. Anyway, this is a minor point. x depends on liby (>=
0.1). If x is developed on, but doesn't use any additional features of
liby, its dep on liby should *not* be increased, so x version 0.2 would
be released depending on liby 0.1. If something gets added to liby which
x then uses, its dep should be increased to match the *future* version
of liby in the same commit. This is why the version number of the
modules in configure.ac or VERSION should be the current version plus
one.

Does that make any sense?

[Mark Ellis]

Post by Jonny Lamb

Post by Mark Ellis
What happened with trayicon ? I keep forgetting to test make dist...

% make dist
make: *** No rule to make target `intltool-merge.in', needed by distdir'. Stop.
Good luck debugging intltool. :-)

Oh no....

Post by Jonny Lamb

Post by Mark Ellis
gvfs I don't know what to do with yet.

Take your time. I can guess that both you and I aren't too fussed about
distribution inclusion, as GVFS isn't being included in Lenny.

Actually I switched to Ubuntu Hardy. Nothing to do with synce or gvfs,
it worked much better than Lenny with the 3G usb modem I just got. I
felt a bit guilty for a while :)

Post by Jonny Lamb

Post by Mark Ellis
Agreed. I've often made commits that depend on something else since the
last release, with no way to make that clear. Maybe we should only bump
the version in svn after something has been committed, otherwise we
imply changes that haven't happened. Too complicated ?

The last release of tool x is, for the sake of this example, 0.1. x
depends on liby, which had a 0.1 release recently. When working on these
modules, the version in configure.ac (or VERSION) should be 0.2. The
exact number /should/ be the version that will next be released, but
it's not a big deal. Anyway, this is a minor point. x depends on liby (>=
0.1). If x is developed on, but doesn't use any additional features of
liby, its dep on liby should *not* be increased, so x version 0.2 would
be released depending on liby 0.1. If something gets added to liby which
x then uses, its dep should be increased to match the *future* version
of liby in the same commit. This is why the version number of the
modules in configure.ac or VERSION should be the current version plus
one.
Does that make any sense?

Yeah, makes perfect sense, I was being convoluted.

Mark

[John Carr]

Post by Jonny Lamb

Post by Jonny Lamb

Post by Mark Ellis
What happened with trayicon ? I keep forgetting to test make dist...

% make dist
make: *** No rule to make target `intltool-merge.in', needed by

distdir'. Stop.

Post by Jonny Lamb
Good luck debugging intltool. :-)

Oh no....

This sounds like an intltool 0.4 thing. Jonnylamb, what version of intltool
are you running?

John

[Mark Ellis]

Post by Mark Ellis

Post by Jonny Lamb

Post by Mark Ellis
What happened with trayicon ? I keep forgetting to test

make dist...

Post by Jonny Lamb
% make dist
make: *** No rule to make target `intltool-merge.in', needed

by distdir'. Stop.

Post by Jonny Lamb
Good luck debugging intltool. :-)

Oh no....
This sounds like an intltool 0.4 thing. Jonnylamb, what version of
intltool are you running?

It's something odd. Jonny, it works fine for me, intltool 0.37.1. Do you
want to post your autogen.sh and configure output, might help ?

Mark

[Adam Williamson]

Post by Mark Ellis
It's something odd. Jonny, it works fine for me, intltool 0.37.1. Do you
want to post your autogen.sh and configure output, might help ?

Probably not related, but FWIW, I kept getting an odd problem with
gnome-autogen.sh on our buildsystem when building synce-trayicon . On my
own system it built fine. Testing on one of our build nodes it worked
fine. Even testing with iurt directly - our buildsystem app that creates
a clean chroot to build the package - it worked fine. But when I
actually submitted it to the official buildsystem process, the build
would always break with no error message as soon as it ran
gnome-autogen.sh .

I simply couldn't figure this out, so I just patched synce-trayicon's
autogen.sh to call autoreconf -i instead of gnome-autogen.sh . Bit of a
hack, but it at least worked. Anyway, though I'd mention it. No idea
what the problem is.

[John Carr]

Post by Mark Ellis

Post by Mark Ellis

Post by Jonny Lamb

Post by Mark Ellis
What happened with trayicon ? I keep forgetting to test

make dist...

Post by Jonny Lamb
% make dist
make: *** No rule to make target `intltool-merge.in', needed

by distdir'. Stop.

Post by Jonny Lamb
Good luck debugging intltool. :-)

Oh no....
This sounds like an intltool 0.4 thing. Jonnylamb, what version of
intltool are you running?

It's something odd. Jonny, it works fine for me, intltool 0.37.1. Do you
want to post your autogen.sh and configure output, might help ?
Mark

Smelling more and more like an intltool 0.4 thing...

John

[Jonny Lamb]

Post by John Carr
This sounds like an intltool 0.4 thing.

I assume you mean intltool 0.40, no?

Post by John Carr
Jonnylamb,

That "Jonny Lamb", but you may call me "Jonny".

Post by John Carr
what version of intltool are you running?

% apt-cache show intltool | awk '/Version:/ { print $2 }'
0.40.0-1

I'm not familiar with this tool at all and I have no time to invest in
working out what's wrong, so I'm all ears as to how to fix it.

Due to my lack of time for this issue, I will accept already made-up
tarballs from Mark Ellis (and Mark Ellis alone) if he wants to do this
-- throw the tarballs somewhere online, email me the md5sums and *sign*
the mail with a publicly available GPG key).

Of course, it would be nicer to actually fix this for others who are
running the same versions I am running.

Thanks,

[John Carr]

Post by Jonny Lamb

Post by John Carr
This sounds like an intltool 0.4 thing.

I assume you mean intltool 0.40, no?

That would be correct. Pesky 0's.

Post by Jonny Lamb

Post by John Carr
Jonnylamb,

That "Jonny Lamb", but you may call me "Jonny".

Sorry jonnylamb. Auto-cap-new-sentence got me. I didn't realise you were
picky about nick capitalization - noted for future. jc used to bother me,
but i've long since stopped caring. JC still grates a little, though.
Especially JC2k. Oh the humanity. How dare they.. etc.

Post by Jonny Lamb
what version of intltool are you running?

% apt-cache show intltool | awk '/Version:/ { print $2 }'

Post by Jonny Lamb
0.40.0-1
I'm not familiar with this tool at all and I have no time to invest in
working out what's wrong, so I'm all ears as to how to fix it.
Due to my lack of time for this issue, I will accept already made-up
tarballs from Mark Ellis (and Mark Ellis alone) if he wants to do this
-- throw the tarballs somewhere online, email me the md5sums and *sign*
the mail with a publicly available GPG key).
Of course, it would be nicer to actually fix this for others who are
running the same versions I am running.

My understanding of the issue: we can't fix this for Debian and other 0.40
users without breaking it for everyone else. So we should leave it as is
until intltool 0.40 is more widely deployed (like the next GNOME release or
something).

To fix it for 0.40, you just need to remove the intltool stuff from
EXTRA_DIST, but this will probably result in a tarball that only 0.40 people
can use...

John

[Mark Ellis]

Post by Jonny Lamb

Post by John Carr
This sounds like an intltool 0.4 thing.

I assume you mean intltool 0.40, no?

Post by John Carr
Jonnylamb,

That "Jonny Lamb", but you may call me "Jonny".

Post by John Carr
what version of intltool are you running?

% apt-cache show intltool | awk '/Version:/ { print $2 }'
0.40.0-1
I'm not familiar with this tool at all and I have no time to invest in
working out what's wrong, so I'm all ears as to how to fix it.
Due to my lack of time for this issue, I will accept already made-up
tarballs from Mark Ellis (and Mark Ellis alone) if he wants to do this
-- throw the tarballs somewhere online, email me the md5sums and *sign*
the mail with a publicly available GPG key).
Of course, it would be nicer to actually fix this for others who are
running the same versions I am running.

I can vaguely imagine what kind of backwards incompatible changes
they've made, it'll need some research.

Jonny, we'd better go with plan B, I'll sort something out for you
shortly.

How would you feel about the same solution for gvfs ? I can build a
tarball that includes the required files from the main gvfs source.

Mark

[Jonny Lamb]

Post by Mark Ellis
How would you feel about the same solution for gvfs ? I can build a
tarball that includes the required files from the main gvfs source.

For you, anything!

[Mark Ellis]

Post by Jonny Lamb

Post by Mark Ellis
How would you feel about the same solution for gvfs ? I can build a
tarball that includes the required files from the main gvfs source.

For you, anything!

Bless you :)

[H. S. Teoh]

Post by Jonny Lamb
Hi all,
SynCE 0.12 is out. There would be comic names for SynCE releases, but
we're just too solemn for that kind of thing.

Awesome!

Thanks for your work that helps keep my desktop Windows-free. ;-)

Post by Jonny Lamb
What's new
==========
There has been steady progress with this release. I will not summarize
here -- check out the SVN logs. The roadmap for this release and its
http://synce.org/moin/SynceRoadmap

[...]

Browsing through the wiki, I noticed that the SynCE ideas page lists HAL
integration... hasn't this already been implemented by synce-hal?


T