vectorlinux-devel — Vector Linux developer's list

[Vectorlinux-devel] AutoPartitioning

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

As most everyone by now knows We are working on a new installer.
One of the new features we would like to add is the ability to
autopartition.
If anyone has any suggestions or can contribute code it would be
appreciated.
We have at least 2 scenarios to work from.
1 being take over HD and use whole thing
2 Use free space on HD
We thought if user wants to use free space on windows partition we would
make them do that themselves and put their data loss in their hands.

Our objective as we see it so far is: how to calculate the space to allocat=
e
for / /home and swapspace taking into account amount of space available,
minimum safe size for /, and so on

Thanks,
Uel Archuletta

[Vectorlinux-devel] Re[2]: [Vectorlinux-devel]

[Jason W. <woo...@ja...>]

Hi guys,

> We do need a pasture directory. Since I'll be doing primary work on
> maintaining the repo, I want to have a place to move the old stuff so
> that it doesn't show up in slapt-get/gslapt, espcially when we've
> updated core packages due to security fixes, etc. We have to avoid
> duplicate versions and/or duplicate packages.
> 
> I can also argue for an unsupported directory, in that it's a place
> where we put software that is no longer being supported by its author,
> etc.

I just wanted to chime in here... and this is somewhat based on the Debian approach:

vl-release - directory for released versions of vector... would be tagged vl-5.5 or some such
vl-security - directory for security updates for the release, tagged vl-5.5-security 

So stable users get two default package sources, the release and security sources.  That way,
the release directory is unaffected by any changes, and security updates are in a specific
location that is easy to check for tools and users alike.  

vl-current - agreed
vl-pasture - this could serve for unsupported packages as well


take care,
jason

--
Jason Woodward
woo...@ja...

Re: [Vectorlinux-devel] "Unstable" repository

[John B <joh...@gm...>]

We do need a pasture directory. Since I'll be doing primary work on
maintaining the repo, I want to have a place to move the old stuff so
that it doesn't show up in slapt-get/gslapt, espcially when we've
updated core packages due to security fixes, etc. We have to avoid
duplicate versions and/or duplicate packages.

I can also argue for an unsupported directory, in that it's a place
where we put software that is no longer being supported by its author,
etc.

While we're talking about packaging standards, we absolutely need to
use dependencies that are part of the core unless there is a
compelling reason to use a different version. I speak mainly of gtk,
though this would also apply to qt, wxwidgets, etc. I don't want to
see us have multiple versions of gtk2 or qt in the main package tree.

One additional comment on the "current" directory - we should take the
same position that Patrick V takes with the slackware-current tree.
Besides Joe's comment about updated versions of apps and libs being in
there (i.e., feature enhancements), it should also be seen as the
place where development work on future versions of VL takes place.
Therefore, while the stuff in there should work, we should make a
strong disclaimer that anything in veclinux-current may break your
box. I envision "current" as a directory that would eventually become
frozen to a specific release.

FWIW,
John

On 4/25/06, uel archuletta <ue...@gm...> wrote:
> I agree with everything, But I read it a little diferently so I would
> propose these changes
>
>
> -testing: every package should go here till deemed worthy by a team of
> official package testers, then sent to it's rightful place.
>
> -stable: (or official): only for the specific versions of apps/libs in th=
e
> release or their security/bug fixes
>
>
> -extra: (or unofficial): for libs / apps not included in the distro.
>
> -current: for updated versions of libs / apps included in the distro,
> but not simple security /bug fixes, rather feature updates.
>
> -unstable: for beta and rc apps.
>
> I would also volunteer for testing packages as I have room to keep a clea=
n
> box to install them onto.
>
> Thanks
> Uel
>
>
>
>
> On 4/25/06, Jose J. Rodriguez <jo...@gm...> wrote:
> > I'd like to awaken this thread because we need to come to a decision
> > regarding the structure of the VL6 repo. VL6 will be breaking new
> > ground for us in the packaging department, as all packages that make
> > up the distro will be available on the repo, to allow for rolling back
> > upgrades, etc. Also, we intend to make dist-upgrade possible, as
> > discussed before. So we need to get the repo structure just right.
> > Also, we need to think about separating the repos for Standard and
> > SOHO, or (probably impossible) making the packages installable for
> > both. Looking at previous posts, I'd like to sum up a possible repo
> > structure and ask for comments/discussions.
> >
> > -testing: every package should go here till deemed worthy by a team of
> > official package testers, then sent to it's rightful place.
> >
> > -stable: (or official): for bug fixes or security updates of the libs
> > / apps included on the distro.
> >
> > -extra: (or unofficial): for libs / apps not included in the distro.
> >
> > -current: for updated versions of libs / apps included in the distro,
> > but not simple security /bug fixes, rather feature updates.
> >
> > -unstable: for beta and rc apps, whether included in the distro or not.
> >
> > -pasture and unsupported have been proposed, but so far I don't see
> > the use for them within the timeline of a VL version, your views on
> > this?
> >
> > Regards,
> > Joe1962
> >
> >
> > -------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, securit=
y?
> > 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 Geron=
imo
> >
> 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] "Unstable" repository

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

