[Synce-devel] gentoo version bump

[Iain Buchanan]

Hi all,

[firstly, great to see the flurry of talk going back and forth - I'm
silently watching!]

I have finally found a gentoo dev who wants to commit both a
synce-0.10.0 ebuild and synce svn "snapshot". I see this as an
advantage for a number of reasons:
1. gentoo-ers can have official portage support for the latest
official synce release
2. gentoo-ers using the unstable tree can test out the latest svn
updates, to help you guys test your pre 0.11 release.

So this is what I would like to submit to gentoo shortly, with help of
course :)
1. 0.10.0 ebuilds (possibly the current laymen ones?)
2. 0.11-pre svn snapshot ebuilds (they don't have to have this name
if you would prefer)
3. Pick a date to make the snapshot. Any time around now is
probably fine!

If you're wondering what I mean by snapshot - where a development has
increased substantially from the last release (as synce has) the
snapshot ebuils allow users to get a common "release" from svn by
someone checking out and tarballing every month or so.

I would like to do this as right as possible, so I'm contacting you guys
first for comments. What do you think?

thanks,

[Dr J A Gow]

Post by Iain Buchanan
Hi all,
[firstly, great to see the flurry of talk going back and forth - I'm
silently watching!]
I have finally found a gentoo dev who wants to commit both a
synce-0.10.0 ebuild and synce svn "snapshot". I see this as an
1. gentoo-ers can have official portage support for the latest
official synce release
2. gentoo-ers using the unstable tree can test out the latest svn
updates, to help you guys test your pre 0.11 release.
So this is what I would like to submit to gentoo shortly, with help of
course :)
1. 0.10.0 ebuilds (possibly the current laymen ones?)
2. 0.11-pre svn snapshot ebuilds (they don't have to have this name
if you would prefer)
3. Pick a date to make the snapshot. Any time around now is
probably fine!
If you're wondering what I mean by snapshot - where a development has
increased substantially from the last release (as synce has) the
snapshot ebuils allow users to get a common "release" from svn by
someone checking out and tarballing every month or so.
I would like to do this as right as possible, so I'm contacting you guys
first for comments. What do you think?
thanks,

Great idea - can we hold off for a few days until I can fully test and
then commit the batch of new changes I have developed for sync-engine?
These changes are quite significant and represent a lot of improvements.

John.

[Iain Buchanan]

Post by Dr J A Gow
Great idea - can we hold off for a few days until I can fully test and
then commit the batch of new changes I have developed for sync-engine?
These changes are quite significant and represent a lot of improvements.

OK, I'll start by submitting the 0.10.0 ebuilds. Anyone know who wrote
the ones in layman currently?
http://synce.svn.sourceforge.net/svnroot/synce/dist/gentoo/synce-wm5-layman.xml

I'll ping you in a few days about the current state of svn (I'm
monitoring the svn commit logs anyway :)

thanks,

[Richard Alimi]

Post by Iain Buchanan

Post by Dr J A Gow
Great idea - can we hold off for a few days until I can fully test and
then commit the batch of new changes I have developed for sync-engine?
These changes are quite significant and represent a lot of improvements.

the ones in layman currently?
http://synce.svn.sourceforge.net/svnroot/synce/dist/gentoo/synce-wm5-layman
.xml
I'll ping you in a few days about the current state of svn (I'm
monitoring the svn commit logs anyway :)
thanks,

I had done the initial versions of the ebuilds. More work was done on these
by Dmitry Zamaruev. It would be good to see these make their way into the
official Gentoo ebuilds and be maintained there.

I have been following much of the recent development and I am quite impressed
with the activity! I'm truly sorry I don't have any time to devote to SynCE
for the next few months.

[Iain Buchanan]

Post by Richard Alimi

Post by Iain Buchanan

Post by Dr J A Gow
Great idea - can we hold off for a few days until I can fully test and
then commit the batch of new changes I have developed for sync-engine?
These changes are quite significant and represent a lot of improvements.

the ones in layman currently?
http://synce.svn.sourceforge.net/svnroot/synce/dist/gentoo/synce-wm5-layman
.xml
I'll ping you in a few days about the current state of svn (I'm
monitoring the svn commit logs anyway :)
thanks,

