vectorlinux-devel

[Vectorlinux-devel] Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

Sorry if this has already been decided upon but I haven't been made aware o=
f
it so here goes.

I have been looking at these as I'm sure some or all of you have as well.

I think we can work with these to build our base from source and then expan=
d
on them in the future.

There were a few of us on irc last night chatting about it.

This is how I think we should move forward with this:

1 - as a group, decide on all the packages for both std vl and soho before
we start
2 - 1 person designated to build the bare minimum base(a/ap/d/l/k source
trees) - probably either myself or Uel or anyone that wants to take
ownership of this task - all base build scripts need to be corrected for
arch,flags,etc
3 - once the base is built, each developer is given a source tree or trees
and they work on those on top of the base(vlbase.tgz).eg. kde,xap,etc - all
packages must be built on a virgin base except for soho - 2 groups are
needed here - std and soho and there will be some duplication as std and
soho should be treated as separate distros - all build scripts need to
corrected for arch,flags,etc
4 - we need to come up with SlackBuilds for the packages we include that
aren't in slack and split this up depending on how many pkgs there are
5 - upload all the built packages to the respective trees and each of us
install them for testing.
6 - once testing is completed, we package these up for the cd into
vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages should
reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE only and have
all packages built for it using kde as a dep.
7 - release beta std and soho at the same time
8 - set a beta test schedule of 2 weeks
9 - fix and release rc
10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until stable.
11 - release final std and soho at the same time.
12 - designate a dev for each versions - std and soho - whose primary
responsibility will be security patching
13 - start working on extra packages for the repo
14 - once there is a large repo of apps available, start the next cycle at
step 1

Let me know what you all think.  Having this process more organized and
coordinated will allow us to work quicker and more efficiently giving us
more time to create the extra app repo that is needed to take VL to the nex=
t
level. That way when Robert becomes rich from VL, he will share with all of
us - lol.

Regards,
Tony

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[uel a. <ue...@gm...>]

Sounds good. I have some additions to a few of your propositions. here thay
are

1. we have some package list we may be able to use to help in this they are
in ftp in the VL6base folder.
2. I nominate you to build the base and get it setup for us. :)
3. sounds good, but do we have enough people to seperate into 2 groups?
4. agree
5. agree
6. I along with others would like to see this borken down further. base-cli=
,
dev, X, std, soho, some examples would be the package lists in VL6base on
ftp.
7. I think there should be a seperation in release dates. 1 reason is
Distrowatch another is easier for us to debug.
8.agree
9.agree
10.agree
11. see #7
12. I really like this idea
13. agree
14. agree

some really good ideas here Tony.
Thanks,
Uel

On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
>
> Sorry if this has already been decided upon but I haven't been made aware
> of it so here goes.
>
> I have been looking at these as I'm sure some or all of you have as well.
>
> I think we can work with these to build our base from source and then
> expand on them in the future.
>
> There were a few of us on irc last night chatting about it.
>
> This is how I think we should move forward with this:
>
> 1 - as a group, decide on all the packages for both std vl and soho befor=
e
> we start
> 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k source
> trees) - probably either myself or Uel or anyone that wants to take
> ownership of this task - all base build scripts need to be corrected for
> arch,flags,etc
> 3 - once the base is built, each developer is given a source tree or tree=
s
> and they work on those on top of the base(vlbase.tgz).eg. kde,xap,etc -
> all packages must be built on a virgin base except for soho - 2 groups ar=
e
> needed here - std and soho and there will be some duplication as std and
> soho should be treated as separate distros - all build scripts need to
> corrected for arch,flags,etc
> 4 - we need to come up with SlackBuilds for the packages we include that
> aren't in slack and split this up depending on how many pkgs there are
> 5 - upload all the built packages to the respective trees and each of us
> install them for testing.
> 6 - once testing is completed, we package these up for the cd into
> vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages
> should reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE only
> and have all packages built for it using kde as a dep.
> 7 - release beta std and soho at the same time
> 8 - set a beta test schedule of 2 weeks
> 9 - fix and release rc
> 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until stable.
> 11 - release final std and soho at the same time.
> 12 - designate a dev for each versions - std and soho - whose primary
> responsibility will be security patching
> 13 - start working on extra packages for the repo
> 14 - once there is a large repo of apps available, start the next cycle a=
t
> step 1
>
> Let me know what you all think.  Having this process more organized and
> coordinated will allow us to work quicker and more efficiently giving us
> more time to create the extra app repo that is needed to take VL to the n=
ext
> level. That way when Robert becomes rich from VL, he will share with all =
of
> us - lol.
>
> Regards,
> Tony
>
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Jose J. R. <jo...@gm...>]

I agree with most of what Tony proposes, but with uel's "fixes", lol.

I might be jumping ahead here, but I do think we should start planning
so the repo for VL6 has a better organization from the start, as
discussed previously, something like official, unofficial, extras,
unstable, etc, or any other naming convention. The thing is to
separate the maintenance packages (allowing for a possible
distro-update) from the extra apps and those which are development
releases of apps.

I must also restate my hope that beyond the base-cli bulk, the rest
can be handled as packages with metapackages to define the "bulks".
This would allow an "easy" install by selecting metapackages or an
"advanced" install where most apps are listed for selection (probably
not necessary to list libs) and the deps are handled automatically for
those selected. For this, slapt-get might be a good choice to consider
if it can be called from the installer in the initrd.

Regards,
Joe1962


On 4/6/06, uel archuletta <ue...@gm...> wrote:
> Sounds good. I have some additions to a few of your propositions. here th=
ay
> are
>
> 1. we have some package list we may be able to use to help in this they a=
re
> in ftp in the VL6base folder.
> 2. I nominate you to build the base and get it setup for us. :)
> 3. sounds good, but do we have enough people to seperate into 2 groups?
> 4. agree
> 5. agree
> 6. I along with others would like to see this borken down further. base-c=
li,
> dev, X, std, soho, some examples would be the package lists in VL6base on
> ftp.
> 7. I think there should be a seperation in release dates. 1 reason is
> Distrowatch another is easier for us to debug.
> 8.agree
> 9.agree
> 10.agree
> 11. see #7
> 12. I really like this idea
> 13. agree
> 14. agree
>
> some really good ideas here Tony.
> Thanks,
> Uel
>
>
> On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >
> > Sorry if this has already been decided upon but I haven't been made awa=
re
> of it so here goes.
> >
> > I have been looking at these as I'm sure some or all of you have as wel=
l.
> >
> > I think we can work with these to build our base from source and then
> expand on them in the future.
> >
> > There were a few of us on irc last night chatting about it.
> >
> > This is how I think we should move forward with this:
> >
> > 1 - as a group, decide on all the packages for both std vl and soho bef=
ore
> we start
> > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k sourc=
e
> trees) - probably either myself or Uel or anyone that wants to take
> ownership of this task - all base build scripts need to be corrected for
> arch,flags,etc
> > 3 - once the base is built, each developer is given a source tree or tr=
ees
> and they work on those on top of the base(vlbase.tgz).eg. kde,xap,etc - a=
ll
> packages must be built on a virgin base except for soho - 2 groups are
> needed here - std and soho and there will be some duplication as std and
> soho should be treated as separate distros - all build scripts need to
> corrected for arch,flags,etc
> > 4 - we need to come up with SlackBuilds for the packages we include tha=
t
> aren't in slack and split this up depending on how many pkgs there are
> > 5 - upload all the built packages to the respective trees and each of u=
s
> install them for testing.
> > 6 - once testing is completed, we package these up for the cd into
> vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages shou=
ld
> reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE only and hav=
e
> all packages built for it using kde as a dep.
> > 7 - release beta std and soho at the same time
> > 8 - set a beta test schedule of 2 weeks
> > 9 - fix and release rc
> > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until stabl=
e.
> > 11 - release final std and soho at the same time.
> > 12 - designate a dev for each versions - std and soho - whose primary
> responsibility will be security patching
> > 13 - start working on extra packages for the repo
> > 14 - once there is a large repo of apps available, start the next cycle=
 at
> step 1
> >
> > Let me know what you all think.  Having this process more organized and
> coordinated will allow us to work quicker and more efficiently giving us
> more time to create the extra app repo that is needed to take VL to the n=
ext
> level. That way when Robert becomes rich from VL, he will share with all =
of
> us - lol.
> >
> > Regards,
> >
> > Tony
> >
>
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

Agreed. We need a much better repo organization that follows the version
number. Having vl 5.1 and soho 5.1.1 using the 5.0 repo is confusing and
just bad altogether - lol.



On 4/6/06, Jose J. Rodriguez <jo...@gm...> wrote:
>
> I agree with most of what Tony proposes, but with uel's "fixes", lol.
>
> I might be jumping ahead here, but I do think we should start planning
> so the repo for VL6 has a better organization from the start, as
> discussed previously, something like official, unofficial, extras,
> unstable, etc, or any other naming convention. The thing is to
> separate the maintenance packages (allowing for a possible
> distro-update) from the extra apps and those which are development
> releases of apps.
>
> I must also restate my hope that beyond the base-cli bulk, the rest
> can be handled as packages with metapackages to define the "bulks".
> This would allow an "easy" install by selecting metapackages or an
> "advanced" install where most apps are listed for selection (probably
> not necessary to list libs) and the deps are handled automatically for
> those selected. For this, slapt-get might be a good choice to consider
> if it can be called from the installer in the initrd.
>
> Regards,
> Joe1962
>
>
> On 4/6/06, uel archuletta <ue...@gm...> wrote:
> > Sounds good. I have some additions to a few of your propositions. here
> thay
> > are
> >
> > 1. we have some package list we may be able to use to help in this they
> are
> > in ftp in the VL6base folder.
> > 2. I nominate you to build the base and get it setup for us. :)
> > 3. sounds good, but do we have enough people to seperate into 2 groups?
> > 4. agree
> > 5. agree
> > 6. I along with others would like to see this borken down further.
> base-cli,
> > dev, X, std, soho, some examples would be the package lists in VL6base
> on
> > ftp.
> > 7. I think there should be a seperation in release dates. 1 reason is
> > Distrowatch another is easier for us to debug.
> > 8.agree
> > 9.agree
> > 10.agree
> > 11. see #7
> > 12. I really like this idea
> > 13. agree
> > 14. agree
> >
> > some really good ideas here Tony.
> > Thanks,
> > Uel
> >
> >
> > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > >
> > >
> > > Sorry if this has already been decided upon but I haven't been made
> aware
> > of it so here goes.
> > >
> > > I have been looking at these as I'm sure some or all of you have as
> well.
> > >
> > > I think we can work with these to build our base from source and then
> > expand on them in the future.
> > >
> > > There were a few of us on irc last night chatting about it.
> > >
> > > This is how I think we should move forward with this:
> > >
> > > 1 - as a group, decide on all the packages for both std vl and soho
> before
> > we start
> > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k
> source
> > trees) - probably either myself or Uel or anyone that wants to take
> > ownership of this task - all base build scripts need to be corrected fo=
r
> > arch,flags,etc
> > > 3 - once the base is built, each developer is given a source tree or
> trees
> > and they work on those on top of the base(vlbase.tgz).eg. kde,xap,etc -
> all
> > packages must be built on a virgin base except for soho - 2 groups are
> > needed here - std and soho and there will be some duplication as std an=
d
> > soho should be treated as separate distros - all build scripts need to
> > corrected for arch,flags,etc
> > > 4 - we need to come up with SlackBuilds for the packages we include
> that
> > aren't in slack and split this up depending on how many pkgs there are
> > > 5 - upload all the built packages to the respective trees and each of
> us
> > install them for testing.
> > > 6 - once testing is completed, we package these up for the cd into
> > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages
> should
> > reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE only and
> have
> > all packages built for it using kde as a dep.
> > > 7 - release beta std and soho at the same time
> > > 8 - set a beta test schedule of 2 weeks
> > > 9 - fix and release rc
> > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until
> stable.
> > > 11 - release final std and soho at the same time.
> > > 12 - designate a dev for each versions - std and soho - whose primary
> > responsibility will be security patching
> > > 13 - start working on extra packages for the repo
> > > 14 - once there is a large repo of apps available, start the next
> cycle at
> > step 1
> > >
> > > Let me know what you all think.  Having this process more organized
> and
> > coordinated will allow us to work quicker and more efficiently giving u=
s
> > more time to create the extra app repo that is needed to take VL to the
> next
> > level. That way when Robert becomes rich from VL, he will share with al=
l
> of
> > us - lol.
> > >
> > > Regards,
> > >
> > > Tony
> > >
> >
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