I agree with everything, But I read it a little diferently so I would
propose these changes

-testing: every package should go here till deemed worthy by a team of
official package testers, then sent to it's rightful place.

-stable: (or official): only for the specific versions of apps/libs in the
release or their security/bug fixes

-extra: (or unofficial): for libs / apps not included in the distro.

-current: for updated versions of libs / apps included in the distro,
but not simple security /bug fixes, rather feature updates.

-unstable: for beta and rc apps.

I would also volunteer for testing packages as I have room to keep a clean
box to install them onto.

Thanks
Uel



On 4/25/06, Jose J. Rodriguez <jo...@gm...> wrote:
>
> I'd like to awaken this thread because we need to come to a decision
> regarding the structure of the VL6 repo. VL6 will be breaking new
> ground for us in the packaging department, as all packages that make
> up the distro will be available on the repo, to allow for rolling back
> upgrades, etc. Also, we intend to make dist-upgrade possible, as
> discussed before. So we need to get the repo structure just right.
> Also, we need to think about separating the repos for Standard and
> SOHO, or (probably impossible) making the packages installable for
> both. Looking at previous posts, I'd like to sum up a possible repo
> structure and ask for comments/discussions.
>
> -testing: every package should go here till deemed worthy by a team of
> official package testers, then sent to it's rightful place.
>
> -stable: (or official): for bug fixes or security updates of the libs
> / apps included on the distro.
>
> -extra: (or unofficial): for libs / apps not included in the distro.
>
> -current: for updated versions of libs / apps included in the distro,
> but not simple security /bug fixes, rather feature updates.
>
> -unstable: for beta and rc apps, whether included in the distro or not.
>
> -pasture and unsupported have been proposed, but so far I don't see
> the use for them within the timeline of a VL version, your views on
> this?
>
> 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] "Unstable" repository

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

I'd like to awaken this thread because we need to come to a decision
regarding the structure of the VL6 repo. VL6 will be breaking new
ground for us in the packaging department, as all packages that make
up the distro will be available on the repo, to allow for rolling back
upgrades, etc. Also, we intend to make dist-upgrade possible, as
discussed before. So we need to get the repo structure just right.
Also, we need to think about separating the repos for Standard and
SOHO, or (probably impossible) making the packages installable for
both. Looking at previous posts, I'd like to sum up a possible repo
structure and ask for comments/discussions.

-testing: every package should go here till deemed worthy by a team of
official package testers, then sent to it's rightful place.

-stable: (or official): for bug fixes or security updates of the libs
/ apps included on the distro.

-extra: (or unofficial): for libs / apps not included in the distro.

-current: for updated versions of libs / apps included in the distro,
but not simple security /bug fixes, rather feature updates.

-unstable: for beta and rc apps, whether included in the distro or not.

-pasture and unsupported have been proposed, but so far I don't see
the use for them within the timeline of a VL version, your views on
this?

Regards,
Joe1962

[Vectorlinux-devel] Xpdf package

[Oleg <ya...@gm...>]

Hi All!