I had done the initial versions of the ebuilds. More work was done on these
by Dmitry Zamaruev. It would be good to see these make their way into the
official Gentoo ebuilds and be maintained there.
I have been following much of the recent development and I am quite impressed
with the activity!

me2

Post by Richard Alimi
I'm truly sorry I don't have any time to devote to SynCE
for the next few months.

no worries! You'll be back (I'm sure...) Hopefully by getting 0.10.0
into portage, we'll get some more help from all the gentoo 31337!!

OK, I'm about to attache them to gentoo's bugzilla. Is this list
complete/correct?

app-pda/synce/synce-0.10.0.ebuild
app-pda/synce-gnomevfs/synce-gnomevfs-0.10.0.ebuild
app-pda/synce-librapi2/synce-librapi2-0.10.0.ebuild
app-pda/synce-rra/synce-rra-0.10.0.ebuild
app-pda/synce-gnome/synce-gnome-0.10.0.ebuild
app-pda/synce-odccm/synce-odccm-0.10.0-r1.ebuild
app-pda/synce-libsynce/synce-libsynce-0.10.0.ebuild
app-pda/synce-vdccm/synce-vdccm-0.10.0.ebuild
app-pda/synce-serial/synce-serial-0.10.0.ebuild
app-pda/synce-sync-engine/synce-sync-engine-0.10.0.ebuild
sys-fs/usb-rndis-lite/usb-rndis-lite-0.10.0.ebuild
sys-fs/usb-rndis-ng/usb-rndis-ng-0.10.0.ebuild

thanks,

[Richard Alimi]

Post by Iain Buchanan
OK, I'm about to attache them to gentoo's bugzilla. Is this list
complete/correct?
app-pda/synce/synce-0.10.0.ebuild
app-pda/synce-gnomevfs/synce-gnomevfs-0.10.0.ebuild
app-pda/synce-librapi2/synce-librapi2-0.10.0.ebuild
app-pda/synce-rra/synce-rra-0.10.0.ebuild
app-pda/synce-gnome/synce-gnome-0.10.0.ebuild
app-pda/synce-odccm/synce-odccm-0.10.0-r1.ebuild
app-pda/synce-libsynce/synce-libsynce-0.10.0.ebuild
app-pda/synce-vdccm/synce-vdccm-0.10.0.ebuild
app-pda/synce-serial/synce-serial-0.10.0.ebuild
app-pda/synce-sync-engine/synce-sync-engine-0.10.0.ebuild
sys-fs/usb-rndis-lite/usb-rndis-lite-0.10.0.ebuild
sys-fs/usb-rndis-ng/usb-rndis-ng-0.10.0.ebuild
thanks,

You are missing some of the other dependencies, such as for sync-engine. For
each of those ebuilds, take a look at the dependencies and be sure that they
are all there. The other ones off the top of my head are synce-pywbxml and
librtfcomp, but there might be others.

--
Richard Alimi
Department of Computer Science
Yale University

[Iain Buchanan]

Hi,

Post by Richard Alimi
You are missing some of the other dependencies, such as for sync-engine. For
each of those ebuilds, take a look at the dependencies and be sure that they
are all there. The other ones off the top of my head are synce-pywbxml and
librtfcomp, but there might be others.

ok, I went through them all and added those two plus libwbxml. How does
this list look?

app-pda/synce/synce-0.10.0.ebuild
app-pda/synce-gnomevfs/synce-gnomevfs-0.10.0.ebuild
app-pda/synce-librapi2/synce-librapi2-0.10.0.ebuild
app-pda/synce-rra/synce-rra-0.10.0.ebuild
app-pda/synce-gnome/synce-gnome-0.10.0.ebuild
app-pda/synce-odccm/synce-odccm-0.10.0-r1.ebuild
app-pda/synce-libsynce/synce-libsynce-0.10.0.ebuild
app-pda/synce-vdccm/synce-vdccm-0.10.0.ebuild
app-pda/synce-serial/synce-serial-0.10.0.ebuild
app-pda/synce-sync-engine/synce-sync-engine-0.10.0.ebuild
sys-fs/usb-rndis-lite/usb-rndis-lite-0.10.0.ebuild
sys-fs/usb-rndis-ng/usb-rndis-ng-0.10.0.ebuild
app-pda/synce-librtfcomp/synce-librtfcomp-1.1.ebuild
app-pda/synce-pywbxml/synce-pywbxml-0.1.ebuild
dev-libs/libwbxml/libwbxml-0.9.2_p48.ebuild