On 4/6/06, uel archuletta <ue...@gm...> wrote:
>
> Sounds good. I have some additions to a few of your propositions. here
> thay are
>
> 1. we have some package list we may be able to use to help in this they
> are in ftp in the VL6base folder.
> 2. I nominate you to build the base and get it setup for us. :)
>

OK


 3. sounds good, but do we have enough people to seperate into 2 groups?
>

If not 2 groups, then each dev can have 2 partitions for dev - std and soho=
.
This shouldn't be too bad a task if we have all the pkgs decided upon at th=
e
beginning and hand out the workload equally. Remember, in the past Robert
did std by himself and I did soho by myself on top of std so it is possible=
.


 4. agree
> 5. agree
> 6. I along with others would like to see this borken down further.
> base-cli, dev, X, std, soho, some examples would be the package lists in
> VL6base on ftp.
>


base-cli and dev will have to be 1 since we can't work on a base without de=
v
tools.

X - if by this you mean xorg alone then I agree but if this includes
WM's,etc then no.


 7. I think there should be a seperation in release dates. 1 reason is
> Distrowatch another is easier for us to debug.
> 8.agree
> 9.agree
> 10.agree
> 11. see #7
> 12. I really like this idea
> 13. agree
> 14. agree
>
> some really good ideas here Tony.
> Thanks,
>
> Uel
>
>
> On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >  Sorry if this has already been decided upon but I haven't been made
> > aware of it so here goes.
> >
> > I have been looking at these as I'm sure some or all of you have as
> > well.
> >
> > I think we can work with these to build our base from source and then
> > expand on them in the future.
> >
> > There were a few of us on irc last night chatting about it.
> >
> > This is how I think we should move forward with this:
> >
> > 1 - as a group, decide on all the packages for both std vl and soho
> > before we start
> > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k sourc=
e
> > trees) - probably either myself or Uel or anyone that wants to take
> > ownership of this task - all base build scripts need to be corrected fo=
r
> > arch,flags,etc
> > 3 - once the base is built, each developer is given a source tree or
> > trees and they work on those on top of the base(vlbase.tgz).eg.
> > kde,xap,etc - all packages must be built on a virgin base except for so=
ho -
> > 2 groups are needed here - std and soho and there will be some duplicat=
ion
> > as std and soho should be treated as separate distros - all build scrip=
ts
> > need to corrected for arch,flags,etc
> > 4 - we need to come up with SlackBuilds for the packages we include tha=
t
> > aren't in slack and split this up depending on how many pkgs there are
> > 5 - upload all the built packages to the respective trees and each of u=
s
> > install them for testing.
> > 6 - once testing is completed, we package these up for the cd into
> > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages
> > should reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE onl=
y
> > and have all packages built for it using kde as a dep.
> > 7 - release beta std and soho at the same time
> > 8 - set a beta test schedule of 2 weeks
> > 9 - fix and release rc
> > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until
> > stable.
> > 11 - release final std and soho at the same time.
> > 12 - designate a dev for each versions - std and soho - whose primary
> > responsibility will be security patching
> > 13 - start working on extra packages for the repo
> > 14 - once there is a large repo of apps available, start the next cycle
> > at step 1
> >
> > Let me know what you all think.  Having this process more organized and
> > coordinated will allow us to work quicker and more efficiently giving u=
s
> > more time to create the extra app repo that is needed to take VL to the=
 next
> > level. That way when Robert becomes rich from VL, he will share with al=
l of
> > us - lol.
> >
> > Regards,
> >  Tony
> >
> >
>
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[uel a. <ue...@gm...>]

On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
>
>
>
> On 4/6/06, uel archuletta <ue...@gm...> wrote:
>
> > Sounds good. I have some additions to a few of your propositions. here
> > thay are
> >
> > 1. we have some package list we may be able to use to help in this they
> > are in ftp in the VL6base folder.
> > 2. I nominate you to build the base and get it setup for us. :)
> >
>
> OK
>
>
>  3. sounds good, but do we have enough people to seperate into 2 groups?
> >
>
> If not 2 groups, then each dev can have 2 partitions for dev - std and
> soho. This shouldn't be too bad a task if we have all the pkgs decided up=
on
> at the beginning and hand out the workload equally. Remember, in the past
> Robert did std by himself and I did soho by myself on top of std so it is
> possible.
>

That is workable 2 seperate workloads if one has time/space they could work
on both.



4. agree
> > 5. agree
> > 6. I along with others would like to see this borken down further.
> > base-cli, dev, X, std, soho, some examples would be the package lists i=
n
> > VL6base on ftp.
> >
>
>
> base-cli and dev will have to be 1 since we can't work on a base without
> dev tools.
>

this is where I get things mixed up so correct me if I am wrong. if we are
building packages and populating a repo then we can build a base for the
devs to build packages on that has all tools and X, and then build a base
for the installer that has them seperated out. as long as we test the
packages on this base as well.




X - if by this you mean xorg alone then I agree but if this includes
> WM's,etc then no.
>

Vec asked if we couldnt include xfce in our xorg package since it is in
both, and if we go down to the package level it woould simply mean adding i=
t
to the metapackage


7. I think there should be a seperation in release dates. 1 reason is
> > Distrowatch another is easier for us to debug.
> > 8.agree
> > 9.agree
> > 10.agree
> > 11. see #7
> > 12. I really like this idea
> > 13. agree
> > 14. agree
> >
> > some really good ideas here Tony.
> > Thanks,
> >
> > Uel
> >
> >
> > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > >
> > >  Sorry if this has already been decided upon but I haven't been made
> > > aware of it so here goes.
> > >
> > > I have been looking at these as I'm sure some or all of you have as
> > > well.
> > >
> > > I think we can work with these to build our base from source and then
> > > expand on them in the future.
> > >
> > > There were a few of us on irc last night chatting about it.
> > >
> > > This is how I think we should move forward with this:
> > >
> > > 1 - as a group, decide on all the packages for both std vl and soho
> > > before we start
> > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k
> > > source trees) - probably either myself or Uel or anyone that wants to=
 take
> > > ownership of this task - all base build scripts need to be corrected =
for
> > > arch,flags,etc
> > > 3 - once the base is built, each developer is given a source tree or
> > > trees and they work on those on top of the base(vlbase.tgz).eg.
> > > kde,xap,etc - all packages must be built on a virgin base except for =
soho -
> > > 2 groups are needed here - std and soho and there will be some duplic=
ation
> > > as std and soho should be treated as separate distros - all build scr=
ipts
> > > need to corrected for arch,flags,etc
> > > 4 - we need to come up with SlackBuilds for the packages we include
> > > that aren't in slack and split this up depending on how many pkgs the=
re are
> > > 5 - upload all the built packages to the respective trees and each of
> > > us install them for testing.
> > > 6 - once testing is completed, we package these up for the cd into
> > > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages
> > > should reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE
> > > only and have all packages built for it using kde as a dep.
> > > 7 - release beta std and soho at the same time
> > > 8 - set a beta test schedule of 2 weeks
> > > 9 - fix and release rc
> > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until
> > > stable.
> > > 11 - release final std and soho at the same time.
> > > 12 - designate a dev for each versions - std and soho - whose primary
> > > responsibility will be security patching
> > > 13 - start working on extra packages for the repo
> > > 14 - once there is a large repo of apps available, start the next
> > > cycle at step 1
> > >
> > > Let me know what you all think.  Having this process more organized
> > > and coordinated will allow us to work quicker and more efficiently gi=
ving us
> > > more time to create the extra app repo that is needed to take VL to t=
he next
> > > level. That way when Robert becomes rich from VL, he will share with =
all of
> > > us - lol.
> > >
> > > Regards,
> > >  Tony
> > >
> > >
> >
> >
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

On 4/6/06, uel archuletta <ue...@gm...> wrote:

>
>
>  On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >
> >
> >  On 4/6/06, uel archuletta < ue...@gm...> wrote:
> >
> > > Sounds good. I have some additions to a few of your propositions. her=
e
> > > thay are
> > >
> > > 1. we have some package list we may be able to use to help in this
> > > they are in ftp in the VL6base folder.
> > > 2. I nominate you to build the base and get it setup for us. :)
> > >
> >
> >  OK
> >
> >
> >  3. sounds good, but do we have enough people to seperate into 2 groups=
?
> > >
> >
> >  If not 2 groups, then each dev can have 2 partitions for dev - std and
> > soho. This shouldn't be too bad a task if we have all the pkgs decided =
upon
> > at the beginning and hand out the workload equally. Remember, in the pa=
st
> > Robert did std by himself and I did soho by myself on top of std so it =
is
> > possible.
> >
>
> That is workable 2 seperate workloads if one has time/space they could
> work on both.
>
>
>
>   4. agree
> > > 5. agree
> > > 6. I along with others would like to see this borken down further.
> > > base-cli, dev, X, std, soho, some examples would be the package lists=
 in
> > > VL6base on ftp.
> > >
> >
> >
> >  base-cli and dev will have to be 1 since we can't work on a base
> > without dev tools.
> >
>
> this is where I get things mixed up so correct me if I am wrong. if we ar=
e
> building packages and populating a repo then we can build a base for the
> devs to build packages on that has all tools and X, and then build a base
> for the installer that has them seperated out. as long as we test the
> packages on this base as well.
>


I think this would create more work.  Apps built for SOHO would have
kde-centric additions wherever possible to integrate them better into the
desktop environment. While we may use the same apps for std, they should no=
t
have kde deps in them.  This is kind of like the issue you get if you try t=
o
install packages from linuxpackages.net - arts has a dep of gnome - wtf?
Whay would you build arts with a gnome dep. Same goes for apps for std that
might have a kde dep - not a good thing at all.

The base would be common to all, including X and dev.  std(WM's and
apps) and soho(KDE and apps) would then be built on top of the base.  Soho
would have KDE as its first build so that any other app installs after that
would be able to use kde hooks where needed.



>
>
>   X - if by this you mean xorg alone then I agree but if this includes
> > WM's,etc then no.
> >
>
> Vec asked if we couldnt include xfce in our xorg package since it is in
> both, and if we go down to the package level it woould simply mean adding=
 it
> to the metapackage
>
>


I really don't think xfce should be in SOHO.  IMHO, 99% of those that get
SOHO are getting it for kde and not xfce.  If they want xfce, they should
stick with std.  This would also allow us to make soho easier and better du=
e
to the fact that you wouldn't have to worry about menus and such as long as
a kde .desktop file was included with the packages.
Folks that are looking for xfce aren't looking for the bloat of kde and
those looking for the richness and integration of kde aren't looking for
xfce.  Again, we need to go back and look at the target market for these an=
d
not what we want out of it.  We could always add wm's and such to the repo
but I doubt they'd get a lot of hits.

Concentrating only on kde for soho would be the best bet.  choosing apps fo=
r
soho should also be centred around kde as well so they integrate properly
into the DE.  The maturity of the apps for kde is there now and we should
take advantage of that.

The only folks I know that run SOHO with xfce are vec and monty - lol. No
offense guys.

We need to focus on packages as that is what is really important. That is
why stuff like ubuntu, gentoo,etc have gained the popularity they have.
Folks don't have to go searching a million different places to get what the=
y
need. It is all available from a central source for the most part.

Linuxpackages and slacky.it are ok but they still have some goofyness to
them with deps of stuff that isn't needed.