I wonder, who builds Xpdf for VL? I would like to add some localizations files 
(for 1-byte encodings: Arabic, Cyrillic, Greek, Hebrew, Latin2, Thai, 
Turkish). Of course I can package them separately, but this stuff takes as 
small as ~5K in packed form and ~11K in unpacked form, so I believe it worth 
including to the main xpdf package. 
I am also going to create separate packages for Chinese/simplified, 
Chinese/traditional, Japanese and Korean - they will take from 450K to 800K 
(packed).
So, may I take this package or should I discuss this with somebody?

Regards,
YaP

[Vectorlinux-devel] I think kvpnc is packaged with wrong dependency

[Oleg <ya...@gm...>]

slack-required contains 
openoffice >= 2.0
Please report to packager
I have provided the patch for makeslapt which makes it unnecessary to have 
a "clean box" to build packages:
http://www.vectorlinux.com/forum1/index.php?topic=10123.0

Re: [Vectorlinux-devel] Some Feedback about SOHO

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

I guess what I dont understand is
1) who's path gets loaded when I use "su"??
2) how do I add something to that path permenantly?


[uel@vector~]$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/opt/bin:/usr/local/games:/opt/=
java/bin:/opt/java/jre/bin:/opt/kde/bin:/opt/xfce4/bin:.:/usr/X11R6/bin:/op=
t/xfce4/bin
[uel@vector~]$ su -
Password:
[root@vector~]# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/opt/bin:/usr/local/games:/usr/=
local/sbin:/usr/sbin:/sbin:/opt/java/bin:/opt/java/jre/bin:/opt/kde/bin:/op=
t/xfce4/bin:/usr/X11R6/bin:/opt/xfce4/bin
[root@vector~]# exit
logout
[uel@vector~]$ su
Password:
[root@vector/home/uel]# echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin=
:/opt/xfce4/bin


I thought I better look for the answer myself before I posted this, and
after I found it I thought I would pass it along
just incase anyone else needs it

       The  current  environment is passed to the new shell.  The
       value of $PATH is reset to /bin:/usr/bin for normal users,
       or /sbin:/bin:/usr/sbin:/usr/bin for the super user.  This
       may be changed with the ENV_PATH  and  ENV_SUPATH  defini=AD
       tions in /etc/login.defs.


Thanks
Uel


On 4/21/06, Jose J. Rodriguez <jo...@gm...> wrote:
>
> On 4/21/06, uel archuletta <ue...@gm...> wrote:
> > I think its a good Idea, But I have that in my .bashrc and it doesnt
> help me
> > :(
> > I even get this in a new terminal
> > non-network local connections being added to access control list
> > [uel@vector~]$ su -
> > Password:
> >  [root@vector~]# firefox
> >
> > (firefox-bin:18773): Gtk-WARNING **: cannot open display:
> > [root@vector~]# exit
> > logout
> >
> > firefox works if i just use "su" but kate and kwrite don't. weird
> > I know I dont get roots path without the - but I thouht I had the users=
?
> >
> >
> > [uel@vector~]$ su
> > Password:
> > [root@vector/home/uel]# firefox
> > [root@vector/home/uel]# kate
> > bash: kate: command not found
> > [root@vector/home/uel]# kwrite
> > bash: kwrite: command not found
> > [root@vector /home/uel]#
> >
> >
> >
> >
>
> This fix has worked well for me too, since it was posted. Uel, your
> problem with kate, kedit and company is another little "bug". The
> environment path is different for root and users. Add /opt/kde/bin to
> the root path. Your other problem with "su -" is funny, as it's
> probably because this variation of su works like this:
>
> "The optional argument - may be used to provide an environment
> similiar to what the user would expect had the user logged in
> directly"
>
> so maybe as the fix is not in the root user's environment.......
>
> 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] 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] Some Feedback about SOHO

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

On 4/21/06, uel archuletta <ue...@gm...> wrote:
> I think its a good Idea, But I have that in my .bashrc and it doesnt help=
 me