thanks,

[Richard Alimi]

Post by Iain Buchanan
Hi,

Post by Richard Alimi
You are missing some of the other dependencies, such as for sync-engine.
For each of those ebuilds, take a look at the dependencies and be sure
that they are all there. The other ones off the top of my head are
synce-pywbxml and librtfcomp, but there might be others.

ok, I went through them all and added those two plus libwbxml. How does
this list look?
app-pda/synce/synce-0.10.0.ebuild
app-pda/synce-gnomevfs/synce-gnomevfs-0.10.0.ebuild
app-pda/synce-librapi2/synce-librapi2-0.10.0.ebuild
app-pda/synce-rra/synce-rra-0.10.0.ebuild
app-pda/synce-gnome/synce-gnome-0.10.0.ebuild
app-pda/synce-odccm/synce-odccm-0.10.0-r1.ebuild
app-pda/synce-libsynce/synce-libsynce-0.10.0.ebuild
app-pda/synce-vdccm/synce-vdccm-0.10.0.ebuild
app-pda/synce-serial/synce-serial-0.10.0.ebuild
app-pda/synce-sync-engine/synce-sync-engine-0.10.0.ebuild
sys-fs/usb-rndis-lite/usb-rndis-lite-0.10.0.ebuild
sys-fs/usb-rndis-ng/usb-rndis-ng-0.10.0.ebuild
app-pda/synce-librtfcomp/synce-librtfcomp-1.1.ebuild
app-pda/synce-pywbxml/synce-pywbxml-0.1.ebuild
dev-libs/libwbxml/libwbxml-0.9.2_p48.ebuild
thanks,

That list should be fine. The only other question that come to mind, is what
will they do with the libwbxml build? It seems to me like the most elegant
way to integrate it into the existing gentoo ebuilds would be to add our
patches via a USE flag that is disabled by default. Our ebuilds would have
to require libwbxml to have that USE flag enabled. I suspect they wouldn't
accept it without that modification.

--
Richard Alimi
Department of Computer Science
Yale University

[Mark Ellis]

Post by Iain Buchanan
Hi,

Post by Richard Alimi
You are missing some of the other dependencies, such as for sync-engine. For
each of those ebuilds, take a look at the dependencies and be sure that they
are all there. The other ones off the top of my head are synce-pywbxml and
librtfcomp, but there might be others.

ok, I went through them all and added those two plus libwbxml. How does
this list look?
app-pda/synce/synce-0.10.0.ebuild
app-pda/synce-gnomevfs/synce-gnomevfs-0.10.0.ebuild
app-pda/synce-librapi2/synce-librapi2-0.10.0.ebuild
app-pda/synce-rra/synce-rra-0.10.0.ebuild
app-pda/synce-gnome/synce-gnome-0.10.0.ebuild
app-pda/synce-odccm/synce-odccm-0.10.0-r1.ebuild
app-pda/synce-libsynce/synce-libsynce-0.10.0.ebuild
app-pda/synce-vdccm/synce-vdccm-0.10.0.ebuild
app-pda/synce-serial/synce-serial-0.10.0.ebuild
app-pda/synce-sync-engine/synce-sync-engine-0.10.0.ebuild
sys-fs/usb-rndis-lite/usb-rndis-lite-0.10.0.ebuild
sys-fs/usb-rndis-ng/usb-rndis-ng-0.10.0.ebuild
app-pda/synce-librtfcomp/synce-librtfcomp-1.1.ebuild
app-pda/synce-pywbxml/synce-pywbxml-0.1.ebuild
dev-libs/libwbxml/libwbxml-0.9.2_p48.ebuild
thanks,

Trayicon for gnomers ?

Mark

[Richard Alimi]

Post by Mark Ellis

Post by Iain Buchanan
...
app-pda/synce-librtfcomp/synce-librtfcomp-1.1.ebuild
app-pda/synce-pywbxml/synce-pywbxml-0.1.ebuild
dev-libs/libwbxml/libwbxml-0.9.2_p48.ebuild
thanks,