>    7. I think there should be a seperation in release dates. 1 reason is
> > > Distrowatch another is easier for us to debug.
> > > 8.agree
> > > 9.agree
> > > 10.agree
> > > 11. see #7
> > > 12. I really like this idea
> > > 13. agree
> > > 14. agree
> > >
> > > some really good ideas here Tony.
> > > Thanks,
> > >
> > > Uel
> > >
> > >
> > > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > > >
> > > >  Sorry if this has already been decided upon but I haven't been mad=
e
> > > > aware of it so here goes.
> > > >
> > > > I have been looking at these as I'm sure some or all of you have as
> > > > well.
> > > >
> > > > I think we can work with these to build our base from source and
> > > > then expand on them in the future.
> > > >
> > > > There were a few of us on irc last night chatting about it.
> > > >
> > > > This is how I think we should move forward with this:
> > > >
> > > > 1 - as a group, decide on all the packages for both std vl and soho
> > > > before we start
> > > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k
> > > > source trees) - probably either myself or Uel or anyone that wants =
to take
> > > > ownership of this task - all base build scripts need to be correcte=
d for
> > > > arch,flags,etc
> > > > 3 - once the base is built, each developer is given a source tree o=
r
> > > > trees and they work on those on top of the base(vlbase.tgz).eg.
> > > > kde,xap,etc - all packages must be built on a virgin base except fo=
r soho -
> > > > 2 groups are needed here - std and soho and there will be some dupl=
ication
> > > > as std and soho should be treated as separate distros - all build s=
cripts
> > > > need to corrected for arch,flags,etc
> > > > 4 - we need to come up with SlackBuilds for the packages we include
> > > > that aren't in slack and split this up depending on how many pkgs t=
here are
> > > > 5 - upload all the built packages to the respective trees and each
> > > > of us install them for testing.
> > > > 6 - once testing is completed, we package these up for the cd into
> > > > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related package=
s
> > > > should reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE
> > > > only and have all packages built for it using kde as a dep.
> > > > 7 - release beta std and soho at the same time
> > > > 8 - set a beta test schedule of 2 weeks
> > > > 9 - fix and release rc
> > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until
> > > > stable.
> > > > 11 - release final std and soho at the same time.
> > > > 12 - designate a dev for each versions - std and soho - whose
> > > > primary responsibility will be security patching
> > > > 13 - start working on extra packages for the repo
> > > > 14 - once there is a large repo of apps available, start the next
> > > > cycle at step 1
> > > >
> > > > Let me know what you all think.  Having this process more organized
> > > > and coordinated will allow us to work quicker and more efficiently =
giving us
> > > > more time to create the extra app repo that is needed to take VL to=
 the next
> > > > level. That way when Robert becomes rich from VL, he will share wit=
h all of
> > > > us - lol.
> > > >
> > > > Regards,
> > > >  Tony
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Sriram D. <sri...@gm...>]

hi, am sorry i could not be part of the irc conversation. But may i suggest
that we should consider the live versions also from the start?
the key would be to start with a really simple base.
here is the layout i have in mind[ very awkward.. but might work.. changes
invited :) ]

1. Dev base
2. Non Dev base [ for the minimal live CD ]
3. Std [ 1 +  no kde - soho apps ]
4. SOHO [ 1 +  kde + soho apps ]
5. Std Live [ 2 + * ]
6. SOHO Live [ 2 +  kde + soho apps ]

i agree that our primary objective for SoHo should be kde only. if there is
a lot of demand for other WMs, that should be an additional package.
what we release should be usable .. for example puppy linux uses VL as thei=
r
host development system.   But their install is simple and clean.  We can d=
o
a similar thing.

commonly pooping up themes :
1. upgrade path from std to soho
2. --dist_upgrade

If we ignore one 1. have two clearly demarcated repos for std and soho . 2.
is possible

And it makes development and package management a lot easier if we consider
them two seperate Distros altogether.. they share only the vector
philosophy.. and the non KDE part of the initial base system.  All packages
that can take advantage of having KDE as a dep should  have it .

Life will be much much easier for ever one involved, devs, pkgers and users
:)
cheers
ram





On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
>
>
>
> On 4/6/06, uel archuletta <ue...@gm...> wrote:
>
> >
> >
> >  On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> > >
> > >
> > >
> > >  On 4/6/06, uel archuletta < ue...@gm...> wrote:
> > >
> > > > Sounds good. I have some additions to a few of your propositions.
> > > > here thay are
> > > >
> > > > 1. we have some package list we may be able to use to help in this
> > > > they are in ftp in the VL6base folder.
> > > > 2. I nominate you to build the base and get it setup for us. :)
> > > >
> > >
> > >  OK
> > >
> > >
> > >  3. sounds good, but do we have enough people to seperate into 2
> > > > groups?
> > > >
> > >
> > >  If not 2 groups, then each dev can have 2 partitions for dev - std
> > > and soho. This shouldn't be too bad a task if we have all the pkgs de=
cided
> > > upon at the beginning and hand out the workload equally. Remember, in=
 the
> > > past Robert did std by himself and I did soho by myself on top of std=
 so it
> > > is possible.
> > >
> >
> > That is workable 2 seperate workloads if one has time/space they could
> > work on both.
> >
> >
> >
> >   4. agree
> > > > 5. agree
> > > > 6. I along with others would like to see this borken down further.
> > > > base-cli, dev, X, std, soho, some examples would be the package lis=
ts in
> > > > VL6base on ftp.
> > > >
> > >
> > >
> > >  base-cli and dev will have to be 1 since we can't work on a base
> > > without dev tools.
> > >
> >
> > this is where I get things mixed up so correct me if I am wrong. if we
> > are building packages and populating a repo then we can build a base fo=
r the
> > devs to build packages on that has all tools and X, and then build a ba=
se
> > for the installer that has them seperated out. as long as we test the
> > packages on this base as well.
> >
>
>
> I think this would create more work.  Apps built for SOHO would have
> kde-centric additions wherever possible to integrate them better into the
> desktop environment. While we may use the same apps for std, they should =
not
> have kde deps in them.  This is kind of like the issue you get if you try=
 to
> install packages from linuxpackages.net - arts has a dep of gnome - wtf?
> Whay would you build arts with a gnome dep. Same goes for apps for std th=
at
> might have a kde dep - not a good thing at all.
>
> The base would be common to all, including X and dev.  std(WM's and
> apps) and soho(KDE and apps) would then be built on top of the base.  Soh=
o
> would have KDE as its first build so that any other app installs after th=
at
> would be able to use kde hooks where needed.
>
>
>
> >
> >
> >   X - if by this you mean xorg alone then I agree but if this includes
> > > WM's,etc then no.
> > >
> >
> > Vec asked if we couldnt include xfce in our xorg package since it is in
> > both, and if we go down to the package level it woould simply mean addi=
ng it
> > to the metapackage
> >
> >
>
>
> I really don't think xfce should be in SOHO.  IMHO, 99% of those that get
> SOHO are getting it for kde and not xfce.  If they want xfce, they should
> stick with std.  This would also allow us to make soho easier and better =
due
> to the fact that you wouldn't have to worry about menus and such as long =
as
> a kde .desktop file was included with the packages.
> Folks that are looking for xfce aren't looking for the bloat of kde and
> those looking for the richness and integration of kde aren't looking for
> xfce.  Again, we need to go back and look at the target market for these =
and
> not what we want out of it.  We could always add wm's and such to the rep=
o
> but I doubt they'd get a lot of hits.
>
> Concentrating only on kde for soho would be the best bet.  choosing apps
> for soho should also be centred around kde as well so they integrate
> properly into the DE.  The maturity of the apps for kde is there now and =
we
> should take advantage of that.
>
> The only folks I know that run SOHO with xfce are vec and monty - lol. No
> offense guys.
>
> We need to focus on packages as that is what is really important. That is
> why stuff like ubuntu, gentoo,etc have gained the popularity they have.
> Folks don't have to go searching a million different places to get what t=
hey
> need. It is all available from a central source for the most part.
>
> Linuxpackages and slacky.it are ok but they still have some goofyness to
> them with deps of stuff that isn't needed.
>
>
>
> >    7. I think there should be a seperation in release dates. 1 reason i=
s
> > > > Distrowatch another is easier for us to debug.
> > > > 8.agree
> > > > 9.agree
> > > > 10.agree
> > > > 11. see #7
> > > > 12. I really like this idea
> > > > 13. agree
> > > > 14. agree
> > > >
> > > > some really good ideas here Tony.
> > > > Thanks,
> > > >
> > > > Uel
> > > >
> > > >
> > > > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > > > >
> > > > >  Sorry if this has already been decided upon but I haven't been
> > > > > made aware of it so here goes.
> > > > >
> > > > > I have been looking at these as I'm sure some or all of you have
> > > > > as well.
> > > > >
> > > > > I think we can work with these to build our base from source and
> > > > > then expand on them in the future.
> > > > >
> > > > > There were a few of us on irc last night chatting about it.
> > > > >
> > > > > This is how I think we should move forward with this:
> > > > >
> > > > > 1 - as a group, decide on all the packages for both std vl and
> > > > > soho before we start
> > > > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k
> > > > > source trees) - probably either myself or Uel or anyone that want=
s to take
> > > > > ownership of this task - all base build scripts need to be correc=
ted for
> > > > > arch,flags,etc
> > > > > 3 - once the base is built, each developer is given a source tree
> > > > > or trees and they work on those on top of the base(vlbase.tgz).eg=
.
> > > > > kde,xap,etc - all packages must be built on a virgin base except =
for soho -
> > > > > 2 groups are needed here - std and soho and there will be some du=
plication
> > > > > as std and soho should be treated as separate distros - all build=
 scripts
> > > > > need to corrected for arch,flags,etc
> > > > > 4 - we need to come up with SlackBuilds for the packages we
> > > > > include that aren't in slack and split this up depending on how m=
any pkgs
> > > > > there are
> > > > > 5 - upload all the built packages to the respective trees and eac=
h
> > > > > of us install them for testing.
> > > > > 6 - once testing is completed, we package these up for the cd int=
o
> > > > > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related
> > > > > packages should reside in vl-std.tgz and vl-soho.tgz so that SOHO
> > > > > can be KDE only and have all packages built for it using kde as a=
 dep.
> > > > > 7 - release beta std and soho at the same time
> > > > > 8 - set a beta test schedule of 2 weeks
> > > > > 9 - fix and release rc
> > > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until
> > > > > stable.
> > > > > 11 - release final std and soho at the same time.
> > > > > 12 - designate a dev for each versions - std and soho - whose
> > > > > primary responsibility will be security patching
> > > > > 13 - start working on extra packages for the repo
> > > > > 14 - once there is a large repo of apps available, start the next
> > > > > cycle at step 1
> > > > >
> > > > > Let me know what you all think.  Having this process more
> > > > > organized and coordinated will allow us to work quicker and more =
efficiently
> > > > > giving us more time to create the extra app repo that is needed t=
o take VL
> > > > > to the next level. That way when Robert becomes rich from VL, he =
will share
> > > > > with all of us - lol.
> > > > >
> > > > > Regards,
> > > > >  Tony
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>

[Vectorlinux-devel] Re: Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

I agree that std and soho should be separate and should have separate
repos and I thought I made that clear in my original message - lol.

Live would be Uel's baby so I'll let him address that.  As part of his
live build, he could just strip out the dev stuff but then installing
that would be a pain since you couldn't make packages without having
to download everything.  Folks that need ati or nvidia drivers or any
other proprietary drivers would be SOL.


On 4/6/06, Sriram Durbha <sri...@gm...> wrote:
> hi, am sorry i could not be part of the irc conversation. But may i sugge=
st
> that we should consider the live versions also from the start?
> the key would be to start with a really simple base.
> here is the layout i have in mind[ very awkward.. but might work.. change=
s
> invited :) ]
>
> 1. Dev base
> 2. Non Dev base [ for the minimal live CD ]
> 3. Std [ 1 +  no kde - soho apps ]
> 4. SOHO [ 1 +  kde + soho apps ]
> 5. Std Live [ 2 + * ]
> 6. SOHO Live [ 2 +  kde + soho apps ]
>
> i agree that our primary objective for SoHo should be kde only. if there =
is
> a lot of demand for other WMs, that should be an additional package.
> what we release should be usable .. for example puppy linux uses VL as th=
eir
> host development system.   But their install is simple and clean.  We can=
 do