> :(
> I even get this in a new terminal
> non-network local connections being added to access control list
> [uel@vector~]$ su -
> Password:
>  [root@vector~]# firefox
>
> (firefox-bin:18773): Gtk-WARNING **: cannot open display:
> [root@vector~]# exit
> logout
>
> firefox works if i just use "su" but kate and kwrite don't. weird
> I know I dont get roots path without the - but I thouht I had the users?
>
>
> [uel@vector~]$ su
> Password:
> [root@vector/home/uel]# firefox
> [root@vector/home/uel]# kate
> bash: kate: command not found
> [root@vector/home/uel]# kwrite
> bash: kwrite: command not found
> [root@vector /home/uel]#
>
>
>
>

This fix has worked well for me too, since it was posted. Uel, your
problem with kate, kedit and company is another little "bug". The
environment path is different for root and users. Add /opt/kde/bin to
the root path. Your other problem with "su -" is funny, as it's
probably because this variation of su works like this:

"The optional argument - may be used to provide an environment
similiar to what the user would expect had the user logged in
directly"

so maybe as the fix is not in the root user's environment.......

Regards,
Joe1962

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] Some Feedback about SOHO

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

I think its a good Idea, But I have that in my .bashrc and it doesnt help m=
e
:(
I even get this in a new terminal
non-network local connections being added to access control list
[uel@vector~]$ su -
Password:
[root@vector~]# firefox

(firefox-bin:18773): Gtk-WARNING **: cannot open display:
[root@vector~]# exit
logout

firefox works if i just use "su" but kate and kwrite don't. weird
I know I dont get roots path without the - but I thouht I had the users?


[uel@vector~]$ su
Password:
[root@vector/home/uel]# firefox
[root@vector/home/uel]# kate
bash: kate: command not found
[root@vector/home/uel]# kwrite
bash: kwrite: command not found
[root@vector/home/uel]#




On 4/21/06, John B <joh...@gm...> wrote:
>
> What we may be able to do regarding #5 in Bustere's annoyances is to
> add a change to the .bashrc file in /etc/skel that was proposed by
> Vanger in the forums:
>
> /usr/X11R6/bin/xhost local:root
>
> I've had this change in the .bashrc file in my home directory, and I
> don't run into an issue with opening GUI apps after su'ing to root.
>
> Assuming that Vec is comfortable with making this tweak, we just have
> to make sure that the change does not propagate to the .bashrc file
> for root. What say y'all?
>
> Best,
> John
>
> On 4/21/06, Sriram Durbha <sri...@gm...> wrote:
> > great and concise feed back.  point 5 in his annoyances list has a
> solution
> > in the forums. a lot of us suffered with this initially.  it has to do
> with
> > the kdesu stuff.. i will dig out the corresponding post and update
> again. or
> > pm the person on the forum.
> > cheers
> > ram
> >
> >
> > On 4/20/06, John B <joh...@gm...> wrote:
> > >
> >  Guys,
> >
> > I received a PM from Bustere, who has recently joined the forums. I
> > thought I would share it with you, since some good points are made in
> > it.
> >
> > Best,
> > John
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > You work really hard on the forums!!!! Wrote to you instead of
> > posting. Maybe you can make use of my experiences. No need to reply if
> > you're busy.
> >
> > What I really like about SOHO:
> > 1. Great LiveCD
> > 2. Multimedia package saves lots of time
> > 3. Seems quick, even in KDE
> > 4. Friendly forums
> > 5. Has a Canadian source (Guess where I live)
> > 6. Attractive defaults
> > 7. Gslapt works easily and quickly
> > 8. Many things set up automatically with the install
> > 9. You can put lilo on a floppy
> > 10. You can boot into root
> >
> > What I accept as OK
> > 1. An installer that seems "old fashioned"
> > 2. Installing with a separate disc from the LiveCD (This will probably
> > change)
> > 3. Lilo is used instead of my preferred GRUB
> >
> > What I found annoying
> > 1. There was no indication that the firewall would negate the
> > automatic finding of shares
> > 2 Streaming of mpg and avi files from a different computer seems
> > awkward to set up, and I haven't succeeded yet
> > 3 The reference to scsi drives during the install, even though the 2.6
> > kernel doesn't need this, could be handled better
> > 4. 3d acceleration, which has been pretty well automatic for a few
> > years with my ati rage128 pro card, is proving elusive
> > 5. When I su to root I can't get kate or kwrite to open from the
> terminal
> >
> > If I think of more things I'd be happy to write if it helps. Vector
> > seems like a great idea, and I feel a certain amount of discomfort
> > when I see it dropping to 21st position on Distrowatch (Not
> > conclusive, but an indicator of some loss of interest.) Appreciate
> > your help, and I'll keep working on my SOHO, but PCLinuxOS and Mepis
> > are tough competition, except Vector is FAST! And maybe that's it
> > niche.
> >
> >
> > -------------------------------------------------------
> > 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
> Geronimo
> > 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
> >
> >
>
>
> -------------------------------------------------------
> 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] Some Feedback about SOHO