Trayicon for gnomers ?

The reason that wasn't included is because there was no official release of it
in 0.10.0. There is an SVN build for it that builds from /trunk, but I
believe it is Gentoo's policy that eny SVN trunk builds must be masked (i.e.,
not generally available unless you specifically go in and change a config
file to override it).

Of course, for the next release, there can be an ebuild.

--
Richard Alimi
Department of Computer Science
Yale University

[Iain Buchanan]

Post by Richard Alimi

Post by Mark Ellis

Post by Iain Buchanan
...
app-pda/synce-librtfcomp/synce-librtfcomp-1.1.ebuild
app-pda/synce-pywbxml/synce-pywbxml-0.1.ebuild
dev-libs/libwbxml/libwbxml-0.9.2_p48.ebuild
thanks,

Trayicon for gnomers ?

The reason that wasn't included is because there was no official release of it
in 0.10.0. There is an SVN build for it that builds from /trunk, but I
believe it is Gentoo's policy that eny SVN trunk builds must be masked (i.e.,
not generally available unless you specifically go in and change a config
file to override it).

kind of... you can specify various "masks" that you want to install from
on a system wide level, or on a package per package level. I personally
install from "unstable" on a system wide scale (which is more stable and
usable than the name suggests). Then there is "hard masked" for
not-working packages, and "stable" for the packages that make it through
unstable without issues for a while.

Anyway, svn or "snapshot ebuilds" as they're called can go into either
stable or unstable depending on how well they work, and how old the last
official release was.

I'm actually in the process of making some synce snapshots from svn, so
they can also go into gentoo, just waiting a few days for John to work
his magic!

Post by Richard Alimi
Of course, for the next release, there can be an ebuild.

cool. I'll make sure to put trayicon in the snapshot ebuilds till then.

cya,

[Richard Alimi]

Post by Iain Buchanan

Post by Richard Alimi
The reason that wasn't included is because there was no official release
of it in 0.10.0. There is an SVN build for it that builds from /trunk,
but I believe it is Gentoo's policy that eny SVN trunk builds must be
masked (i.e., not generally available unless you specifically go in and
change a config file to override it).

kind of... you can specify various "masks" that you want to install from
on a system wide level, or on a package per package level. I personally
install from "unstable" on a system wide scale (which is more stable and
usable than the name suggests). Then there is "hard masked" for
not-working packages, and "stable" for the packages that make it through
unstable without issues for a while.

Yes - this was exactly my point. People need to go into a config file to
specify this.

Post by Iain Buchanan
Anyway, svn or "snapshot ebuilds" as they're called can go into either
stable or unstable depending on how well they work, and how old the last
official release was.

Right. If the ebuild were to checkout from a particular revision, then I
think it would be fine. My comment was that using the ebuild as it stands
(which builds from the latest revision in trunk) would probably never be
available unmasked in Portage.

Post by Iain Buchanan
I'm actually in the process of making some synce snapshots from svn, so
they can also go into gentoo, just waiting a few days for John to work
his magic!

Cool. I'm wondering what the version number we should use for the snapshot
then. Since this is sort of a "pre-0.11.0" release, I guess the ebuild
should have the version number "0.10.0_pre<SVN_REVISION>". That seems to be
what they are doing for the mythtv SVN snapshots anyways. Any other ideas?

[Richard Alimi]

Post by Richard Alimi
Cool. I'm wondering what the version number we should use for the snapshot
then. Since this is sort of a "pre-0.11.0" release, I guess the ebuild
should have the version number "0.10.0_pre<SVN_REVISION>". That seems to
be what they are doing for the mythtv SVN snapshots anyways. Any other
ideas?

Sorry, that should have read "0.11.0_pre<SVN_REVISION>" ...

[Mark Ellis]

Post by Richard Alimi

Post by Richard Alimi
Cool. I'm wondering what the version number we should use for the snapshot
then. Since this is sort of a "pre-0.11.0" release, I guess the ebuild
should have the version number "0.10.0_pre<SVN_REVISION>". That seems to
be what they are doing for the mythtv SVN snapshots anyways. Any other
ideas?

Sorry, that should have read "0.11.0_pre<SVN_REVISION>" ...