> a similar thing.
>
> commonly pooping up themes :
> 1. upgrade path from std to soho
> 2. --dist_upgrade
>
> If we ignore one 1. have two clearly demarcated repos for std and soho . =
2.
> is possible
>
> And it makes development and package management a lot easier if we consid=
er
> them two seperate Distros altogether.. they share only the vector
> philosophy.. and the non KDE part of the initial base system.  All packag=
es
> that can take advantage of having KDE as a dep should  have it .
>
> Life will be much much easier for ever one involved, devs, pkgers and use=
rs
> :)
> cheers
> ram
>
>
>
>
>
> On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >
> >
> > On 4/6/06, uel archuletta <ue...@gm...> wrote:
> >
> > >
> > >
> > >  On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> > > >
> > > >
> > > >
> > > >  On 4/6/06, uel archuletta < ue...@gm...> wrote:
> > > >
> > > > > Sounds good. I have some additions to a few of your propositions.
> > > > > here thay are
> > > > >
> > > > > 1. we have some package list we may be able to use to help in thi=
s
> > > > > they are in ftp in the VL6base folder.
> > > > > 2. I nominate you to build the base and get it setup for us. :)
> > > > >
> > > >
> > > >  OK
> > > >
> > > >
> > > >  3. sounds good, but do we have enough people to seperate into 2
> > > > > groups?
> > > > >
> > > >
> > > >  If not 2 groups, then each dev can have 2 partitions for dev - std
> > > > and soho. This shouldn't be too bad a task if we have all the pkgs
> decided
> > > > upon at the beginning and hand out the workload equally. Remember, =
in
> the
> > > > past Robert did std by himself and I did soho by myself on top of s=
td
> so it
> > > > is possible.
> > > >
> > >
> > > That is workable 2 seperate workloads if one has time/space they coul=
d
> > > work on both.
> > >
> > >
> > >
> > >   4. agree
> > > > > 5. agree
> > > > > 6. I along with others would like to see this borken down further=
.
> > > > > base-cli, dev, X, std, soho, some examples would be the package
> lists in
> > > > > VL6base on ftp.
> > > > >
> > > >
> > > >
> > > >  base-cli and dev will have to be 1 since we can't work on a base
> > > > without dev tools.
> > > >
> > >
> > > this is where I get things mixed up so correct me if I am wrong. if w=
e
> > > are building packages and populating a repo then we can build a base =
for
> the
> > > devs to build packages on that has all tools and X, and then build a
> base
> > > for the installer that has them seperated out. as long as we test the
> > > packages on this base as well.
> > >
> >
> >
> > I think this would create more work.  Apps built for SOHO would have
> > kde-centric additions wherever possible to integrate them better into t=
he
> > desktop environment. While we may use the same apps for std, they shoul=
d
> not
> > have kde deps in them.  This is kind of like the issue you get if you t=
ry
> to
> > install packages from linuxpackages.net - arts has a dep of gnome - wtf=
?
> > Whay would you build arts with a gnome dep. Same goes for apps for std
> that
> > might have a kde dep - not a good thing at all.
> >
> > The base would be common to all, including X and dev.  std(WM's and
> > apps) and soho(KDE and apps) would then be built on top of the base.  S=
oho
> > would have KDE as its first build so that any other app installs after
> that
> > would be able to use kde hooks where needed.
> >
> >
> >
> > >
> > >
> > >   X - if by this you mean xorg alone then I agree but if this include=
s
> > > > WM's,etc then no.
> > > >
> > >
> > > Vec asked if we couldnt include xfce in our xorg package since it is =
in
> > > both, and if we go down to the package level it woould simply mean
> adding it
> > > to the metapackage
> > >
> > >
> >
> >
> > I really don't think xfce should be in SOHO.  IMHO, 99% of those that g=
et
> > SOHO are getting it for kde and not xfce.  If they want xfce, they shou=
ld
> > stick with std.  This would also allow us to make soho easier and bette=
r
> due
> > to the fact that you wouldn't have to worry about menus and such as lon=
g
> as
> > a kde .desktop file was included with the packages.
> > Folks that are looking for xfce aren't looking for the bloat of kde and
> > those looking for the richness and integration of kde aren't looking fo=
r
> > xfce.  Again, we need to go back and look at the target market for thes=
e
> and
> > not what we want out of it.  We could always add wm's and such to the r=
epo
> > but I doubt they'd get a lot of hits.
> >
> > Concentrating only on kde for soho would be the best bet.  choosing app=
s
> > for soho should also be centred around kde as well so they integrate
> > properly into the DE.  The maturity of the apps for kde is there now an=
d
> we
> > should take advantage of that.
> >
> > The only folks I know that run SOHO with xfce are vec and monty - lol. =
No
> > offense guys.
> >
> > We need to focus on packages as that is what is really important. That =
is
> > why stuff like ubuntu, gentoo,etc have gained the popularity they have.
> > Folks don't have to go searching a million different places to get what
> they
> > need. It is all available from a central source for the most part.
> >
> > Linuxpackages and slacky.it are ok but they still have some goofyness t=
o
> > them with deps of stuff that isn't needed.
> >
> >
> >
> > >    7. I think there should be a seperation in release dates. 1 reason=
 is
> > > > > Distrowatch another is easier for us to debug.
> > > > > 8.agree
> > > > > 9.agree
> > > > > 10.agree
> > > > > 11. see #7
> > > > > 12. I really like this idea
> > > > > 13. agree
> > > > > 14. agree
> > > > >
> > > > > some really good ideas here Tony.
> > > > > Thanks,
> > > > >
> > > > > Uel
> > > > >
> > > > >
> > > > > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > > > > >
> > > > > >  Sorry if this has already been decided upon but I haven't been
> > > > > > made aware of it so here goes.
> > > > > >
> > > > > > I have been looking at these as I'm sure some or all of you hav=
e
> > > > > > as well.
> > > > > >
> > > > > > I think we can work with these to build our base from source an=
d
> > > > > > then expand on them in the future.
> > > > > >
> > > > > > There were a few of us on irc last night chatting about it.
> > > > > >
> > > > > > This is how I think we should move forward with this:
> > > > > >
> > > > > > 1 - as a group, decide on all the packages for both std vl and
> > > > > > soho before we start
> > > > > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l=
/k
> > > > > > source trees) - probably either myself or Uel or anyone that wa=
nts
> to take
> > > > > > ownership of this task - all base build scripts need to be
> corrected for
> > > > > > arch,flags,etc
> > > > > > 3 - once the base is built, each developer is given a source tr=
ee
> > > > > > or trees and they work on those on top of the base(vlbase.tgz).=
eg.
> > > > > > kde,xap,etc - all packages must be built on a virgin base excep=
t
> for soho -
> > > > > > 2 groups are needed here - std and soho and there will be some
> duplication
> > > > > > as std and soho should be treated as separate distros - all bui=
ld
> scripts
> > > > > > need to corrected for arch,flags,etc
> > > > > > 4 - we need to come up with SlackBuilds for the packages we
> > > > > > include that aren't in slack and split this up depending on how
> many pkgs
> > > > > > there are
> > > > > > 5 - upload all the built packages to the respective trees and e=
ach
> > > > > > of us install them for testing.
> > > > > > 6 - once testing is completed, we package these up for the cd i=
nto
> > > > > > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related
> > > > > > packages should reside in vl-std.tgz and vl-soho.tgz so that SO=
HO
> > > > > > can be KDE only and have all packages built for it using kde as=
 a
> dep.
> > > > > > 7 - release beta std and soho at the same time
> > > > > > 8 - set a beta test schedule of 2 weeks
> > > > > > 9 - fix and release rc
> > > > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 unt=
il
> > > > > > stable.
> > > > > > 11 - release final std and soho at the same time.
> > > > > > 12 - designate a dev for each versions - std and soho - whose
> > > > > > primary responsibility will be security patching
> > > > > > 13 - start working on extra packages for the repo
> > > > > > 14 - once there is a large repo of apps available, start the ne=
xt
> > > > > > cycle at step 1
> > > > > >
> > > > > > Let me know what you all think.  Having this process more
> > > > > > organized and coordinated will allow us to work quicker and mor=
e
> efficiently
> > > > > > giving us more time to create the extra app repo that is needed=
 to
> take VL
> > > > > > to the next level. That way when Robert becomes rich from VL, h=
e
> will share
> > > > > > with all of us - lol.
> > > > > >
> > > > > > Regards,
> > > > > >  Tony
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>

Re: [Vectorlinux-devel] Re: Slack Builds and VL - my suggestions

[uel a. <ue...@gm...>]

Tony,
How is everything going with the "Base" so far?
just thought I would check in and get an update.

Thanks,
Uel