[John B <joh...@gm...>]

What we may be able to do regarding #5 in Bustere's annoyances is to
add a change to the .bashrc file in /etc/skel that was proposed by
Vanger in the forums:

/usr/X11R6/bin/xhost local:root

I've had this change in the .bashrc file in my home directory, and I
don't run into an issue with opening GUI apps after su'ing to root.

Assuming that Vec is comfortable with making this tweak, we just have
to make sure that the change does not propagate to the .bashrc file
for root. What say y'all?

Best,
John

On 4/21/06, Sriram Durbha <sri...@gm...> wrote:
> great and concise feed back.  point 5 in his annoyances list has a soluti=
on
> in the forums. a lot of us suffered with this initially.  it has to do wi=
th
> the kdesu stuff.. i will dig out the corresponding post and update again.=
 or
> pm the person on the forum.
> cheers
> ram
>
>
> On 4/20/06, John B <joh...@gm...> wrote:
> >
>  Guys,
>
> I received a PM from Bustere, who has recently joined the forums. I
> thought I would share it with you, since some good points are made in
> it.
>
> Best,
> John
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> You work really hard on the forums!!!! Wrote to you instead of
> posting. Maybe you can make use of my experiences. No need to reply if
> you're busy.
>
> What I really like about SOHO:
> 1. Great LiveCD
> 2. Multimedia package saves lots of time
> 3. Seems quick, even in KDE
> 4. Friendly forums
> 5. Has a Canadian source (Guess where I live)
> 6. Attractive defaults
> 7. Gslapt works easily and quickly
> 8. Many things set up automatically with the install
> 9. You can put lilo on a floppy
> 10. You can boot into root
>
> What I accept as OK
> 1. An installer that seems "old fashioned"
> 2. Installing with a separate disc from the LiveCD (This will probably
> change)
> 3. Lilo is used instead of my preferred GRUB
>
> What I found annoying
> 1. There was no indication that the firewall would negate the
> automatic finding of shares
> 2 Streaming of mpg and avi files from a different computer seems
> awkward to set up, and I haven't succeeded yet
> 3 The reference to scsi drives during the install, even though the 2.6
> kernel doesn't need this, could be handled better
> 4. 3d acceleration, which has been pretty well automatic for a few
> years with my ati rage128 pro card, is proving elusive
> 5. When I su to root I can't get kate or kwrite to open from the terminal
>
> If I think of more things I'd be happy to write if it helps. Vector
> seems like a great idea, and I feel a certain amount of discomfort
> when I see it dropping to 21st position on Distrowatch (Not
> conclusive, but an indicator of some loss of interest.) Appreciate
> your help, and I'll keep working on my SOHO, but PCLinuxOS and Mepis
> are tough competition, except Vector is FAST! And maybe that's it
> niche.
>
>
> -------------------------------------------------------
> 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] Some Feedback about SOHO

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

great and concise feed back.  point 5 in his annoyances list has a solution
in the forums. a lot of us suffered with this initially.  it has to do with
the kdesu stuff.. i will dig out the corresponding post and update again. o=
r
pm the person on the forum.
cheers
ram

