You can subscribe to this list here.
2006 |
Jan
(8) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(6) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(7) |
2008 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(2) |
May
(2) |
Jun
(3) |
Jul
(3) |
Aug
(1) |
Sep
(11) |
Oct
(7) |
Nov
(1) |
Dec
(3) |
2009 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(3) |
May
(12) |
Jun
(22) |
Jul
(36) |
Aug
(7) |
Sep
(6) |
Oct
(9) |
Nov
(11) |
Dec
(14) |
2010 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <hai...@us...> - 2007-12-09 14:10:20
|
Revision: 238 http://xconfig.svn.sourceforge.net/xconfig/?rev=238&view=rev Author: hai-zaar Date: 2007-12-09 06:10:25 -0800 (Sun, 09 Dec 2007) Log Message: ----------- tagging 2.1.1 Added Paths: ----------- xconfig/tags/2.1.1/ xconfig/tags/2.1.1/ChangeLog xconfig/tags/2.1.1/configure.ac xconfig/tags/2.1.1/lib/plugins/PluggedMonitors.sh xconfig/tags/2.1.1/lib/sections/Files.sh Removed Paths: ------------- xconfig/tags/2.1.1/ChangeLog xconfig/tags/2.1.1/configure.ac xconfig/tags/2.1.1/lib/plugins/PluggedMonitors.sh xconfig/tags/2.1.1/lib/sections/Files.sh This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <hai...@us...> - 2007-12-09 14:09:23
|
Revision: 237 http://xconfig.svn.sourceforge.net/xconfig/?rev=237&view=rev Author: hai-zaar Date: 2007-12-09 06:09:28 -0800 (Sun, 09 Dec 2007) Log Message: ----------- closing 2.1.1 Modified Paths: -------------- xconfig/trunk/ChangeLog xconfig/trunk/configure.ac This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <hai...@us...> - 2007-12-09 14:08:18
|
Revision: 236 http://xconfig.svn.sourceforge.net/xconfig/?rev=236&view=rev Author: hai-zaar Date: 2007-12-09 06:08:21 -0800 (Sun, 09 Dec 2007) Log Message: ----------- Xorg-7.2 compatability fixes Modified Paths: -------------- xconfig/trunk/ChangeLog xconfig/trunk/lib/sections/Files.sh This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <hai...@us...> - 2007-12-09 14:07:00
|
Revision: 235 http://xconfig.svn.sourceforge.net/xconfig/?rev=235&view=rev Author: hai-zaar Date: 2007-12-09 06:07:01 -0800 (Sun, 09 Dec 2007) Log Message: ----------- PluggedMonitors.sh: Bash compatability fixes Modified Paths: -------------- xconfig/trunk/ChangeLog xconfig/trunk/lib/plugins/PluggedMonitors.sh This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <a13...@12...> - 2006-12-04 13:47:10
|
您好! 我司(广州市南雄贸易有限公司),按季度完税,每月都搁下相当数量的国 税、地税发票。为了避免过多的发票因此作废,特--优惠对外企业、厂家、 个人代理代开!如有需要的请来电话联系! 联系人:陈健生-1 3 8 2 6 4 9 7 4 7 6 公司Email:a13...@12... |
From: <a13...@12...> - 2006-09-11 02:48:35
|
您好! 我司(广州市南雄贸易有限公司),按季度完税,每月都搁下相当数量的国 税、地税发票。为了避免过多的发票因此作废,特--优惠对外企业、厂家、 个人代理代开!如有需要的请来电话联系! 联系人:陈健生-1 3 8 2 6 4 9 7 4 7 6 公司Email:a13...@12... |
From: <a13...@12...> - 2006-09-06 18:08:47
|
您好! 我司(广州市南雄贸易有限公司),按季度完税,每月都搁下相当数量的国 税、地税发票。为了避免过多的发票因此作废,特--优惠对外企业、厂家、 个人代理代开!如有需要的请来电话联系! 联系人:陈健生-1 3 8 2 6 4 9 7 4 7 6 公司Email:a13...@12... |
From: Hai Z. <ha...@gm...> - 2006-08-24 19:58:27
|
xconfig subversion repository has been migrated to SourceFourge. Dick, you are welcome to create xconfig-compat branch and start putting your patches there. -- Zaar |
From: Dick <dic...@ch...> - 2006-08-17 17:10:23
|
Alon Keren <alon.keren <at> gmail.com> writes: > I'm actually leaning more towards this solution ('3') now, as I worry > that another package would confuse potential users. I agree, lets go for option 3 ;) I'll try to port libbash and xconfig to older bash / sed as soon as possible and send patches + updated scripts to the list for review. greetings, Dick |
From: Alon K. <alo...@gm...> - 2006-08-17 12:16:13
|
> 3. Just like 2, but release one single tarball, which will have both > new and old code sets and master configure-like script which will test > the system and then pass control to either new or compat version. > Pros: Like in 2 > Contras: Alghouth 2.contras is eliminated, but new contras are > * configure-like script have to be maintained to contain > all relevant system checks > * We still will have to release original new and compat > tarballs, since distribution vendors will want them and not this new > all-in-one tarball. Distribution vendors let all kinds of monstrous products intro their repositories. I don't think a slightly bigger tarball will make a difference for them. Especially if: 1. They don't have a choice 2. The products ('xconfig' and 'libbash') are very small as it is I'm actually leaning more towards this solution ('3') now, as I worry that another package would confuse potential users. Alon On 8/17/06, Hai Zaar <ha...@gm...> wrote: > Well, I can see these solutions here: > > 1. Release rpms for RH-7.3 and put those patches there. Or may be put > the patches under 'legacy' dir in libbash/xconfig distribution. > Considering amount of related changes and xconfig/libbash release > cycle, it does not look like time-consuming task to maintain it. > Pros: Easy, minimal initial time investment. > Contras: Not elegant - manual patches track. Becomes more difficult to > maintain as amount of differences grows. > > 2. Create libbash-compat and xconfig-compat branches in version > control system. This means releasing two sets of tarballs and rpms. > This solution is much like the first one, but more elegant. > Pros: Version control does everything. Very elegant. > Contras: Two release sets - users will somehow have to choose which > one is relevant for them. > > 3. Just like 2, but release one single tarball, which will have both > new and old code sets and master configure-like script which will test > the system and then pass control to either new or compat version. > Pros: Like in 2 > Contras: Alghouth 2.contras is eliminated, but new contras are > * configure-like script have to be maintained to contain > all relevant system checks > * We still will have to release original new and compat > tarballs, since distribution vendors will want them and not this new > all-in-one tarball. > * So by saving user from some thinking we introduce > another type of release file. > > 4. Move to templates, that will be substituted by configure. For > example @sed_tab@ will be expanded either by '\t' of by ' ' > depending on sed version. > Pros: Single code line and release set > Contras: Very time consuming. In fact, we'll start to implement our > own set of macros, which will have to be extended each time another > backward-incompatibility is discovered. Each xconfig/libbash developer > will have to become familiar with this macro set. > > 5. Write backward compatible code. But this is just ugly... > > Start voting guys! :) > > I'm voting with both hands for solution number 2! > > On 8/14/06, Dick Marinus <dic...@ch...> wrote: > > Hi, > > > > I've started hacking libbash and xconfig to make both scripts compatible > > with bash 2 and older coreutils (I'm stuck to a Red Hat 7.3 environment) > > Please review my patches attached to this mail. > > I think it would be a good idea to use autoconf / automake to detect the > > bash version and generate the scripts with appropriate code. Could > > someone please give me some hints about this? > > > > Thanks in advance, > > Dick > > > > > > ------------------------------------------------------------------------- > > 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?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > > _______________________________________________ > > Xconfig-common mailing list > > Xco...@li... > > https://lists.sourceforge.net/lists/listinfo/xconfig-common > > > > > > > > > > > -- > Zaar > > ------------------------------------------------------------------------- > 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?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Xconfig-common mailing list > Xco...@li... > https://lists.sourceforge.net/lists/listinfo/xconfig-common > |
From: Hai Z. <ha...@gm...> - 2006-08-17 11:15:48
|
Well, I can see these solutions here: 1. Release rpms for RH-7.3 and put those patches there. Or may be put the patches under 'legacy' dir in libbash/xconfig distribution. Considering amount of related changes and xconfig/libbash release cycle, it does not look like time-consuming task to maintain it. Pros: Easy, minimal initial time investment. Contras: Not elegant - manual patches track. Becomes more difficult to maintain as amount of differences grows. 2. Create libbash-compat and xconfig-compat branches in version control system. This means releasing two sets of tarballs and rpms. This solution is much like the first one, but more elegant. Pros: Version control does everything. Very elegant. Contras: Two release sets - users will somehow have to choose which one is relevant for them. 3. Just like 2, but release one single tarball, which will have both new and old code sets and master configure-like script which will test the system and then pass control to either new or compat version. Pros: Like in 2 Contras: Alghouth 2.contras is eliminated, but new contras are * configure-like script have to be maintained to contain all relevant system checks * We still will have to release original new and compat tarballs, since distribution vendors will want them and not this new all-in-one tarball. * So by saving user from some thinking we introduce another type of release file. 4. Move to templates, that will be substituted by configure. For example @sed_tab@ will be expanded either by '\t' of by ' ' depending on sed version. Pros: Single code line and release set Contras: Very time consuming. In fact, we'll start to implement our own set of macros, which will have to be extended each time another backward-incompatibility is discovered. Each xconfig/libbash developer will have to become familiar with this macro set. 5. Write backward compatible code. But this is just ugly... Start voting guys! :) I'm voting with both hands for solution number 2! On 8/14/06, Dick Marinus <dic...@ch...> wrote: > Hi, > > I've started hacking libbash and xconfig to make both scripts compatible > with bash 2 and older coreutils (I'm stuck to a Red Hat 7.3 environment) > Please review my patches attached to this mail. > I think it would be a good idea to use autoconf / automake to detect the > bash version and generate the scripts with appropriate code. Could > someone please give me some hints about this? > > Thanks in advance, > Dick > > > ------------------------------------------------------------------------- > 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?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > Xconfig-common mailing list > Xco...@li... > https://lists.sourceforge.net/lists/listinfo/xconfig-common > > > > -- Zaar |
From: Alon K. <alo...@gm...> - 2006-08-14 17:19:01
|
On 8/14/06, Dick Marinus <dic...@ch...> wrote: > Hi, > > I've started hacking libbash and xconfig to make both scripts compatible > with bash 2 and older coreutils (I'm stuck to a Red Hat 7.3 environment) > Please review my patches attached to this mail. > I think it would be a good idea to use autoconf / automake to detect the > bash version and generate the scripts with appropriate code. Could > someone please give me some hints about this? > > Thanks in advance, > Dick > > > ------------------------------------------------------------------------- > 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?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > Xconfig-common mailing list > Xco...@li... > https://lists.sourceforge.net/lists/listinfo/xconfig-common > > > > Hi, I haven't looked at the patches yet, but I'd like to address the issue of implementing backwards-compatability: Such patches are likely to change as code is added to the projects, and version-controling them could become ugly. Instead, we should keep backwards-compatible files under version-control. One way to do it is to maintain shadows ('branches') of xconfig and libbash specifically for backwards-compatibility. Another way is to keep backwards-compatible files alongside uptodate files, and let the autotools choose which to install (according to versions of bash and coreutils). Personally, I have no preference between these two ways - the first way means administration hassle, and the second means autotools hassle. Alon |
From: Dick M. <dic...@ch...> - 2006-08-14 15:46:41
|
Hi, I've started hacking libbash and xconfig to make both scripts compatible with bash 2 and older coreutils (I'm stuck to a Red Hat 7.3 environment) Please review my patches attached to this mail. I think it would be a good idea to use autoconf / automake to detect the bash version and generate the scripts with appropriate code. Could someone please give me some hints about this? Thanks in advance, Dick |
From: Hai Z. <ha...@gm...> - 2006-06-28 06:53:44
|
- Added dependency for pciutils - Corrected paths Thanks to Dick Marinus for the notes. -- Zaar |
From: Alon K. <alo...@gm...> - 2006-06-26 16:39:24
|
Hi everyone, 2.1.0 is finally out, after a few months of waiting. Notable changes: - Added a configuration for Synaptics touchpad. That means that a touchpad would be auto-detected (obviously, the Synaptics Touchpad X-driver should be installed: http://web.telia.com/~u89404340/touchpad/) - the 'RandRRotation' option is now enabled by default for Nvidia drivers - Added a plug-in that enables and disables X's Composite extension (`xconfig --change Composite --enable`) Enjoy! -- Alon |
From: Hai Z. <ha...@gm...> - 2006-02-19 10:24:46
|
Here are some issues with Xorg-6.9.0 'X -configure' may decide to use 'nv' driver, nevertheless 'nvidia' driver is present. I think it has something to have loading order. Anyway, if you install NVIDIA driver the regular way, you need to do something like: cd /usr/X11/lib/modules && mv nv_drv.so nv_drv.so.skip cd /usr/X11/lib/modules && mv nv_drv.o nv_drv.o.skip -- Zaar |
From: Hai Z. <ha...@gm...> - 2006-02-19 09:54:52
|
I've noticed strange issue with new NVIDIA driver 8178 (+ kernel 2.6.15) and Xorg-6.9.0: Settin "Overlay" "On", will make all qt based apps having their wigets garbled. Checked with qt-3.3.4 and qt-3.3.5. The issue appears only when using Xorg-6.9.0. The solution is either not to enable Overlay, or use both: Option "Overlay" "On" Option "RenderAccel" "On" # Enable hardware acceleration for RENDER exten= sion since xconfig enables overlay by default for nvidia driver, I've fixed it in upstream. Patch attached. -- Zaar |
From: Hai Z. <ha...@gm...> - 2006-02-01 10:24:42
|
2.0.0-rc7 was successfully promoted to 2.0.0 -- Zaar |
From: Hai Z. <ha...@gm...> - 2006-01-08 09:07:59
|
Hi! rc7 contains rpm spec fixes you've asked for. Enjoy! -- Zaar |
From: Hai Z. <ha...@gm...> - 2006-01-06 22:00:18
|
> Well I like pciutils as a frontend, but I think you should use /sys (umm > yes not /proc/pci ;-)) for quering the database from an application. > > But if you think this is way to complicated and you'd like to use the > pciids database from pciutils, pciutils might be a better choice. > We haven't installed pciutils yes because it is an option package in > Fedora Core 4. /sys looks very frightening :) I do not feel like investing in this. pciutils is generally considered as one of the basic system packages, so I think requiring it is not a big issue. P.S. does xconfig work for you, after all? > > Greetings, > Dick > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBDvuUk6xLbhaCdQl8RAuXxAJ4sx1J9BaENdLG04MYtPDQCPxKa0ACfRgHY > 5pt+BkBfKdYI5kqjBK0X8bc=3D > =3DrIkg > -----END PGP SIGNATURE----- > > > -- Zaar |
From: Dick M. <dic...@ch...> - 2006-01-06 21:46:23
|
Op vr, 06-01-2006 te 22:18 +0200, schreef Hai Zaar: > >I don't like the dependency on pciutils,can't you use > > /proc/pci ? > Why do you not like pciutils? Well I like pciutils as a frontend, but I think you should use /sys (umm yes not /proc/pci ;-)) for quering the database from an application. But if you think this is way to complicated and you'd like to use the pciids database from pciutils, pciutils might be a better choice. We haven't installed pciutils yes because it is an option package in Fedora Core 4. Greetings, Dick |
From: Hai Z. <ha...@gm...> - 2006-01-06 20:19:01
|
Hi! On 1/6/06, Dick Marinus <Dic...@et...> wrote: > > Dear Hai-Zaar, > > The RPM for xconfig is missing the dependencies for libbash and pciutils. > The RPM for libbash isn't suitably configured for xconfig (prefix is / > instead of /usr). I'll check/fix this on Sunday. >I don't like the dependency on pciutils,can't you use > /proc/pci ? Why do you not like pciutils? Moreover, from linux-2.6.15/drivers/pci/Kconfig: ---------------------- config PCI_LEGACY_PROC bool "Legacy /proc/pci interface" depends on PCI ---help--- This feature enables a procfs file -- /proc/pci -- that provides = a summary of PCI devices in the system. This feature has been deprecated as of v2.5.53, in favor of using= the tool lspci(8). This feature may be removed at a future date. lspci can provide the same data, as well as much more. lspci is a part of the pci-utils package, which should be installed by your distribu= tion. See <file:Documentation/Changes> for information on where to get the latest version. When in doubt, say N. ---------------------- > > Greetings, > Dick -- Zaar |
From: Dick M. <Dic...@et...> - 2006-01-06 09:56:13
|
Dear Hai-Zaar, The RPM for xconfig is missing the dependencies for libbash and pciutils. The RPM for libbash isn't suitably configured for xconfig (prefix is / instead of /usr). I don't like the dependency on pciutils,can't you use /proc/pci ? Greetings, Dick |
From: Hai Z. <ha...@gm...> - 2006-01-02 16:30:13
|
Additionally, rpms are now available. -- Zaar |
From: Hai Z. <ha...@gm...> - 2006-01-02 15:37:41
|
> > Donations (in case we'll have them) - we need to decide which email > > address will be in charge. > Your e-mail address will be ok for now. Ok. Then please go to https://sourceforge.net/project/admin/donations.php?group_id=3D153622 and opt in. > > I will try your xconfig as soon as possible for our project, I hope it > will suffice... > > About the future of my xconfig, I was thinking about creating an > xconfig-patch tool which applies certain updates on a X config file. Well, my xconfig has an API for plugins, which are intended to alter existing xorg.conf. running xconfig --change ... will invoke plugings. Currently there are two plugings: FontPath and PluggedMonitors. For example: xconfig --change FontPath --add /usr/share/fonts/misc All of this info (and much more) is available in man pages. Plugin API is described in developer manual (under doc) - you'll need doxygen to generate it. P.S. Please reply to the list. Best. -- Zaar |