On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
>
> I agree that std and soho should be separate and should have separate
> repos and I thought I made that clear in my original message - lol.
>
> Live would be Uel's baby so I'll let him address that.  As part of his
> live build, he could just strip out the dev stuff but then installing
> that would be a pain since you couldn't make packages without having
> to download everything.  Folks that need ati or nvidia drivers or any
> other proprietary drivers would be SOL.
>
>
> On 4/6/06, Sriram Durbha <sri...@gm...> wrote:
> > hi, am sorry i could not be part of the irc conversation. But may i
> suggest
> > that we should consider the live versions also from the start?
> > the key would be to start with a really simple base.
> > here is the layout i have in mind[ very awkward.. but might work..
> changes
> > invited :) ]
> >
> > 1. Dev base
> > 2. Non Dev base [ for the minimal live CD ]
> > 3. Std [ 1 +  no kde - soho apps ]
> > 4. SOHO [ 1 +  kde + soho apps ]
> > 5. Std Live [ 2 + * ]
> > 6. SOHO Live [ 2 +  kde + soho apps ]
> >
> > i agree that our primary objective for SoHo should be kde only. if ther=
e
> is
> > a lot of demand for other WMs, that should be an additional package.
> > what we release should be usable .. for example puppy linux uses VL as
> their
> > host development system.   But their install is simple and clean.  We
> can do
> > a similar thing.
> >
> > commonly pooping up themes :
> > 1. upgrade path from std to soho
> > 2. --dist_upgrade
> >
> > If we ignore one 1. have two clearly demarcated repos for std and soho =
.
> 2.
> > is possible
> >
> > And it makes development and package management a lot easier if we
> consider
> > them two seperate Distros altogether.. they share only the vector
> > philosophy.. and the non KDE part of the initial base system.  All
> packages
> > that can take advantage of having KDE as a dep should  have it .
> >
> > Life will be much much easier for ever one involved, devs, pkgers and
> users
> > :)
> > cheers
> > ram
> >
> >
> >
> >
> >
> > On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
> > >
> > >
> > >
> > > On 4/6/06, uel archuletta <ue...@gm...> wrote:
> > >
> > > >
> > > >
> > > >  On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> > > > >
> > > > >
> > > > >
> > > > >  On 4/6/06, uel archuletta < ue...@gm...> wrote:
> > > > >
> > > > > > Sounds good. I have some additions to a few of your
> propositions.
> > > > > > here thay are
> > > > > >
> > > > > > 1. we have some package list we may be able to use to help in
> this
> > > > > > they are in ftp in the VL6base folder.
> > > > > > 2. I nominate you to build the base and get it setup for us. :)
> > > > > >
> > > > >
> > > > >  OK
> > > > >
> > > > >
> > > > >  3. sounds good, but do we have enough people to seperate into 2
> > > > > > groups?
> > > > > >
> > > > >
> > > > >  If not 2 groups, then each dev can have 2 partitions for dev -
> std
> > > > > and soho. This shouldn't be too bad a task if we have all the pkg=
s
> > decided
> > > > > upon at the beginning and hand out the workload equally. Remember=
,
> in
> > the
> > > > > past Robert did std by himself and I did soho by myself on top of
> std
> > so it
> > > > > is possible.
> > > > >
> > > >
> > > > That is workable 2 seperate workloads if one has time/space they
> could
> > > > work on both.
> > > >
> > > >
> > > >
> > > >   4. agree
> > > > > > 5. agree
> > > > > > 6. I along with others would like to see this borken down
> further.
> > > > > > base-cli, dev, X, std, soho, some examples would be the package
> > lists in
> > > > > > VL6base on ftp.
> > > > > >
> > > > >
> > > > >
> > > > >  base-cli and dev will have to be 1 since we can't work on a base
> > > > > without dev tools.
> > > > >
> > > >
> > > > this is where I get things mixed up so correct me if I am wrong. if
> we
> > > > are building packages and populating a repo then we can build a bas=
e
> for
> > the
> > > > devs to build packages on that has all tools and X, and then build =
a
> > base
> > > > for the installer that has them seperated out. as long as we test
> the
> > > > packages on this base as well.
> > > >
> > >
> > >
> > > I think this would create more work.  Apps built for SOHO would have
> > > kde-centric additions wherever possible to integrate them better into
> the
> > > desktop environment. While we may use the same apps for std, they
> should
> > not
> > > have kde deps in them.  This is kind of like the issue you get if you
> try
> > to
> > > install packages from linuxpackages.net - arts has a dep of gnome -
> wtf?
> > > Whay would you build arts with a gnome dep. Same goes for apps for st=
d
> > that
> > > might have a kde dep - not a good thing at all.
> > >
> > > The base would be common to all, including X and dev.  std(WM's and
> > > apps) and soho(KDE and apps) would then be built on top of the
> base.  Soho
> > > would have KDE as its first build so that any other app installs afte=
r
> > that
> > > would be able to use kde hooks where needed.
> > >
> > >
> > >
> > > >
> > > >
> > > >   X - if by this you mean xorg alone then I agree but if this
> includes
> > > > > WM's,etc then no.
> > > > >
> > > >
> > > > Vec asked if we couldnt include xfce in our xorg package since it i=
s
> in
> > > > both, and if we go down to the package level it woould simply mean
> > adding it
> > > > to the metapackage
> > > >
> > > >
> > >
> > >
> > > I really don't think xfce should be in SOHO.  IMHO, 99% of those that
> get
> > > SOHO are getting it for kde and not xfce.  If they want xfce, they
> should
> > > stick with std.  This would also allow us to make soho easier and
> better
> > due
> > > to the fact that you wouldn't have to worry about menus and such as
> long
> > as
> > > a kde .desktop file was included with the packages.
> > > Folks that are looking for xfce aren't looking for the bloat of kde
> and
> > > those looking for the richness and integration of kde aren't looking
> for
> > > xfce.  Again, we need to go back and look at the target market for
> these
> > and
> > > not what we want out of it.  We could always add wm's and such to the
> repo
> > > but I doubt they'd get a lot of hits.
> > >
> > > Concentrating only on kde for soho would be the best bet.  choosing
> apps
> > > for soho should also be centred around kde as well so they integrate
> > > properly into the DE.  The maturity of the apps for kde is there now
> and
> > we
> > > should take advantage of that.
> > >
> > > The only folks I know that run SOHO with xfce are vec and monty - lol=
.
> No
> > > offense guys.
> > >
> > > We need to focus on packages as that is what is really important. Tha=
t
> is
> > > why stuff like ubuntu, gentoo,etc have gained the popularity they
> have.
> > > Folks don't have to go searching a million different places to get
> what
> > they
> > > need. It is all available from a central source for the most part.
> > >
> > > Linuxpackages and slacky.it are ok but they still have some goofyness
> to
> > > them with deps of stuff that isn't needed.
> > >
> > >
> > >
> > > >    7. I think there should be a seperation in release dates. 1
> reason is
> > > > > > Distrowatch another is easier for us to debug.
> > > > > > 8.agree
> > > > > > 9.agree
> > > > > > 10.agree
> > > > > > 11. see #7
> > > > > > 12. I really like this idea
> > > > > > 13. agree
> > > > > > 14. agree
> > > > > >
> > > > > > some really good ideas here Tony.
> > > > > > Thanks,
> > > > > >
> > > > > > Uel
> > > > > >
> > > > > >
> > > > > > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > > > > > >
> > > > > > >  Sorry if this has already been decided upon but I haven't
> been
> > > > > > > made aware of it so here goes.
> > > > > > >
> > > > > > > I have been looking at these as I'm sure some or all of you
> have
> > > > > > > as well.
> > > > > > >
> > > > > > > I think we can work with these to build our base from source
> and
> > > > > > > then expand on them in the future.
> > > > > > >
> > > > > > > There were a few of us on irc last night chatting about it.
> > > > > > >
> > > > > > > This is how I think we should move forward with this:
> > > > > > >
> > > > > > > 1 - as a group, decide on all the packages for both std vl an=
d
> > > > > > > soho before we start
> > > > > > > 2 - 1 person designated to build the bare minimum
> base(a/ap/d/l/k
> > > > > > > source trees) - probably either myself or Uel or anyone that
> wants
> > to take
> > > > > > > ownership of this task - all base build scripts need to be
> > corrected for
> > > > > > > arch,flags,etc
> > > > > > > 3 - once the base is built, each developer is given a source
> tree
> > > > > > > or trees and they work on those on top of the base(vlbase.tgz
> ).eg.
> > > > > > > kde,xap,etc - all packages must be built on a virgin base
> except
> > for soho -
> > > > > > > 2 groups are needed here - std and soho and there will be som=
e
> > duplication
> > > > > > > as std and soho should be treated as separate distros - all
> build
> > scripts
> > > > > > > need to corrected for arch,flags,etc
> > > > > > > 4 - we need to come up with SlackBuilds for the packages we
> > > > > > > include that aren't in slack and split this up depending on
> how
> > many pkgs
> > > > > > > there are
> > > > > > > 5 - upload all the built packages to the respective trees and
> each
> > > > > > > of us install them for testing.
> > > > > > > 6 - once testing is completed, we package these up for the cd
> into
> > > > > > > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related
> > > > > > > packages should reside in vl-std.tgz and vl-soho.tgz so that
> SOHO
> > > > > > > can be KDE only and have all packages built for it using kde
> as a
> > dep.
> > > > > > > 7 - release beta std and soho at the same time
> > > > > > > 8 - set a beta test schedule of 2 weeks
> > > > > > > 9 - fix and release rc
> > > > > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10
> until
> > > > > > > stable.
> > > > > > > 11 - release final std and soho at the same time.
> > > > > > > 12 - designate a dev for each versions - std and soho - whose
> > > > > > > primary responsibility will be security patching
> > > > > > > 13 - start working on extra packages for the repo
> > > > > > > 14 - once there is a large repo of apps available, start the
> next
> > > > > > > cycle at step 1
> > > > > > >
> > > > > > > Let me know what you all think.  Having this process more
> > > > > > > organized and coordinated will allow us to work quicker and
> more
> > efficiently
> > > > > > > giving us more time to create the extra app repo that is
> needed to
> > take VL
> > > > > > > to the next level. That way when Robert becomes rich from VL,
> he
> > will share
> > > > > > > with all of us - lol.
> > > > > > >
> > > > > > > Regards,
> > > > > > >  Tony
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>

Re: [Vectorlinux-devel] Re: Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

I'm still waiting for everyone to decide on a package list - complete.  Onc=
e
we have that, I will build the base.