On 4/20/06, John B <joh...@gm...> wrote:
>
> Guys,
>
> I received a PM from Bustere, who has recently joined the forums. I
> thought I would share it with you, since some good points are made in
> it.
>
> Best,
> John
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> You work really hard on the forums!!!! Wrote to you instead of
> posting. Maybe you can make use of my experiences. No need to reply if
> you're busy.
>
> What I really like about SOHO:
> 1. Great LiveCD
> 2. Multimedia package saves lots of time
> 3. Seems quick, even in KDE
> 4. Friendly forums
> 5. Has a Canadian source (Guess where I live)
> 6. Attractive defaults
> 7. Gslapt works easily and quickly
> 8. Many things set up automatically with the install
> 9. You can put lilo on a floppy
> 10. You can boot into root
>
> What I accept as OK
> 1. An installer that seems "old fashioned"
> 2. Installing with a separate disc from the LiveCD (This will probably
> change)
> 3. Lilo is used instead of my preferred GRUB
>
> What I found annoying
> 1. There was no indication that the firewall would negate the
> automatic finding of shares
> 2 Streaming of mpg and avi files from a different computer seems
> awkward to set up, and I haven't succeeded yet
> 3 The reference to scsi drives during the install, even though the 2.6
> kernel doesn't need this, could be handled better
> 4. 3d acceleration, which has been pretty well automatic for a few
> years with my ati rage128 pro card, is proving elusive
> 5. When I su to root I can't get kate or kwrite to open from the terminal
>
> If I think of more things I'd be happy to write if it helps. Vector
> seems like a great idea, and I feel a certain amount of discomfort
> when I see it dropping to 21st position on Distrowatch (Not
> conclusive, but an indicator of some loss of interest.) Appreciate
> your help, and I'll keep working on my SOHO, but PCLinuxOS and Mepis
> are tough competition, except Vector is FAST! And maybe that's it
> niche.
>
>
> -------------------------------------------------------
> 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] 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

