You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
(40) |
Apr
(76) |
May
(31) |
Jun
(39) |
Jul
(44) |
Aug
(87) |
Sep
(32) |
Oct
(23) |
Nov
(36) |
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(49) |
Sep
(14) |
Oct
|
Nov
|
Dec
(1) |
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(63) |
Aug
(95) |
Sep
(39) |
Oct
(61) |
Nov
(75) |
Dec
(118) |
2009 |
Jan
(25) |
Feb
(37) |
Mar
(20) |
Apr
(15) |
May
(14) |
Jun
(48) |
Jul
(82) |
Aug
(160) |
Sep
(94) |
Oct
(55) |
Nov
(59) |
Dec
(4) |
2010 |
Jan
(5) |
Feb
(17) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: uel a. <ue...@gm...> - 2006-04-14 02:44:20
|
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 > |
From: Jose J. R. <jo...@gm...> - 2006-04-12 13:40:51
|
On 4/12/06, Jose J. Rodriguez <jo...@gm...> wrote: > The new kernel 2.6.16 + udev 0.88 stuff causes a problem in D4X > (probably in other apps, too), where there is no sound and an error of > missing /dev/dsp is given. Maybe this device needs to be preset in > /lib/udev/devices? Or is there another way to handle this? > Well, possibly answering my own question. Found this in an udev primer: ---------------------------------------------------------------------------= --- Mixer/Midi/Dsp Devices: Some people, including me, report that the /dev/mixer isn't being created or /dev/midi or /dev/dsp. The problem is not udev. If you compiled your kernel with them as modules you have to load them in /etc/modules.autoload.d/kernel-2.6. So if those devices aren't being created add: snd_pcm_oss & snd_seq_oss to kernel-2.6 file. The snd_pcm_oss will load snd_mixer_oss itself. snd_mixer_oss alias is /dev/mixer snd_pcm_oss alias is /dev/dsp snd_seq_oss alias is /dev/midi ---------------------------------------------------------------------------= --- So those need to be loaded manually in rc.modules still? Regards, Joe1962 |
From: Jose J. R. <jo...@gm...> - 2006-04-12 13:21:28
|
The new kernel 2.6.16 + udev 0.88 stuff causes a problem in D4X (probably in other apps, too), where there is no sound and an error of missing /dev/dsp is given. Maybe this device needs to be preset in /lib/udev/devices? Or is there another way to handle this? Regards, Joe1962 |
From: Hanumizzle <han...@gm...> - 2006-04-10 23:21:36
|
On 4/10/06, Larry Gagnon <lgg...@un...> wrote: > I have completed an edit of the VL5 documentation as described in a > previous post to this forum. I would appreciate as many developers > having a look at it as possible. Any constructive criticism, edits, > busts, suggested changes most welcome. > > The docs are available at the upload site: > http://distro.ibiblio.org/pub/linux/distributions/vectorlinux/upload/laga= gnon/new_vl5_docs.tar.bz2 > > I will leave them there for 2 weeks, after that and after any more > editing I think we should publish them to the website and make an > announcement. > > Larry (lagagnon) Will give it a look. -- "For the time being anyway, until the age of Terminator." -- Yukihiro 'matz' Matsumoto |
From: Hanumizzle <han...@gm...> - 2006-04-10 23:20:31
|
On 4/10/06, Sriram Durbha <sri...@gm...> wrote: > hanum, > can this also use the same user login table from the forum ? I haven't the expertise, but see: http://twiki.org/cgi-bin/view/TWiki04/TWikiUserAuthentication for pointers. I imagine so. Jai -- "For the time being anyway, until the age of Terminator." -- Yukihiro 'matz' Matsumoto |
From: Sriram D. <sri...@gm...> - 2006-04-10 23:13:41
|
hanum, can this also use the same user login table from the forum ? cheers ram On 4/10/06, Hanumizzle <han...@gm...> wrote: > > On 4/10/06, Sriram Durbha <sri...@gm...> wrote: > > guyz, i opened a bug in the sf bugtracker to track this.. But soon > realised > > that it is a big waste of time.. a wiki is much better. bugtracker is > also > > ok. but wiki is better. > > > > i was investigating phpwiki if it can be used for our forums. > > I submit that TWiki is probably a better solution. It's a clone of the > original (in)famous c2 wiki, and written in a less evil language than > phpwiki. > > -- > "For the time being anyway, until the age of Terminator." -- Yukihiro > 'matz' Matsumoto > > > ------------------------------------------------------- > 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 > |
From: Hanumizzle <han...@gm...> - 2006-04-10 23:11:47
|
On 4/10/06, Sriram Durbha <sri...@gm...> wrote: > guyz, i opened a bug in the sf bugtracker to track this.. But soon reali= sed > that it is a big waste of time.. a wiki is much better. bugtracker is al= so > ok. but wiki is better. > > i was investigating phpwiki if it can be used for our forums. I submit that TWiki is probably a better solution. It's a clone of the original (in)famous c2 wiki, and written in a less evil language than phpwiki. -- "For the time being anyway, until the age of Terminator." -- Yukihiro 'matz' Matsumoto |
From: Sriram D. <sri...@gm...> - 2006-04-10 18:55:37
|
guyz, i opened a bug in the sf bugtracker to track this.. But soon realise= d that it is a big waste of time.. a wiki is much better. bugtracker is also ok. but wiki is better. i was investigating phpwiki if it can be used for our forums. turns out soem one with a decent knowledge of php and mysql can easily integrate php wiki with our forum such that the login password for the foru= m works on the wiki also. thus we can restrict the users to only registered users .. i think phpwiki has additional layers where we can specify who can edit. unfortunately i dont quite fit the bill :( [ Yet :) ] Basically they have to edit the phpwiki code so that it uses the login tabl= e from the forum. cheers ram On 4/10/06, Jose J. Rodriguez <jo...@gm...> wrote: > > On 4/10/06, Larry Gagnon <lgg...@un...> wrote: > > I have completed an edit of the VL5 documentation as described in a > > previous post to this forum. I would appreciate as many developers > > having a look at it as possible. Any constructive criticism, edits, > > busts, suggested changes most welcome. > > > > The docs are available at the upload site: > > > http://distro.ibiblio.org/pub/linux/distributions/vectorlinux/upload/laga= gnon/new_vl5_docs.tar.bz2 > > > > I will leave them there for 2 weeks, after that and after any more > > editing I think we should publish them to the website and make an > > announcement. > > > > I couldn't get into gmail till now, so I answered this in the Forum > first. I'll quote myself here just in case: > > "Larry: If you want the developers to edit the docs concurrently, some > form of collaborative environment would be very helpful. Maybe we can > set up the wiki again, but close it for editing according to a > user/password login system? Or if you think it's workable, I could put > it up on the SourceForge cvs or subversion repository." > > Regards, > Joe1962 > > > ------------------------------------------------------- > 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 > |
From: Jose J. R. <jo...@gm...> - 2006-04-10 16:30:25
|
On 4/10/06, Larry Gagnon <lgg...@un...> wrote: > I have completed an edit of the VL5 documentation as described in a > previous post to this forum. I would appreciate as many developers > having a look at it as possible. Any constructive criticism, edits, > busts, suggested changes most welcome. > > The docs are available at the upload site: > http://distro.ibiblio.org/pub/linux/distributions/vectorlinux/upload/laga= gnon/new_vl5_docs.tar.bz2 > > I will leave them there for 2 weeks, after that and after any more > editing I think we should publish them to the website and make an > announcement. > I couldn't get into gmail till now, so I answered this in the Forum first. I'll quote myself here just in case: "Larry: If you want the developers to edit the docs concurrently, some form of collaborative environment would be very helpful. Maybe we can set up the wiki again, but close it for editing according to a user/password login system? Or if you think it's workable, I could put it up on the SourceForge cvs or subversion repository." Regards, Joe1962 |
From: Jose J. R. <jo...@gm...> - 2006-04-10 16:27:54
|
On 4/10/06, Sriram Durbha <sri...@gm...> wrote: > hi .. > sorry i lost it from my book marks, but can any one point me to the bug > traq ? Hi, It's at http://www.ibiblio.org/vectorlinux/bugtracker/login_page.php but we have a bug tracker at the vectorlinux project on SourceForge, too (http://sourceforge.net/projects/vectorlinux). Perhaps this might be the one to use, as development services are being centered there now? Then again, our own bugtracker might be more flexible than SFs? Regards, Joe1962 |
From: Sriram D. <sri...@gm...> - 2006-04-10 16:18:57
|
hi .. sorry i lost it from my book marks, but can any one point me to the bug traq ? thanks cheers ram |
From: Sriram D. <sri...@gm...> - 2006-04-10 16:18:27
|
hi larry, unpacked just now .. looks good on an initial scan. i will go through it during the week and give you feedback in incremental chunks :) cheers ram On 4/10/06, Larry Gagnon <lgg...@un...> wrote: > > I have completed an edit of the VL5 documentation as described in a > previous post to this forum. I would appreciate as many developers > having a look at it as possible. Any constructive criticism, edits, > busts, suggested changes most welcome. > > The docs are available at the upload site: > > http://distro.ibiblio.org/pub/linux/distributions/vectorlinux/upload/laga= gnon/new_vl5_docs.tar.bz2 > > I will leave them there for 2 weeks, after that and after any more > editing I think we should publish them to the website and make an > announcement. > > Larry (lagagnon) > > > ------------------------------------------------------- > 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=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Vectorlinux-devel mailing list > Vec...@li... > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel > |
From: John B <joh...@gm...> - 2006-04-10 16:09:42
|
Larry, I want to thank you and Andy (LLL) for your labours in updating our docs. :-) I'll grab them when I get back to my VL box tonight and will give them a careful reading. Best, John On 4/10/06, Larry Gagnon <lgg...@un...> wrote: > I have completed an edit of the VL5 documentation as described in a > previous post to this forum. I would appreciate as many developers > having a look at it as possible. Any constructive criticism, edits, > busts, suggested changes most welcome. > > The docs are available at the upload site: > http://distro.ibiblio.org/pub/linux/distributions/vectorlinux/upload/laga= gnon/new_vl5_docs.tar.bz2 > > I will leave them there for 2 weeks, after that and after any more > editing I think we should publish them to the website and make an > announcement. > > Larry (lagagnon) > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Vectorlinux-devel mailing list > Vec...@li... > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel > |
From: Larry G. <lgg...@un...> - 2006-04-10 16:05:40
|
I have completed an edit of the VL5 documentation as described in a previous post to this forum. I would appreciate as many developers having a look at it as possible. Any constructive criticism, edits, busts, suggested changes most welcome. The docs are available at the upload site: http://distro.ibiblio.org/pub/linux/distributions/vectorlinux/upload/lagagnon/new_vl5_docs.tar.bz2 I will leave them there for 2 weeks, after that and after any more editing I think we should publish them to the website and make an announcement. Larry (lagagnon) |
From: John V. <joh...@sy...> - 2006-04-10 00:44:16
|
I did some research and found that we need to update libusb. This changes w= here usb devices are searched from /proc/bus/usb to /dev. I have updated from ve= rsion 0.1.8 to 0.1.12 and put in update/johnvan along with the other packages tha= t=20 vector built. With this, I can now find my scanner in root mode and in user= mode if I set permissions on /dev/usbdev#.# to 666 (where # are digits). John On Sun, 9 Apr 2006 02:25:45 -0400 John Vanderzwet <joh...@sy...> wrote: > I believe the issue is that there are no usb devices in /proc/bus/usb. Sa= ne > looks in here for the available usb ports and checks the vendor device=20 > information to determine which driver to use. rc.hotplug must somehow > create the necessary entries. Coldplug and uevent finds my usb mouse and > put info in /proc/pci/input and creates device in /dev/input. They also f= ind > the printer part of my all-in-one Epson CX4600 and creates a device in /d= ev. >=20 > JohnVan=20 >=20 > On Sun, 9 Apr 2006 06:23:46 -0400 > "Jose J. Rodriguez" <jo...@gm...> wrote: >=20 > > IIRC, Johnvan stated last night after trying vec's kernel 2.6.16 + > > udev packages that his usb scanner didn't work. I searched for some > > info on this and found the following: > >=20 > > "The usb scanner driver has recently been removed from the kernel and > > re-implemented in userspace (as part of the SANE package). You do not > > (and can not) write rules for this hardware as it does not rely on > > specific kernel drivers." > >=20 > > This is from the latest "Writing udev rules" document at > > http://reactivated.net/writing_udev_rules.html. > >=20 > > Regards, > > Joe1962 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > > that extends applications into web and mobile media. Attend the live we= bcast > > and join the prime developer group breaking into this new coding territ= ory! > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642 > > _______________________________________________ > > Vectorlinux-devel mailing list > > Vec...@li... > > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Vectorlinux-devel mailing list > Vec...@li... > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel |
From: John V. <joh...@sy...> - 2006-04-09 14:26:39
|
I believe the issue is that there are no usb devices in /proc/bus/usb. Sane looks in here for the available usb ports and checks the vendor device=20 information to determine which driver to use. rc.hotplug must somehow create the necessary entries. Coldplug and uevent finds my usb mouse and put info in /proc/pci/input and creates device in /dev/input. They also find the printer part of my all-in-one Epson CX4600 and creates a device in /dev. JohnVan=20 On Sun, 9 Apr 2006 06:23:46 -0400 "Jose J. Rodriguez" <jo...@gm...> wrote: > IIRC, Johnvan stated last night after trying vec's kernel 2.6.16 + > udev packages that his usb scanner didn't work. I searched for some > info on this and found the following: >=20 > "The usb scanner driver has recently been removed from the kernel and > re-implemented in userspace (as part of the SANE package). You do not > (and can not) write rules for this hardware as it does not rely on > specific kernel drivers." >=20 > This is from the latest "Writing udev rules" document at > http://reactivated.net/writing_udev_rules.html. >=20 > Regards, > Joe1962 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Vectorlinux-devel mailing list > Vec...@li... > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel |
From: Tony B. <tb...@gm...> - 2006-04-09 13:26:12
|
Basically the same thing. If the kernel doesn't complain about this, then it is fine. IF it complains, just change it to /dev/null. On 4/9/06, Jose J. Rodriguez <jo...@gm...> wrote: > > On 4/9/06, Tony Brijeski <tb...@gm...> wrote: > > You need to disable hotplug. > > > > echo "/dev/null" > /proc/sys/kernel/hotplug > > > > On boot or hotplug will continue to work. > > > > Interesting, at the start of Vec's rc.udev there is the following: > > # disable hotplug helper, udevd listens to netlink > echo "" > /proc/sys/kernel/hotplug > > Is it the same thing? > > Regards, > Joe1962 > > > ------------------------------------------------------- > 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 > |
From: Jose J. R. <jo...@gm...> - 2006-04-09 12:58:18
|
On 4/9/06, Tony Brijeski <tb...@gm...> wrote: > You need to disable hotplug. > > echo "/dev/null" > /proc/sys/kernel/hotplug > > On boot or hotplug will continue to work. > Interesting, at the start of Vec's rc.udev there is the following: =09# disable hotplug helper, udevd listens to netlink =09echo "" > /proc/sys/kernel/hotplug Is it the same thing? Regards, Joe1962 |
From: Tony B. <tb...@gm...> - 2006-04-09 12:43:22
|
You need to disable hotplug. echo "/dev/null" > /proc/sys/kernel/hotplug On boot or hotplug will continue to work. On 4/9/06, Jose J. Rodriguez <jo...@gm...> wrote: > > On 4/9/06, Jose J. Rodriguez <jo...@gm...> wrote: > > On 4/9/06, Jose J. Rodriguez <jo...@gm...> wrote: > > > > > Of course, vl-hot works too. It even coldplugs, that is, if you have = a > > > pendrive attached on boot, it will be mounted. Of course, where the > > > heck the desktop icon ends up is anybody's guess, lol, as there's no > > > logged-in user at that point! > > > > > > > I'm calling this a new branch of vl-hot, 0.3.0, and it's committed to > > the SF cvs already. If you want it and don't want to mess with the cvs > > yet, just let me know. > > > > Sorry, forgot one little detail, lol. You need to edit /etc/sudoers to > reflect the change in path for vl-hot, like this: > > from: > MOUNT1=3D/etc/udev/scripts/vl-hot_mount,/etc/udev/scripts/vl-hot_umount, > ..... > to: MOUNT1=3D/lib/udev/vl-hot_mount,/lib/udev/vl-hot_umount, ..... > > In actual fact, only vl-hot_umount is relevant in /etc/sudoers, as > this is only needed to allow the desktop icon to unmount the drive. > > Regards, > Joe1962 > > > ------------------------------------------------------- > 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 > |
From: Jose J. R. <jo...@gm...> - 2006-04-09 10:23:50
|
IIRC, Johnvan stated last night after trying vec's kernel 2.6.16 + udev packages that his usb scanner didn't work. I searched for some info on this and found the following: "The usb scanner driver has recently been removed from the kernel and re-implemented in userspace (as part of the SANE package). You do not (and can not) write rules for this hardware as it does not rely on specific kernel drivers." This is from the latest "Writing udev rules" document at http://reactivated.net/writing_udev_rules.html. Regards, Joe1962 |
From: Jose J. R. <jo...@gm...> - 2006-04-09 08:21:37
|
On 4/9/06, Jose J. Rodriguez <jo...@gm...> wrote: > On 4/9/06, Jose J. Rodriguez <jo...@gm...> wrote: > > > Of course, vl-hot works too. It even coldplugs, that is, if you have a > > pendrive attached on boot, it will be mounted. Of course, where the > > heck the desktop icon ends up is anybody's guess, lol, as there's no > > logged-in user at that point! > > > > I'm calling this a new branch of vl-hot, 0.3.0, and it's committed to > the SF cvs already. If you want it and don't want to mess with the cvs > yet, just let me know. > Sorry, forgot one little detail, lol. You need to edit /etc/sudoers to reflect the change in path for vl-hot, like this: from: MOUNT1=3D/etc/udev/scripts/vl-hot_mount,/etc/udev/scripts/vl-hot_umou= nt, ..... to: MOUNT1=3D/lib/udev/vl-hot_mount,/lib/udev/vl-hot_umount, ..... In actual fact, only vl-hot_umount is relevant in /etc/sudoers, as this is only needed to allow the desktop icon to unmount the drive. Regards, Joe1962 |
From: Jose J. R. <jo...@gm...> - 2006-04-09 08:05:21
|
On 4/9/06, Jose J. Rodriguez <jo...@gm...> wrote: > Of course, vl-hot works too. It even coldplugs, that is, if you have a > pendrive attached on boot, it will be mounted. Of course, where the > heck the desktop icon ends up is anybody's guess, lol, as there's no > logged-in user at that point! > Guess I spoke too soon! After some careful study and testing, I found that the udev.rules file has mounting/unmounting rules for usb devices, that call /lib/udev/usbmount.sh, which conflicts with vl-hot. It turned out vl-hot was doing the mounting, but usbmount.sh was doing the unmounting, bith to different mountpoints, which is of course bad. I have modified the vl-hot rules and scripts to use the /lib/udev dir, as is now standard, instead of /etc/udev/scripts. I also made the necessary mods to get it working with this new udev version (required mods to 10-vl-hot.rules). I could modify usbmount.sh for our purposes, but vl-hot is already there and more complete (if I do say so myself, lol). The vl-hot rules are also designed to handle more than just usb devices (which means I must check udev.rules for further interference in the case of pccard or firewire drives). Anyway, I suggest we stick to vl-hot for now, meaning some stuff has to be commented out in udev.rules. So far this is limited to the usb devices in lines 24 and 26, like this: # USB storage devices #KERNEL=3D"sd?[0-9]*", ACTION=3D=3D"add", BUS=3D=3D"usb", NAME=3D"%k", SYMLINK=3D"usbmedia%e", GROUP=3D"cdrom", MODE=3D"0660", RUN+=3D"/lib/udev/usbmount.sh add /dev/%k" KERNEL=3D"ub?[0-9]*", ACTION=3D=3D"add", BUS=3D=3D"usb", NAME=3D"%k", SYMLINK=3D"usbmedia%e", GROUP=3D"cdrom", MODE=3D"0660", RUN+=3D"/lib/udev/usbmount.sh add /dev/%k" #KERNEL=3D"sd?[0-9]*", ACTION=3D=3D"remove", RUN+=3D"/lib/udev/usbmount.sh remove /dev/%k" KERNEL=3D"ub?[0-9]*", ACTION=3D=3D"remove", RUN+=3D"/lib/udev/usbmount.sh remove /dev/%k" I'll leave the ub devices to usbmount.sh, lol. I'm calling this a new branch of vl-hot, 0.3.0, and it's committed to the SF cvs already. If you want it and don't want to mess with the cvs yet, just let me know. Regards, Joe1962 |
From: Jose J. R. <jo...@gm...> - 2006-04-09 06:49:02
|
Well, I tried Vec's kernel 2.6.16 and udev 088 packages and it works. Sound, network, even the modem which uses the alsa module snd_intel8x0m that I had to manually modprobe in rc.modules before. Parallel port seems to be loaded, though I can't test it ATM. Of course, vl-hot works too. It even coldplugs, that is, if you have a pendrive attached on boot, it will be mounted. Of course, where the heck the desktop icon ends up is anybody's guess, lol, as there's no logged-in user at that point! DRM/DRI failed, but that's probably because Vec forgot the i915 module in the kernel ;). Regards, Joe1962 |
From: Hanumizzle <han...@gm...> - 2006-04-09 02:26:53
|
On 4/8/06, vec...@li... <vec...@li...> wrote: > On a related note.. Most of the time i install to a local directory. i > hate to pollute the root . > especially because it becomes difficult to uninstall if the package doesn= t > have a good uninstall rule in the make file. Here's what I do right after make install: 'find /usr -type f -cmin -10 > pkglist'. This will give you all files whose status changed in the last ten minutes under /usr; this seems to cover both creation and modification of files. Jii, you must therefore do a sanity check of the resulting pkglist to make sure everything is right, but 99% of the time it is. > One thing we can do to simplify things is allow installpkg to be run as n= on > root user also. We should poll about this, and see how it flies there. When in doubt, always seek the advice of our insightful user base. (And I don't mean that in even a slightly sarcastic way.) (And for those of you not in the know: 'jii' is an particle we use in Hindi to show respect.) -- "[Hanuman] ist ein unsterblicher Affe mit magischen Kr=E4ften, Sohn des Windgottes Phra Phai...Er ist der m=E4chtigste Soldat Phra Rams." |
From: Sriram D. <sri...@gm...> - 2006-04-08 19:17:25
|
i went thru the tukaani site earlier and in part my idea stems from theirs :) [ installing as users ] also i followed a link from there to the LFS package idea page.. based on package users.. i did not completely understand it.. but got the hang of it. basically they want to install each package as a seperate user whose username is same as the package name. gives a lot of flexibility [ and its own share of headaches too.. ] im sorry for introducing a different aspect without clearly identifying it. 1. stadnardization as per JohnB's initial post.. i couldnt agree more 2. installing as users .. errr.. doesnt look like its such a popular idea so far.. so lets give it some rest for the time being maybe? cheers ram On 4/8/06, Jose J. Rodriguez <jo...@gm...> wrote: > > On 4/8/06, joh...@gm... <joh...@gm...> wrote: > > Some programs create their configuration files in an etc directory. I > have > > seen some packages where such an etc directory was a subdirectory under > /usr > > or /usr/X11R6. Since we are discussing standards for building packages > with > > VL6, I believe that one of the arguments that should be passed to just > about > > all configure scripts is --sysconfdir=3D/etc as opposed to letting the > > sysconfdir setting default to a sub under --prefix=3D/usr. > > > > While I'm on this thread, some programs also create local data, notably > dbus, > > hal, and samba, among others. I want to propose that we explicitly pass > > --localstatedir=3D/var to the configure script for such programs where > local > > state data is created. > > > > Thoughts on these ideas, please. > > > > I agree on /var, since this is sometimes mounted on a separate > partition even. On /etc, I had my misgivings at first, thinking that > programs that install to /usr should use /usr/etc; but after careful > thought and checking out /usr/local/etc (found it empty), /usr/etc > (only sane.d, printcap and wgetrc) and /opt/kde/etc (only xdg and > ksysguarddrc), I realised that, at least the apps I've packaged, and > also any others I've installed, use /etc anyway. It has the added > advantage of making it easier to backup such info. > > Regards, > Joe1962 > > > ------------------------------------------------------- > 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 > |