On 4/14/06, uel archuletta <ue...@gm...> wrote:
>
> Tony,
> How is everything going with the "Base" so far?
> just thought I would check in and get an update.
>
> Thanks,
> Uel
>
> On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
>
> > I agree that std and soho should be separate and should have separate
> repos and I thought I made that clear in my original message - lol.
>
> Live would be Uel's baby so I'll let him address that.  As part of his
> live build, he could just strip out the dev stuff but then installing
> that would be a pain since you couldn't make packages without having
> to download everything.  Folks that need ati or nvidia drivers or any
> other proprietary drivers would be SOL.
>
>
> On 4/6/06, Sriram Durbha <sri...@gm...> wrote:
> > hi, am sorry i could not be part of the irc conversation. But may i
> suggest
> > that we should consider the live versions also from the start?
> > the key would be to start with a really simple base.
> > here is the layout i have in mind[ very awkward.. but might work..
> changes
> > invited :) ]
> >
> > 1. Dev base
> > 2. Non Dev base [ for the minimal live CD ]
> > 3. Std [ 1 +  no kde - soho apps ]
> > 4. SOHO [ 1 +  kde + soho apps ]
> > 5. Std Live [ 2 + * ]
> > 6. SOHO Live [ 2 +  kde + soho apps ]
> >
> > i agree that our primary objective for SoHo should be kde only. if ther=
e
> is
> > a lot of demand for other WMs, that should be an additional package.
> > what we release should be usable .. for example puppy linux uses VL as
> their
> > host development system.   But their install is simple and clean.  We
> can do
> > a similar thing.
> >
> > commonly pooping up themes :
> > 1. upgrade path from std to soho
> > 2. --dist_upgrade
> >
> > If we ignore one 1. have two clearly demarcated repos for std and soho =
.
> 2.
> > is possible
> >
> > And it makes development and package management a lot easier if we
> consider
> > them two seperate Distros altogether.. they share only the vector
> > philosophy.. and the non KDE part of the initial base system.  All
> packages
> > that can take advantage of having KDE as a dep should  have it .
> >
> > Life will be much much easier for ever one involved, devs, pkgers and
> users
> > :)
> > cheers
> > ram
> >
> >
> >
> >
> >
> > On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
> > >
> > >
> > >
> > > On 4/6/06, uel archuletta < ue...@gm...> wrote:
> > >
> > > >
> > > >
> > > >  On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> > > > >
> > > > >
> > > > >
> > > > >  On 4/6/06, uel archuletta < ue...@gm...> wrote:
> > > > >
> > > > > > Sounds good. I have some additions to a few of your
> propositions.
> > > > > > here thay are
> > > > > >
> > > > > > 1. we have some package list we may be able to use to help in
> this
> > > > > > they are in ftp in the VL6base folder.
> > > > > > 2. I nominate you to build the base and get it setup for us. :)
> > > > > >
> > > > >
> > > > >  OK
> > > > >
> > > > >
> > > > >  3. sounds good, but do we have enough people to seperate into 2
> > > > > > groups?
> > > > > >
> > > > >
> > > > >  If not 2 groups, then each dev can have 2 partitions for dev -
> std
> > > > > and soho. This shouldn't be too bad a task if we have all the pkg=
s
>
> > decided
> > > > > upon at the beginning and hand out the workload equally. Remember=
,
> in
> > the
> > > > > past Robert did std by himself and I did soho by myself on top of
> std
> > so it
> > > > > is possible.
> > > > >
> > > >
> > > > That is workable 2 seperate workloads if one has time/space they
> could
> > > > work on both.
> > > >
> > > >
> > > >
> > > >   4. agree
> > > > > > 5. agree
> > > > > > 6. I along with others would like to see this borken down
> further.
> > > > > > base-cli, dev, X, std, soho, some examples would be the package
> > lists in
> > > > > > VL6base on ftp.
> > > > > >
> > > > >
> > > > >
> > > > >  base-cli and dev will have to be 1 since we can't work on a base
> > > > > without dev tools.
> > > > >
> > > >
> > > > this is where I get things mixed up so correct me if I am wrong. if
> we
> > > > are building packages and populating a repo then we can build a bas=
e
> for
> > the
> > > > devs to build packages on that has all tools and X, and then build =
a
> > base
> > > > for the installer that has them seperated out. as long as we test
> the
> > > > packages on this base as well.
> > > >
> > >
> > >
> > > I think this would create more work.  Apps built for SOHO would have
> > > kde-centric additions wherever possible to integrate them better into
> the
> > > desktop environment. While we may use the same apps for std, they
> should
> > not
> > > have kde deps in them.  This is kind of like the issue you get if you
> try
> > to
> > > install packages from linuxpackages.net - arts has a dep of gnome -
> wtf?
> > > Whay would you build arts with a gnome dep. Same goes for apps for st=
d
> > that
> > > might have a kde dep - not a good thing at all.
> > >
> > > The base would be common to all, including X and dev.  std(WM's and
> > > apps) and soho(KDE and apps) would then be built on top of the
> base.  Soho
> > > would have KDE as its first build so that any other app installs afte=
r
> > that
> > > would be able to use kde hooks where needed.
> > >
> > >
> > >
> > > >
> > > >
> > > >   X - if by this you mean xorg alone then I agree but if this
> includes
> > > > > WM's,etc then no.
> > > > >
> > > >
> > > > Vec asked if we couldnt include xfce in our xorg package since it i=
s
> in
> > > > both, and if we go down to the package level it woould simply mean
> > adding it
> > > > to the metapackage
> > > >
> > > >
> > >
> > >
> > > I really don't think xfce should be in SOHO.  IMHO, 99% of those that
> get
> > > SOHO are getting it for kde and not xfce.  If they want xfce, they
> should
> > > stick with std.  This would also allow us to make soho easier and
> better
> > due
> > > to the fact that you wouldn't have to worry about menus and such as
> long
> > as
> > > a kde .desktop file was included with the packages.
> > > Folks that are looking for xfce aren't looking for the bloat of kde
> and
> > > those looking for the richness and integration of kde aren't looking
> for
> > > xfce.  Again, we need to go back and look at the target market for
> these
> > and
> > > not what we want out of it.  We could always add wm's and such to the
> repo
> > > but I doubt they'd get a lot of hits.
> > >
> > > Concentrating only on kde for soho would be the best bet.  choosing
> apps
> > > for soho should also be centred around kde as well so they integrate
> > > properly into the DE.  The maturity of the apps for kde is there now
> and
> > we
> > > should take advantage of that.
> > >
> > > The only folks I know that run SOHO with xfce are vec and monty - lol=
.
> No
> > > offense guys.
> > >
> > > We need to focus on packages as that is what is really important. Tha=
t
> is
> > > why stuff like ubuntu, gentoo,etc have gained the popularity they
> have.
> > > Folks don't have to go searching a million different places to get
> what
> > they
> > > need. It is all available from a central source for the most part.
> > >
> > > Linuxpackages and slacky.it are ok but they still have some goofyness
> to
> > > them with deps of stuff that isn't needed.
> > >
> > >
> > >
> > > >    7. I think there should be a seperation in release dates. 1
> reason is
> > > > > > Distrowatch another is easier for us to debug.
> > > > > > 8.agree
> > > > > > 9.agree
> > > > > > 10.agree
> > > > > > 11. see #7
> > > > > > 12. I really like this idea
> > > > > > 13. agree
> > > > > > 14. agree
> > > > > >
> > > > > > some really good ideas here Tony.
> > > > > > Thanks,
> > > > > >
> > > > > > Uel
> > > > > >
> > > > > >
> > > > > > On 4/5/06, Tony Brijeski < tb...@gm...> wrote:
> > > > > > >
> > > > > > >  Sorry if this has already been decided upon but I haven't
> been
> > > > > > > made aware of it so here goes.
> > > > > > >
> > > > > > > I have been looking at these as I'm sure some or all of you
> have
> > > > > > > as well.
> > > > > > >
> > > > > > > I think we can work with these to build our base from source
> and
> > > > > > > then expand on them in the future.
> > > > > > >
> > > > > > > There were a few of us on irc last night chatting about it.
> > > > > > >
> > > > > > > This is how I think we should move forward with this:
> > > > > > >
> > > > > > > 1 - as a group, decide on all the packages for both std vl an=
d
> > > > > > > soho before we start
> > > > > > > 2 - 1 person designated to build the bare minimum
> base(a/ap/d/l/k
> > > > > > > source trees) - probably either myself or Uel or anyone that
> wants
> > to take
> > > > > > > ownership of this task - all base build scripts need to be
> > corrected for
> > > > > > > arch,flags,etc
> > > > > > > 3 - once the base is built, each developer is given a source
> tree
> > > > > > > or trees and they work on those on top of the base( vlbase.tg=
z
> ).eg.
> > > > > > > kde,xap,etc - all packages must be built on a virgin base
> except
> > for soho -
> > > > > > > 2 groups are needed here - std and soho and there will be som=
e
>
> > duplication
> > > > > > > as std and soho should be treated as separate distros - all
> build
> > scripts
> > > > > > > need to corrected for arch,flags,etc
> > > > > > > 4 - we need to come up with SlackBuilds for the packages we
> > > > > > > include that aren't in slack and split this up depending on
> how
> > many pkgs
> > > > > > > there are
> > > > > > > 5 - upload all the built packages to the respective trees and
> each
> > > > > > > of us install them for testing.
> > > > > > > 6 - once testing is completed, we package these up for the cd
> into
> > > > > > > vl-base.tgz,vl-std.tgz , and vl-soho.tgz - all X and related
> > > > > > > packages should reside in vl-std.tgz and vl-soho.tgz so that
> SOHO
> > > > > > > can be KDE only and have all packages built for it using kde
> as a
> > dep.
> > > > > > > 7 - release beta std and soho at the same time
> > > > > > > 8 - set a beta test schedule of 2 weeks
> > > > > > > 9 - fix and release rc
> > > > > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10
> until
> > > > > > > stable.
> > > > > > > 11 - release final std and soho at the same time.
> > > > > > > 12 - designate a dev for each versions - std and soho - whose
> > > > > > > primary responsibility will be security patching
> > > > > > > 13 - start working on extra packages for the repo
> > > > > > > 14 - once there is a large repo of apps available, start the
> next
> > > > > > > cycle at step 1
> > > > > > >
> > > > > > > Let me know what you all think.  Having this process more
> > > > > > > organized and coordinated will allow us to work quicker and
> more
> > efficiently
> > > > > > > giving us more time to create the extra app repo that is
> needed to
> > take VL
> > > > > > > to the next level. That way when Robert becomes rich from VL,
> he
> > will share
> > > > > > > with all of us - lol.
> > > > > > >
> > > > > > > Regards,
> > > > > > >  Tony
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
> -------------------------------------------------------
>
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642<htt=
p://sel.as-us.falkag.net/sel?cmdlnk&kid%110944&bid$1720&dat%121642>
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>
>

Re: [Vectorlinux-devel] Re: Slack Builds and VL - my suggestions

[uel a. <ue...@gm...>]

Tony,
The package lists are fially finished
they are in vectors folder on the ftp
let us know if you need anything else.

Thanks,
Uel