[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
> >
> >
>

[Vectorlinux-devel] Some Feedback about SOHO

[John B <joh...@gm...>]

Guys,

I received a PM from Bustere, who has recently joined the forums. I
thought I would share it with you, since some good points are made in
it.

Best,
John

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
You work really hard on the forums!!!! Wrote to you instead of
posting. Maybe you can make use of my experiences. No need to reply if
you're busy.

What I really like about SOHO:
1. Great LiveCD
2. Multimedia package saves lots of time
3. Seems quick, even in KDE
4. Friendly forums
5. Has a Canadian source (Guess where I live)
6. Attractive defaults
7. Gslapt works easily and quickly
8. Many things set up automatically with the install
9. You can put lilo on a floppy
10. You can boot into root

What I accept as OK
1. An installer that seems "old fashioned"
2. Installing with a separate disc from the LiveCD (This will probably chan=
ge)
3. Lilo is used instead of my preferred GRUB

What I found annoying
1. There was no indication that the firewall would negate the
automatic finding of shares
2 Streaming of mpg and avi files from a different computer seems
awkward to set up, and I haven't succeeded yet
3 The reference to scsi drives during the install, even though the 2.6
kernel doesn't need this, could be handled better
4. 3d acceleration, which has been pretty well automatic for a few
years with my ati rage128 pro card, is proving elusive
5. When I su to root I can't get kate or kwrite to open from the terminal

If I think of more things I'd be happy to write if it helps. Vector
seems like a great idea, and I feel a certain amount of discomfort
when I see it dropping to 21st position on Distrowatch (Not
conclusive, but an indicator of some loss of interest.) Appreciate
your help, and I'll keep working on my SOHO, but PCLinuxOS and Mepis
are tough competition, except Vector is FAST! And maybe that's it
niche.

Re: [Vectorlinux-devel] More Forum Antics?

[<nig...@ju...>]

John,

I would say some paranoia is in order. It is about 3 pm where I am and t=
he forum has been down all day. It was also down most of yesterday. Keep=
ing the forum running should be high on the list of priorities.

Roy


>>>> John B wrote: <<<<
Howdy, folks!

As I type this e-mail, it is lunchtime US Eastern Daylight Time. I
have attempted to access the VL forum several times during my lunch
break. However, with every attempt I've been met with the following
error message on the home page:

Connection Problems
Sorry, SMF was unable to connect to the database. This may be caused
by the server being busy. Please try again later.

I wonder whether some sort of denial-of-service attack has been
launched on our forum or whether there is some sort of bandwidth cap?
I also wonder whether I'm being too paranoid about this stuff. ;X

Best,
John


________________________________________________________________________=

Try Juno Platinum for Free! Then, only $9.95/month!
Unlimited Internet Access with 1GB of Email Storage.
Visit http://www.juno.com/value to sign up today!

Re: [Vectorlinux-devel] More Forum Antics?

[Robert L. <vec...@ya...>]

Seems the mailing list program has been compromised by
hackers so they took the whole site down till we find
a solution. By mailing list I don't mean this one but
the one on the vector site. Sorry for the hassle Im in
contact with madtux.org and waiting for there reply.
thanks,
Robert

--- John B <joh...@gm...> wrote:

> Howdy, folks!
> 
> As I type this e-mail, it is lunchtime US Eastern
> Daylight Time. I
> have attempted to access the VL forum several times
> during my lunch
> break. However, with every attempt I've been met
> with the following
> error message on the home page:
> 
> Connection Problems
> Sorry, SMF was unable to connect to the database.
> This may be caused
> by the server being busy. Please try again later.
> 
> I wonder whether some sort of denial-of-service
> attack has been
> launched on our forum or whether there is some sort
> of bandwidth cap?
> I also wonder whether I'm being too paranoid about
> this stuff. ;X
> 
> Best,
> John
> 
> 
>
-------------------------------------------------------
> 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?cmd=lnk&kid0944&bid$1720&dat1642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
>
https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> 


Robert Lange
vec...@ya...
http://www.vectorlinux.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Vectorlinux-devel] More Forum Antics?

[John B <joh...@gm...>]

Howdy, folks!

As I type this e-mail, it is lunchtime US Eastern Daylight Time. I
have attempted to access the VL forum several times during my lunch
break. However, with every attempt I've been met with the following
error message on the home page:

Connection Problems
Sorry, SMF was unable to connect to the database. This may be caused
by the server being busy. Please try again later.

I wonder whether some sort of denial-of-service attack has been
launched on our forum or whether there is some sort of bandwidth cap?
I also wonder whether I'm being too paranoid about this stuff. ;X

Best,
John

Re: [Vectorlinux-devel] Forum Down

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

On 4/16/06, John B <joh...@gm...> wrote:
> Hi, Guys!
>
> I noticed earlier on 16 April, around 1 PM EDT, that the VL forum was
> down. As of the time I'm sending this e-mail to the VL developers'
> list, the forum is still down. I wonder whether the forum's code or
> the php code was hacked into.
>

Noticed that too, John, but it's back now.

Regards,
Joe1962

[Vectorlinux-devel] Forum Down

[John B <joh...@gm...>]

Hi, Guys!

I noticed earlier on 16 April, around 1 PM EDT, that the VL forum was
down. As of the time I'm sending this e-mail to the VL developers'
list, the forum is still down. I wonder whether the forum's code or
the php code was hacked into.

Regards,
John B

[Vectorlinux-devel] re: new documentation...

[Larry G. <lgg...@un...>]

nightflier: your typos have been noted. Thanks!

lagagnon

Re: [Vectorlinux-devel] new VL5 documentation redy for checking

[<nig...@ju...>]

Hi, All.

This is my first post to the group. I am "nightflier" from the forum.

I'm a hobbyist who like to play with computers. My skills do not include=
 coding and deep technical knowledge, I'm more of an "end user tester". =
=


I was reading through the documentation and wanted to clarify some word =
spelling. Maybe these are just British English vs. American English.

Main page: VL is referred to as "sleak". Should that be "sleek"?
DeLuxe: Generousity (generosity?) Hardisk (hard disk?)
Donations: Huggs (hugs?)
SOHO: Maintanance (maintenance?) Harddisk (hard disk?)

Roy Stefanussen


________________________________________________________________________=

Try Juno Platinum for Free! Then, only $9.95/month!
Unlimited Internet Access with 1GB of Email Storage.
Visit http://www.juno.com/value to sign up today!

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
>
>