For my debs I use 0.10.0.svn<checkout date YYYYMMDD>, makes them run
nicely in sequential order after the release.

Mark

[Iain Buchanan]

Post by Mark Ellis

Post by Richard Alimi

Post by Richard Alimi
Cool. I'm wondering what the version number we should use for the snapshot
then. Since this is sort of a "pre-0.11.0" release, I guess the ebuild
should have the version number "0.10.0_pre<SVN_REVISION>". That seems to
be what they are doing for the mythtv SVN snapshots anyways. Any other
ideas?

Sorry, that should have read "0.11.0_pre<SVN_REVISION>" ...

For my debs I use 0.10.0.svn<checkout date YYYYMMDD>, makes them run
nicely in sequential order after the release.

I would like to name it either synce-0.11_preYYYYMMDD.ebuild where
YYYYMMDD is the day the snapshot was taken (if the synce bigwigs like
the pre-release sound)

OR synce-0.10.0_pYYYYMMDD.ebuild (my personal favourite).

Note the 0.11_pre versus 0.10.0_p This is according to
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap3_sect5 so that portage can sort out which is newer and older.

I chose 0.11 and not 0.11.0 because of (David's?) comments earlier on
versions / roadmap / etc.

thanks!

[Richard Alimi]

Post by Iain Buchanan
I would like to name it either synce-0.11_preYYYYMMDD.ebuild where
YYYYMMDD is the day the snapshot was taken (if the synce bigwigs like
the pre-release sound)
OR synce-0.10.0_pYYYYMMDD.ebuild (my personal favourite).
Note the 0.11_pre versus 0.10.0_p This is according to
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#do
c_chap3_sect5 so that portage can sort out which is newer and older.
I chose 0.11 and not 0.11.0 because of (David's?) comments earlier on
versions / roadmap / etc.

Sounds reasonable. It sounds like you are more familiar on the "best
practices" than I am :) I guess mythtv isn't following the convention then.

--
Richard Alimi
Department of Computer Science
Yale University

[Iain Buchanan]

Post by Richard Alimi

Post by Iain Buchanan

Post by Richard Alimi
The reason that wasn't included is because there was no official release
of it in 0.10.0. There is an SVN build for it that builds from /trunk,
but I believe it is Gentoo's policy that eny SVN trunk builds must be
masked (i.e., not generally available unless you specifically go in and
change a config file to override it).

kind of... you can specify various "masks" that you want to install from
on a system wide level, or on a package per package level. I personally
install from "unstable" on a system wide scale (which is more stable and
usable than the name suggests). Then there is "hard masked" for
not-working packages, and "stable" for the packages that make it through
unstable without issues for a while.

Yes - this was exactly my point. People need to go into a config file to
specify this.

well, yes, but the Gentoo install is all editing config files and
command line stuff. In fact, said config file anyway is a major one...
Except for that new fandangled gui installer (progress I suppose!)

Post by Richard Alimi

Post by Iain Buchanan
Anyway, svn or "snapshot ebuilds" as they're called can go into either
stable or unstable depending on how well they work, and how old the last
official release was.

Right. If the ebuild were to checkout from a particular revision, then I
think it would be fine. My comment was that using the ebuild as it stands
(which builds from the latest revision in trunk) would probably never be
available unmasked in Portage.

ah yes, a live svn ebuild would never make it (I think there's one case
in the entire tree atm) because you can't say at any one time if its
working or not.

not arguing here, I'm just pedantic :)

[Mark Ellis]

Post by Richard Alimi

Post by Mark Ellis

Post by Iain Buchanan
...
app-pda/synce-librtfcomp/synce-librtfcomp-1.1.ebuild
app-pda/synce-pywbxml/synce-pywbxml-0.1.ebuild
dev-libs/libwbxml/libwbxml-0.9.2_p48.ebuild
thanks,

Trayicon for gnomers ?

The reason that wasn't included is because there was no official release of it
in 0.10.0. There is an SVN build for it that builds from /trunk, but I
believe it is Gentoo's policy that eny SVN trunk builds must be masked (i.e.,
not generally available unless you specifically go in and change a config
file to override it).
Of course, for the next release, there can be an ebuild.

Which makes perfect sense, thanks Richard.