On 4/13/06, Tony Brijeski <tb...@gm...> wrote:
>
> I'm still waiting for everyone to decide on a package list - complete.
> Once we have that, I will build the base.
>
>
>
>
> On 4/14/06, uel archuletta < ue...@gm...> wrote:
> >
> > Tony,
> > How is everything going with the "Base" so far?
> > just thought I would check in and get an update.
> >
> > Thanks,
> > Uel
> >
> > On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> >
> > >  I agree that std and soho should be separate and should have separat=
e
> > repos and I thought I made that clear in my original message - lol.
> >
> > Live would be Uel's baby so I'll let him address that.  As part of his
> > live build, he could just strip out the dev stuff but then installing
> > that would be a pain since you couldn't make packages without having
> > to download everything.  Folks that need ati or nvidia drivers or any
> > other proprietary drivers would be SOL.
> >
> >
> > On 4/6/06, Sriram Durbha <sri...@gm...> wrote:
> > > hi, am sorry i could not be part of the irc conversation. But may i
> > suggest
> > > that we should consider the live versions also from the start?
> > > the key would be to start with a really simple base.
> > > here is the layout i have in mind[ very awkward.. but might work..
> > changes
> > > invited :) ]
> > >
> > > 1. Dev base
> > > 2. Non Dev base [ for the minimal live CD ]
> > > 3. Std [ 1 +  no kde - soho apps ]
> > > 4. SOHO [ 1 +  kde + soho apps ]
> > > 5. Std Live [ 2 + * ]
> > > 6. SOHO Live [ 2 +  kde + soho apps ]
> > >
> > > i agree that our primary objective for SoHo should be kde only. if
> > there is
> > > a lot of demand for other WMs, that should be an additional package.
> > > what we release should be usable .. for example puppy linux uses VL a=
s
> > their
> > > host development system.   But their install is simple and clean.  We
> > can do
> > > a similar thing.
> > >
> > > commonly pooping up themes :
> > > 1. upgrade path from std to soho
> > > 2. --dist_upgrade
> > >
> > > If we ignore one 1. have two clearly demarcated repos for std and soh=
o
> > . 2.
> > > is possible
> > >
> > > And it makes development and package management a lot easier if we
> > consider
> > > them two seperate Distros altogether.. they share only the vector
> > > philosophy.. and the non KDE part of the initial base system.  All
> > packages
> > > that can take advantage of having KDE as a dep should  have it .
> > >
> > > Life will be much much easier for ever one involved, devs, pkgers and
> > users
> > > :)
> > > cheers
> > > ram
> > >
> > >
> > >
> > >
> > >
> > > On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
> > > >
> > > >
> > > >
> > > > On 4/6/06, uel archuletta < ue...@gm...> wrote:
> > > >
> > > > >
> > > > >
> > > > >  On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >  On 4/6/06, uel archuletta < ue...@gm... > wrote:
> > > > > >
> > > > > > > Sounds good. I have some additions to a few of your
> > propositions.
> > > > > > > here thay are
> > > > > > >
> > > > > > > 1. we have some package list we may be able to use to help in
> > this
> > > > > > > they are in ftp in the VL6base folder.
> > > > > > > 2. I nominate you to build the base and get it setup for us.
> > :)
> > > > > > >
> > > > > >
> > > > > >  OK
> > > > > >
> > > > > >
> > > > > >  3. sounds good, but do we have enough people to seperate into =
2
> >
> > > > > > > groups?
> > > > > > >
> > > > > >
> > > > > >  If not 2 groups, then each dev can have 2 partitions for dev -
> > std
> > > > > > and soho. This shouldn't be too bad a task if we have all the
> > pkgs
> > > decided
> > > > > > upon at the beginning and hand out the workload equally.
> > Remember, in
> > > the
> > > > > > past Robert did std by himself and I did soho by myself on top
> > of std
> > > so it
> > > > > > is possible.
> > > > > >
> > > > >
> > > > > That is workable 2 seperate workloads if one has time/space they
> > could
> > > > > work on both.
> > > > >
> > > > >
> > > > >
> > > > >   4. agree
> > > > > > > 5. agree
> > > > > > > 6. I along with others would like to see this borken down
> > further.
> > > > > > > base-cli, dev, X, std, soho, some examples would be the
> > package
> > > lists in
> > > > > > > VL6base on ftp.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >  base-cli and dev will have to be 1 since we can't work on a
> > base
> > > > > > without dev tools.
> > > > > >
> > > > >
> > > > > this is where I get things mixed up so correct me if I am wrong.
> > if we
> > > > > are building packages and populating a repo then we can build a
> > base for
> > > the
> > > > > devs to build packages on that has all tools and X, and then buil=
d
> > a
> > > base
> > > > > for the installer that has them seperated out. as long as we test
> > the
> > > > > packages on this base as well.
> > > > >
> > > >
> > > >
> > > > I think this would create more work.  Apps built for SOHO would hav=
e
> > > > kde-centric additions wherever possible to integrate them better
> > into the
> > > > desktop environment. While we may use the same apps for std, they
> > should
> > > not
> > > > have kde deps in them.  This is kind of like the issue you get if
> > you try
> > > to
> > > > install packages from linuxpackages.net - arts has a dep of gnome -
> > wtf?
> > > > Whay would you build arts with a gnome dep. Same goes for apps for
> > std
> > > that
> > > > might have a kde dep - not a good thing at all.
> > > >
> > > > The base would be common to all, including X and dev.  std(WM's and
> > > > apps) and soho(KDE and apps) would then be built on top of the
> > base.  Soho
> > > > would have KDE as its first build so that any other app installs
> > after
> > > that
> > > > would be able to use kde hooks where needed.
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >   X - if by this you mean xorg alone then I agree but if this
> > includes
> > > > > > WM's,etc then no.
> > > > > >
> > > > >
> > > > > Vec asked if we couldnt include xfce in our xorg package since it
> > is in
> > > > > both, and if we go down to the package level it woould simply mea=
n
> > > adding it
> > > > > to the metapackage
> > > > >
> > > > >
> > > >
> > > >
> > > > I really don't think xfce should be in SOHO.  IMHO, 99% of those
> > that get
> > > > SOHO are getting it for kde and not xfce.  If they want xfce, they
> > should
> > > > stick with std.  This would also allow us to make soho easier and
> > better
> > > due
> > > > to the fact that you wouldn't have to worry about menus and such as
> > long
> > > as
> > > > a kde .desktop file was included with the packages.
> > > > Folks that are looking for xfce aren't looking for the bloat of kde
> > and
> > > > those looking for the richness and integration of kde aren't lookin=
g
> > for
> > > > xfce.  Again, we need to go back and look at the target market for
> > these
> > > and
> > > > not what we want out of it.  We could always add wm's and such to
> > the repo
> > > > but I doubt they'd get a lot of hits.
> > > >
> > > > Concentrating only on kde for soho would be the best bet.  choosing
> > apps
> > > > for soho should also be centred around kde as well so they integrat=
e
> > > > properly into the DE.  The maturity of the apps for kde is there no=
w
> > and
> > > we
> > > > should take advantage of that.
> > > >
> > > > The only folks I know that run SOHO with xfce are vec and monty -
> > lol. No
> > > > offense guys.
> > > >
> > > > We need to focus on packages as that is what is really important.
> > That is
> > > > why stuff like ubuntu, gentoo,etc have gained the popularity they
> > have.
> > > > Folks don't have to go searching a million different places to get
> > what
> > > they
> > > > need. It is all available from a central source for the most part.
> > > >
> > > > Linuxpackages and slacky.it are ok but they still have some
> > goofyness to
> > > > them with deps of stuff that isn't needed.
> > > >
> > > >
> > > >
> > > > >    7. I think there should be a seperation in release dates. 1
> > reason is
> > > > > > > Distrowatch another is easier for us to debug.
> > > > > > > 8.agree
> > > > > > > 9.agree
> > > > > > > 10.agree
> > > > > > > 11. see #7
> > > > > > > 12. I really like this idea
> > > > > > > 13. agree
> > > > > > > 14. agree
> > > > > > >
> > > > > > > some really good ideas here Tony.
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Uel
> > > > > > >
> > > > > > >
> > > > > > > On 4/5/06, Tony Brijeski < tb...@gm...> wrote:
> > > > > > > >
> > > > > > > >  Sorry if this has already been decided upon but I haven't
> > been
> > > > > > > > made aware of it so here goes.
> > > > > > > >
> > > > > > > > I have been looking at these as I'm sure some or all of you
> > have
> > > > > > > > as well.
> > > > > > > >
> > > > > > > > I think we can work with these to build our base from sourc=
e
> > and
> > > > > > > > then expand on them in the future.
> > > > > > > >
> > > > > > > > There were a few of us on irc last night chatting about it.
> > > > > > > >
> > > > > > > > This is how I think we should move forward with this:
> > > > > > > >
> > > > > > > > 1 - as a group, decide on all the packages for both std vl
> > and
> > > > > > > > soho before we start
> > > > > > > > 2 - 1 person designated to build the bare minimum
> > base(a/ap/d/l/k
> > > > > > > > source trees) - probably either myself or Uel or anyone tha=
t
> > wants
> > > to take
> > > > > > > > ownership of this task - all base build scripts need to be
> > > corrected for
> > > > > > > > arch,flags,etc
> > > > > > > > 3 - once the base is built, each developer is given a sourc=
e
> > tree
> > > > > > > > or trees and they work on those on top of the base(
> > vlbase.tgz).eg.
> > > > > > > > kde,xap,etc - all packages must be built on a virgin base
> > except
> > > for soho -
> > > > > > > > 2 groups are needed here - std and soho and there will be
> > some
> > > duplication
> > > > > > > > as std and soho should be treated as separate distros - all
> > build
> > > scripts
> > > > > > > > need to corrected for arch,flags,etc
> > > > > > > > 4 - we need to come up with SlackBuilds for the packages we
> > > > > > > > include that aren't in slack and split this up depending on
> > how
> > > many pkgs
> > > > > > > > there are
> > > > > > > > 5 - upload all the built packages to the respective trees
> > and each
> > > > > > > > of us install them for testing.
> > > > > > > > 6 - once testing is completed, we package these up for the
> > cd into
> > > > > > > > vl-base.tgz,vl-std.tgz , and vl-soho.tgz - all X and relate=
d
> > > > > > > > packages should reside in vl-std.tgz and vl-soho.tgz so tha=
t
> > SOHO
> > > > > > > > can be KDE only and have all packages built for it using kd=
e
> > as a
> > > dep.
> > > > > > > > 7 - release beta std and soho at the same time
> > > > > > > > 8 - set a beta test schedule of 2 weeks
> > > > > > > > 9 - fix and release rc
> > > > > > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10
> > until
> > > > > > > > stable.
> > > > > > > > 11 - release final std and soho at the same time.
> > > > > > > > 12 - designate a dev for each versions - std and soho -
> > whose
> > > > > > > > primary responsibility will be security patching
> > > > > > > > 13 - start working on extra packages for the repo
> > > > > > > > 14 - once there is a large repo of apps available, start th=
e
> > next
> > > > > > > > cycle at step 1
> > > > > > > >
> > > > > > > > Let me know what you all think.  Having this process more
> > > > > > > > organized and coordinated will allow us to work quicker and
> > more
> > > efficiently
> > > > > > > > giving us more time to create the extra app repo that is
> > needed to
> > > take VL
> > > > > > > > to the next level. That way when Robert becomes rich from
> > VL, he
> > > will share
> > > > > > > > with all of us - lol.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >  Tony
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > -------------------------------------------------------
> >
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language
> > that extends applications into web and mobile media. Attend the live
> > webcast
> > and join the prime developer group breaking into this new coding
> > territory!
> > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642<h=
ttp://sel.as-us.falkag.net/sel?cmdlnk&kid%110944&bid$1720&dat%121642>
> > _______________________________________________
> > Vectorlinux-devel mailing list
> > Vec...@li...
> > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> >
> >
>

Re: [Vectorlinux-devel] Re: Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

I will get cracking this weekend and let you all know how I make out.

On 4/21/06, uel archuletta <ue...@gm...> wrote:
>
> Tony,
> The package lists are fially finished
> they are in vectors folder on the ftp
> let us know if you need anything else.
>
> Thanks,
>
> Uel
>
>
> On 4/13/06, Tony Brijeski <tb...@gm...> wrote:
> >
> > I'm still waiting for everyone to decide on a package list - complete.
> > Once we have that, I will build the base.
> >
> >
> >
> >
> > On 4/14/06, uel archuletta < ue...@gm...> wrote:
> > >
> > > Tony,
> > > How is everything going with the "Base" so far?
> > > just thought I would check in and get an update.
> > >
> > > Thanks,
> > > Uel
> > >
> > >  On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> > >
> > > > I agree that std and soho should be separate and should have
> > > separate
> > > repos and I thought I made that clear in my original message - lol.
> > >
> > > Live would be Uel's baby so I'll let him address that.  As part of hi=
s
> > > live build, he could just strip out the dev stuff but then installing
> > > that would be a pain since you couldn't make packages without having
> > > to download everything.  Folks that need ati or nvidia drivers or any
> > > other proprietary drivers would be SOL.
> > >
> > >
> > > On 4/6/06, Sriram Durbha <sri...@gm...> wrote:
> > > > hi, am sorry i could not be part of the irc conversation. But may i
> > > suggest
> > > > that we should consider the live versions also from the start?
> > > > the key would be to start with a really simple base.
> > > > here is the layout i have in mind[ very awkward.. but might work..
> > > changes
> > > > invited :) ]
> > > >
> > > > 1. Dev base
> > > > 2. Non Dev base [ for the minimal live CD ]
> > > > 3. Std [ 1 +  no kde - soho apps ]
> > > > 4. SOHO [ 1 +  kde + soho apps ]
> > > > 5. Std Live [ 2 + * ]
> > > > 6. SOHO Live [ 2 +  kde + soho apps ]
> > > >
> > > > i agree that our primary objective for SoHo should be kde only. if
> > > there is
> > > > a lot of demand for other WMs, that should be an additional package=
.
> > > > what we release should be usable .. for example puppy linux uses VL
> > > as their
> > > > host development system.   But their install is simple and
> > > clean.  We can do
> > > > a similar thing.
> > > >
> > > > commonly pooping up themes :
> > > > 1. upgrade path from std to soho
> > > > 2. --dist_upgrade
> > > >
> > > > If we ignore one 1. have two clearly demarcated repos for std and
> > > soho . 2.
> > > > is possible
> > > >
> > > > And it makes development and package management a lot easier if we
> > > consider
> > > > them two seperate Distros altogether.. they share only the vector
> > > > philosophy.. and the non KDE part of the initial base system.  All
> > > packages
> > > > that can take advantage of having KDE as a dep should  have it .
> > > >
> > > > Life will be much much easier for ever one involved, devs, pkgers
> > > and users
> > > > :)
> > > > cheers
> > > > ram
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 4/6/06, uel archuletta < ue...@gm...> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >  On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >  On 4/6/06, uel archuletta < ue...@gm... > wrote:
> > > > > > >
> > > > > > > > Sounds good. I have some additions to a few of your
> > > propositions.
> > > > > > > > here thay are
> > > > > > > >
> > > > > > > > 1. we have some package list we may be able to use to help
> > > in this
> > > > > > > > they are in ftp in the VL6base folder.
> > > > > > > > 2. I nominate you to build the base and get it setup for us=
.
> > > :)
> > > > > > > >
> > > > > > >
> > > > > > >  OK
> > > > > > >
> > > > > > >
> > > > > > >  3. sounds good, but do we have enough people to seperate int=
o
> > > 2
> > > > > > > > groups?
> > > > > > > >
> > > > > > >
> > > > > > >  If not 2 groups, then each dev can have 2 partitions for dev
> > > - std
> > > > > > > and soho. This shouldn't be too bad a task if we have all the
> > > pkgs
> > > > decided
> > > > > > > upon at the beginning and hand out the workload equally.
> > > Remember, in
> > > > the
> > > > > > > past Robert did std by himself and I did soho by myself on to=
p
> > > of std
> > > > so it
> > > > > > > is possible.
> > > > > > >
> > > > > >
> > > > > > That is workable 2 seperate workloads if one has time/space the=
y
> > > could
> > > > > > work on both.
> > > > > >
> > > > > >
> > > > > >
> > > > > >   4. agree
> > > > > > > > 5. agree
> > > > > > > > 6. I along with others would like to see this borken down
> > > further.
> > > > > > > > base-cli, dev, X, std, soho, some examples would be the
> > > package
> > > > lists in
> > > > > > > > VL6base on ftp.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >  base-cli and dev will have to be 1 since we can't work on a
> > > base
> > > > > > > without dev tools.
> > > > > > >
> > > > > >
> > > > > > this is where I get things mixed up so correct me if I am wrong=
.
> > > if we
> > > > > > are building packages and populating a repo then we can build a
> > > base for
> > > > the
> > > > > > devs to build packages on that has all tools and X, and then
> > > build a
> > > > base
> > > > > > for the installer that has them seperated out. as long as we
> > > test the
> > > > > > packages on this base as well.
> > > > > >
> > > > >
> > > > >
> > > > > I think this would create more work.  Apps built for SOHO would
> > > have
> > > > > kde-centric additions wherever possible to integrate them better
> > > into the
> > > > > desktop environment. While we may use the same apps for std, they
> > > should
> > > > not
> > > > > have kde deps in them.  This is kind of like the issue you get if
> > > you try
> > > > to
> > > > > install packages from linuxpackages.net - arts has a dep of gnome
> > > - wtf?
> > > > > Whay would you build arts with a gnome dep. Same goes for apps fo=
r
> > > std
> > > > that
> > > > > might have a kde dep - not a good thing at all.
> > > > >
> > > > > The base would be common to all, including X and dev.  std(WM's
> > > and
> > > > > apps) and soho(KDE and apps) would then be built on top of the
> > > base.  Soho
> > > > > would have KDE as its first build so that any other app installs
> > > after
> > > > that
> > > > > would be able to use kde hooks where needed.
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >   X - if by this you mean xorg alone then I agree but if this
> > > includes
> > > > > > > WM's,etc then no.
> > > > > > >
> > > > > >
> > > > > > Vec asked if we couldnt include xfce in our xorg package since
> > > it is in
> > > > > > both, and if we go down to the package level it woould simply
> > > mean
> > > > adding it
> > > > > > to the metapackage
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > I really don't think xfce should be in SOHO.  IMHO, 99% of those
> > > that get
> > > > > SOHO are getting it for kde and not xfce.  If they want xfce, the=
y
> > > should
> > > > > stick with std.  This would also allow us to make soho easier and
> > > better
> > > > due
> > > > > to the fact that you wouldn't have to worry about menus and such
> > > as long
> > > > as
> > > > > a kde .desktop file was included with the packages.
> > > > > Folks that are looking for xfce aren't looking for the bloat of
> > > kde and
> > > > > those looking for the richness and integration of kde aren't
> > > looking for
> > > > > xfce.  Again, we need to go back and look at the target market fo=
r
> > > these
> > > > and
> > > > > not what we want out of it.  We could always add wm's and such to
> > > the repo
> > > > > but I doubt they'd get a lot of hits.
> > > > >
> > > > > Concentrating only on kde for soho would be the best
> > > bet.  choosing apps
> > > > > for soho should also be centred around kde as well so they
> > > integrate
> > > > > properly into the DE.  The maturity of the apps for kde is there
> > > now and
> > > > we
> > > > > should take advantage of that.
> > > > >
> > > > > The only folks I know that run SOHO with xfce are vec and monty -
> > > lol. No
> > > > > offense guys.
> > > > >
> > > > > We need to focus on packages as that is what is really important.
> > > That is
> > > > > why stuff like ubuntu, gentoo,etc have gained the popularity they
> > > have.
> > > > > Folks don't have to go searching a million different places to ge=
t
> > > what
> > > > they
> > > > > need. It is all available from a central source for the most part=
.
> > >
> > > > >
> > > > > Linuxpackages and slacky.it are ok but they still have some
> > > goofyness to
> > > > > them with deps of stuff that isn't needed.
> > > > >
> > > > >
> > > > >
> > > > > >    7. I think there should be a seperation in release dates. 1
> > > reason is
> > > > > > > > Distrowatch another is easier for us to debug.
> > > > > > > > 8.agree
> > > > > > > > 9.agree
> > > > > > > > 10.agree
> > > > > > > > 11. see #7
> > > > > > > > 12. I really like this idea
> > > > > > > > 13. agree
> > > > > > > > 14. agree
> > > > > > > >
> > > > > > > > some really good ideas here Tony.
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Uel
> > > > > > > >
> > > > > > > >
> > > > > > > > On 4/5/06, Tony Brijeski < tb...@gm...> wrote:
> > > > > > > > >
> > > > > > > > >  Sorry if this has already been decided upon but I haven'=
t
> > > been
> > > > > > > > > made aware of it so here goes.
> > > > > > > > >
> > > > > > > > > I have been looking at these as I'm sure some or all of
> > > you have
> > > > > > > > > as well.
> > > > > > > > >
> > > > > > > > > I think we can work with these to build our base from
> > > source and
> > > > > > > > > then expand on them in the future.
> > > > > > > > >
> > > > > > > > > There were a few of us on irc last night chatting about
> > > it.
> > > > > > > > >
> > > > > > > > > This is how I think we should move forward with this:
> > > > > > > > >
> > > > > > > > > 1 - as a group, decide on all the packages for both std v=
l
> > > and
> > > > > > > > > soho before we start
> > > > > > > > > 2 - 1 person designated to build the bare minimum
> > > base(a/ap/d/l/k
> > > > > > > > > source trees) - probably either myself or Uel or anyone
> > > that wants
> > > > to take
> > > > > > > > > ownership of this task - all base build scripts need to b=
e
> > >
> > > > corrected for
> > > > > > > > > arch,flags,etc
> > > > > > > > > 3 - once the base is built, each developer is given a
> > > source tree
> > > > > > > > > or trees and they work on those on top of the base(
> > > vlbase.tgz).eg.
> > > > > > > > > kde,xap,etc - all packages must be built on a virgin base
> > > except
> > > > for soho -
> > > > > > > > > 2 groups are needed here - std and soho and there will be
> > > some
> > > > duplication
> > > > > > > > > as std and soho should be treated as separate distros -
> > > all build
> > > > scripts
> > > > > > > > > need to corrected for arch,flags,etc
> > > > > > > > > 4 - we need to come up with SlackBuilds for the packages
> > > we
> > > > > > > > > include that aren't in slack and split this up depending
> > > on how
> > > > many pkgs
> > > > > > > > > there are
> > > > > > > > > 5 - upload all the built packages to the respective trees
> > > and each
> > > > > > > > > of us install them for testing.
> > > > > > > > > 6 - once testing is completed, we package these up for th=
e
> > > cd into
> > > > > > > > > vl-base.tgz,vl-std.tgz , and vl-soho.tgz - all X and
> > > related
> > > > > > > > > packages should reside in vl-std.tgz and vl-soho.tgz so
> > > that SOHO
> > > > > > > > > can be KDE only and have all packages built for it using
> > > kde as a
> > > > dep.
> > > > > > > > > 7 - release beta std and soho at the same time
> > > > > > > > > 8 - set a beta test schedule of 2 weeks
> > > > > > > > > 9 - fix and release rc
> > > > > > > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and
> > > 10 until
> > > > > > > > > stable.
> > > > > > > > > 11 - release final std and soho at the same time.
> > > > > > > > > 12 - designate a dev for each versions - std and soho -
> > > whose
> > > > > > > > > primary responsibility will be security patching
> > > > > > > > > 13 - start working on extra packages for the repo
> > > > > > > > > 14 - once there is a large repo of apps available, start
> > > the next
> > > > > > > > > cycle at step 1
> > > > > > > > >
> > > > > > > > > Let me know what you all think.  Having this process more
> > > > > > > > > organized and coordinated will allow us to work quicker
> > > and more
> > > > efficiently
> > > > > > > > > giving us more time to create the extra app repo that is
> > > needed to
> > > > take VL
> > > > > > > > > to the next level. That way when Robert becomes rich from
> > > VL, he
> > > > will share
> > > > > > > > > with all of us - lol.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >  Tony
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > -------------------------------------------------------
> > >
> > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > language
> > > that extends applications into web and mobile media. Attend the live
> > > webcast
> > > and join the prime developer group breaking into this new coding
> > > territory!
> > > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642=
<http://sel.as-us.falkag.net/sel?cmdlnk&kid%110944&bid$1720&dat%121642>
> > > _______________________________________________
> > > Vectorlinux-devel mailing list
> > > Vec...@li...
> > > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> > >
> > >
> > >
> >
> >
>

Re: [Vectorlinux-devel] Re: Slack Builds and VL - my suggestions

[Jose J. R. <jo...@gm...>]

On 4/21/06, Tony Brijeski <tb...@gm...> wrote:
> I will get cracking this weekend and let you all know how I make out.
>
>
>
> On 4/21/06, uel archuletta <ue...@gm...> wrote:
> >
> > Tony,
> > The package lists are fially finished
> > they are in vectors folder on the ftp
> > let us know if you need anything else.
> >
> > Thanks,
> >
> > Uel
> >
> >
> >
> > On 4/13/06, Tony Brijeski <tb...@gm...> wrote:
> > >
> > > I'm still waiting for everyone to decide on a package list - complete=
.
> Once we have that, I will build the base.
> > >
> > >
> > >
> > >
> > >
> > > On 4/14/06, uel archuletta < ue...@gm... > wrote:
> > > >
> > > > Tony,
> > > > How is everything going with the "Base" so far?
> > > > just thought I would check in and get an update.
> > > >


Just in case, you do realise that the versions on Vec's list are not
necessarilly correct? They are mostly a package name guideline. Quick
examples are the kernel and udev...

Also, there are some IMO unnecessary packages (for VL6 base) to point
out from the package lists (correct me if I'm wrong, they might be
necessary for KDE or whatever, as some of the others I previously
pointed out to Vec were):

X-TK:
- gaim
- gftp
- firefox
- xchat
- xmms

NET:
- dhcp
- imapd
- metamail

LIB:
- pilot-link
- are both db42 and db44 required?

A:
- hotplug?

Regards,
Joe1962

Re: [Vectorlinux-devel] Re: Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

Version numbers will be stripped.  I only need the package name up to the
version number.  The build script will be similar to the one I made before =
I
had to take my hiatus away from VL but I believe only Robert has that.

We will need to track any modifications to the base for customized things
very carefully and make a vl-custom package that we can in the future just
install right after the base is automatically built.

The goal of all of this is to allow us to eventually be separate from Slack
but still remain compatible to a certain degree so slack apps will work on
VL even after we are not using their base.  The second goal is to make it s=
o
that a base can be automatically built on its own without a lot of user
intervention which will result in a very clean standard base.  The third
goal will come as a result of the previous 2 in that it will free everyone
up to build as many packages as we can.



On 4/21/06, Jose J. Rodriguez <jo...@gm...> wrote:
>
> On 4/21/06, Tony Brijeski <tb...@gm...> wrote:
> > I will get cracking this weekend and let you all know how I make out.
> >
> >
> >
> > On 4/21/06, uel archuletta <ue...@gm...> wrote:
> > >
> > > Tony,
> > > The package lists are fially finished
> > > they are in vectors folder on the ftp
> > > let us know if you need anything else.
> > >
> > > Thanks,
> > >
> > > Uel
> > >
> > >
> > >
> > > On 4/13/06, Tony Brijeski <tb...@gm...> wrote:
> > > >
> > > > I'm still waiting for everyone to decide on a package list -
> complete.
> > Once we have that, I will build the base.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 4/14/06, uel archuletta < ue...@gm... > wrote:
> > > > >
> > > > > Tony,
> > > > > How is everything going with the "Base" so far?
> > > > > just thought I would check in and get an update.
> > > > >
>
>
> Just in case, you do realise that the versions on Vec's list are not
> necessarilly correct? They are mostly a package name guideline. Quick
> examples are the kernel and udev...
>
> Also, there are some IMO unnecessary packages (for VL6 base) to point
> out from the package lists (correct me if I'm wrong, they might be
> necessary for KDE or whatever, as some of the others I previously
> pointed out to Vec were):
>
> X-TK:
> - gaim
> - gftp
> - firefox
> - xchat
> - xmms
>
> NET:
> - dhcp
> - imapd
> - metamail
>
> LIB:
> - pilot-link
> - are both db42 and db44 required?
>
> A:
> - hotplug?
>
> Regards,
> Joe1962
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[uel a. <ue...@gm...>]

Tony,

I am wondering how everything is going. I know from my own experience life
gets in the way sometimes, so i am just checking to see if you have any
progress on the base.

Thanks,
Uel

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

I let Robert know about things a little while ago.

The end of April and all of May was a write-off for me due to work
committments.  I was busy setting up a new head office for one of our
divisions of the company.  Lots of long hours and weekends but it is finally
over!!!!!

I will try to have the build system finished within the next 2 weeks and
have it tested a week after that.  I want to make sure everything works
smoothly so it can be used by anyone and everyone to build the vl base.

Regards,
Tony



On 6/5/06, uel archuletta <ue...@gm...> wrote:
>
> Tony,
>
> I am wondering how everything is going. I know from my own experience life
> gets in the way sometimes, so i am just checking to see if you have any
> progress on the base.
>
> Thanks,
> Uel
>
>
>
>
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>
>
>