Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
|
2
(17) |
3
(6) |
|
4
(4) |
5
(6) |
6
(7) |
7
(5) |
8
(4) |
9
(17) |
10
(33) |
|
11
(12) |
12
(10) |
13
(3) |
14
(2) |
15
(3) |
16
(8) |
17
|
|
18
(1) |
19
|
20
(4) |
21
(10) |
22
(3) |
23
(13) |
24
(3) |
|
25
(3) |
26
(10) |
27
|
28
|
29
(7) |
30
(15) |
31
(6) |
|
From: Lonnie A. <li...@lo...> - 2009-01-31 19:51:52
|
Philip, I've put a lot of thought into this as well... For the Philip's of the world, this feature can be disabled with: echo "0002~9999~0000~0000~0000~" > /mnt/kd/arno-iptables-firewall/serial (assuming trunk and arno 1.9, start with 0001~ for 0.6 branch) As long as any new run image is arno 1.9 based, no local arno files will be automatically upgraded with the above serial number. Many users don't have a clue what the differences in the arno 1.88 and 1.9 syntax is, and if they use the web interface to define basic firewall settings, the will never have to. Requiring these users to diff, patch and edit plugins, plugin settings and copying a fresh firewall.conf file after each major upgrade is not user friendly, IMHO. I believe the arno-serial-number mechanism provides a good compromise, to smartly upgrade local arno files when necessary, and the ability for power users to turn off this feature if desired. If there is a better method of accomplishing 'fresh' local arno files, I'm more than willing to discuss it. Lonnie On Jan 31, 2009, at 1:12 PM, Philip Prindeville wrote: > I went back and thought about this, and I think it violates the > "principle of least astonishment", or at least backwards > compatibility. > > Before, if you manually upgraded, you knew what you had to tweak on > each > upgrade. > > Now when you upgrade manually, something mysteriously happens under > the > covers and can clobber your work (and worse, leave a box that you're > upgrading remotely unaccessible). > > I think that these changes should *only* happen in a coordinated > fashion, i.e. when you are using your upgrade script explicitly. > > If you're just scp'ing files around, then this should not happen. > > Can you please make this change? > > Thanks. > > > Lonnie Abelbeck wrote: >> As you probably have noticed, revisions 2355 and 2356 introduce a >> serial number to the arno firewall file set that gets copied to / >> mnt/kd. >> >> The problem this tries to solve is to automatically upgrade the local >> (/mnt/kd/arno-iptables-firewall) arno file set when necessary. >> >> The previous directory will be automatically saved as "/mnt/kd/arno- >> iptables-OLD" . >> >> The new file "serial", contains two decimal numbers separated by a >> tilde, the first represents a major change, the second represents a >> minor change. For example, the 0.6 branch serial file is >> "0001~0001~", the trunk serial file is "0002~0001~", which means that >> a fresh local copy of the arno files will automatically be created >> (saving the old) whenever a person goes from 0.6 -> 0.7 and 0.7 -> >> 0.6 >> since they are each running a different, incompatible version of the >> arno script. >> >> Whenever new versions of the astlinux.shim or plugins are added, then >> the minor change number can be incremented. >> >> Note that all pre-existing "/mnt/kd/arno-iptables-firewall" file sets >> will be upgraded since they don't contain the "serial" file. >> >> If we wanted, we could fine tune this more, adding separate numbers >> for the astlinux.shim and plugins, to minimize the scope of the >> upgrade. >> >> Lonnie >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... > . > > |
|
From: Philip P. <phi...@re...> - 2009-01-31 19:12:41
|
I went back and thought about this, and I think it violates the "principle of least astonishment", or at least backwards compatibility. Before, if you manually upgraded, you knew what you had to tweak on each upgrade. Now when you upgrade manually, something mysteriously happens under the covers and can clobber your work (and worse, leave a box that you're upgrading remotely unaccessible). I think that these changes should *only* happen in a coordinated fashion, i.e. when you are using your upgrade script explicitly. If you're just scp'ing files around, then this should not happen. Can you please make this change? Thanks. Lonnie Abelbeck wrote: > As you probably have noticed, revisions 2355 and 2356 introduce a > serial number to the arno firewall file set that gets copied to /mnt/kd. > > The problem this tries to solve is to automatically upgrade the local > (/mnt/kd/arno-iptables-firewall) arno file set when necessary. > > The previous directory will be automatically saved as "/mnt/kd/arno- > iptables-OLD" . > > The new file "serial", contains two decimal numbers separated by a > tilde, the first represents a major change, the second represents a > minor change. For example, the 0.6 branch serial file is > "0001~0001~", the trunk serial file is "0002~0001~", which means that > a fresh local copy of the arno files will automatically be created > (saving the old) whenever a person goes from 0.6 -> 0.7 and 0.7 -> 0.6 > since they are each running a different, incompatible version of the > arno script. > > Whenever new versions of the astlinux.shim or plugins are added, then > the minor change number can be incremented. > > Note that all pre-existing "/mnt/kd/arno-iptables-firewall" file sets > will be upgraded since they don't contain the "serial" file. > > If we wanted, we could fine tune this more, adding separate numbers > for the astlinux.shim and plugins, to minimize the scope of the upgrade. > > Lonnie > |
|
From: Michael K. <mk...@we...> - 2009-01-31 11:18:02
|
>I don't think you can label vfat partitions with tune2fs >------Original Message------ >From: Michael Keuter >To: da...@ke... >To: AstLinux Developers Mailing List >ReplyTo: AstLinux Developers Mailing List >Subject: Re: [Astlinux-devel] /oldroot/cdrom >Sent: Jan 30, 2009 10:31 AM > >>That may be the problem but... >> >>pbx ~ # dosfslabel /dev/hda1 RUNNIX >>-sh: dosfslabel: command not found >> >>same error on my CentOS system too. >> >>Any other way to set the name? Is this a new requirement (to have >>file system labeled RUNNIX) ? As far as I know I have not done >>anything different. >> >>Thanks >>David > >Hi David, > >yes, you can use also: > >tune2fs -L RUNNIX /dev/hda1 > >Michael Yes Darrick you're right, I read the man pages of tune2fs, and it works only with ext2/3 volumes. Sorry for the wrong suggestion. Michael -- Email: mailto:mk...@we... |
|
From: David K. <Da...@Ke...> - 2009-01-31 03:09:54
|
I am seeing the same thing building 0.6 svn from scratch. Oddly, I don't recall seeing it before and the only difference is that I am using Ubuntu for the first time tonight.... have always used CentOS before. Could this make a difference? David On Sun, Jan 25, 2009 at 11:25 PM, S. Erisman <ser...@se...> wrote: > Philip A. Prindeville wrote: > > I've updated a couple of hours ago, and building from scratch I see: > > > > ... > > make[1]: Entering directory > `/home/philipp/0.6/build_i586/linux-2.6.20.21-astlinux' > > CHK include/linux/version.h > > CHK include/linux/utsrelease.h > > HOSTCC scripts/genksyms/genksyms.o > > SHIPPED scripts/genksyms/lex.c > > SHIPPED scripts/genksyms/parse.h > > SHIPPED scripts/genksyms/keywords.c > > CC arch/i386/kernel/asm-offsets.s > > SHIPPED scripts/genksyms/parse.c > > HOSTCC scripts/genksyms/lex.o > > scripts/genksyms/lex.c:1230: warning: 'input' defined but not used > > HOSTCC scripts/genksyms/parse.o > > HOSTLD scripts/genksyms/genksyms > > GEN include/asm-i386/asm-offsets.h > > CC scripts/mod/empty.o > > HOSTCC scripts/mod/mk_elfconfig > > HOSTCC scripts/kallsyms > > MKELF scripts/mod/elfconfig.h > > HOSTCC scripts/mod/file2alias.o > > HOSTCC scripts/mod/modpost.o > > HOSTCC scripts/mod/sumversion.o > > scripts/mod/sumversion.c: In function 'get_src_version': > > scripts/mod/sumversion.c:384: error: 'PATH_MAX' undeclared (first use in > this function) > > scripts/mod/sumversion.c:384: error: (Each undeclared identifier is > reported only once > > scripts/mod/sumversion.c:384: error: for each function it appears in.) > > scripts/mod/sumversion.c:384: warning: unused variable 'filelist' > > make[3]: *** [scripts/mod/sumversion.o] Error 1 > > make[2]: *** [scripts/mod] Error 2 > > make[2]: *** Waiting for unfinished jobs.... > > make[1]: *** [scripts] Error 2 > > make[1]: Leaving directory > `/home/philipp/0.6/build_i586/linux-2.6.20.21-astlinux' > > make: *** > [/home/philipp/0.6/build_i586/linux-2.6.20.21-astlinux/arch/i386/boot/bzImage] > Error 2 > > > > > > This is on an FC9-x86_64 platform. > > > > Anyone else seeing this? > > > > -Philip > > > Philip, > > Yes I have seen this same issue while building the 0.6 branch. I > *temporarily* fixed it by *manually* adding "#include <limits.h>" to the > headers section of the scripts/mod/sumversion.c linux source file. This > should probably get turned into a patch. > > -Steve > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > |
|
From: Lonnie A. <li...@lo...> - 2009-01-31 02:51:25
|
On Jan 30, 2009, at 8:04 PM, David Kerr wrote: > I notice (in the 0.6.2 image) that a new file is in the "os" > directory called "ver" with a one line of text "astlinux-0.6.2" > > I have not noticed this file before. Can someone tell me what it is > used for and whether I need to update it every time I put on a new > image (which will have the svn version number in the filename). > > Thanks Here is a snippet of the runnix code that should answer your question... -- snip -- # Get the latest good one cd $BASE/os RUNIMG=`ls *.run | tail -n1` fi #If we have a ver file, override auto/default.conf value if [ -f $BASE/os/ver ] then RUNIMG=`cat $BASE/os/ver`.run fi -- snip -- In short, removing the 'ver' file, the last alphabetical filename will be used, otherwise the ver file overrides it. If you have used the "upgrade-run-image" feature, 'ver' and 'Xver' files are used to note the current and previous saved images. Possibly that is how the 'ver' file got created. Lonnie PS: Were you able to get your private repository working with ftp:// and upgrade-run-image ? |
|
From: David K. <Da...@Ke...> - 2009-01-31 02:28:42
|
I notice (in the 0.6.2 image) that a new file is in the "os" directory called "ver" with a one line of text "astlinux-0.6.2" I have not noticed this file before. Can someone tell me what it is used for and whether I need to update it every time I put on a new image (which will have the svn version number in the filename). Thanks David. |
|
From: Philip P. <phi...@re...> - 2009-01-30 19:00:01
|
It should be part of the "dosfsutils" package. David Kerr wrote: > Yes, I understood that (reflash CF card). Is there a dosfslabel for > CentOS? > > David > > On Fri, Jan 30, 2009 at 1:01 PM, Darrick Hartman > <dha...@dj... <mailto:dha...@dj...>> wrote: > > David, > > The problem is not with the Astlinux image. It's with the initial > runnix image you used to flash your CF card. The original ones > (before 0.6.2 official releases) did not properly label the vfat > partition. If you don't have dosfsutils, you may need to install > the package in your host OS or you could install the 0.6.2 image > to the CF (completely overwrite everything on your CF). I think > you're best bet is to install the dosfsutils (not sure what it's > called on your specific distro). > > Darrick > > David Kerr wrote: > > I will rebuild my image from the 0.6.2 image this evening and > see how it goes. Thanks > > David > > On Fri, Jan 30, 2009 at 12:05 PM, Darrick Hartman > <dha...@dj... <mailto:dha...@dj...> > <mailto:dha...@dj... > <mailto:dha...@dj...>>> wrote: > > I don't think you can label vfat partitions with tune2fs > ------Original Message------ > From: Michael Keuter > To: da...@ke... <mailto:da...@ke...> > <mailto:da...@ke... <mailto:da...@ke...>> > To: AstLinux Developers Mailing List > ReplyTo: AstLinux Developers Mailing List > Subject: Re: [Astlinux-devel] /oldroot/cdrom > Sent: Jan 30, 2009 10:31 AM > > >That may be the problem but... > > > >pbx ~ # dosfslabel /dev/hda1 RUNNIX > >-sh: dosfslabel: command not found > > > >same error on my CentOS system too. > > > >Any other way to set the name? Is this a new requirement > (to have > >file system labeled RUNNIX) ? As far as I know I have not > done > >anything different. > > > >Thanks > >David > > Hi David, > > yes, you can use also: > > tune2fs -L RUNNIX /dev/hda1 > > Michael > |
|
From: David K. <Da...@Ke...> - 2009-01-30 18:07:01
|
Yes, I understood that (reflash CF card). Is there a dosfslabel for CentOS? David On Fri, Jan 30, 2009 at 1:01 PM, Darrick Hartman <dha...@dj...>wrote: > David, > > The problem is not with the Astlinux image. It's with the initial runnix > image you used to flash your CF card. The original ones (before 0.6.2 > official releases) did not properly label the vfat partition. If you don't > have dosfsutils, you may need to install the package in your host OS or you > could install the 0.6.2 image to the CF (completely overwrite everything on > your CF). I think you're best bet is to install the dosfsutils (not sure > what it's called on your specific distro). > > Darrick > > David Kerr wrote: > >> I will rebuild my image from the 0.6.2 image this evening and see how it >> goes. Thanks >> >> David >> >> On Fri, Jan 30, 2009 at 12:05 PM, Darrick Hartman < >> dha...@dj... <mailto:dha...@dj...>> wrote: >> >> I don't think you can label vfat partitions with tune2fs >> ------Original Message------ >> From: Michael Keuter >> To: da...@ke... <mailto:da...@ke...> >> To: AstLinux Developers Mailing List >> ReplyTo: AstLinux Developers Mailing List >> Subject: Re: [Astlinux-devel] /oldroot/cdrom >> Sent: Jan 30, 2009 10:31 AM >> >> >That may be the problem but... >> > >> >pbx ~ # dosfslabel /dev/hda1 RUNNIX >> >-sh: dosfslabel: command not found >> > >> >same error on my CentOS system too. >> > >> >Any other way to set the name? Is this a new requirement (to have >> >file system labeled RUNNIX) ? As far as I know I have not done >> >anything different. >> > >> >Thanks >> >David >> >> Hi David, >> >> yes, you can use also: >> >> tune2fs -L RUNNIX /dev/hda1 >> >> Michael >> >> -- >> Email: mailto:mk...@we... <mailto:mk...@we...> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> <mailto:Ast...@li...> >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to >> pa...@kr... <mailto:pa...@kr...>. >> >> >> Sent from my BlackBerry(R) wireless device from U.S. Cellular >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> <mailto:Ast...@li...> >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to >> pa...@kr... <mailto:pa...@kr...>. >> >> >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> Donations to support AstLinux are graciously accepted via PayPal to >> pa...@kr.... >> > > > |
|
From: Darrick H. <dha...@dj...> - 2009-01-30 18:01:15
|
David, The problem is not with the Astlinux image. It's with the initial runnix image you used to flash your CF card. The original ones (before 0.6.2 official releases) did not properly label the vfat partition. If you don't have dosfsutils, you may need to install the package in your host OS or you could install the 0.6.2 image to the CF (completely overwrite everything on your CF). I think you're best bet is to install the dosfsutils (not sure what it's called on your specific distro). Darrick David Kerr wrote: > I will rebuild my image from the 0.6.2 image this evening and see how it > goes. Thanks > > David > > On Fri, Jan 30, 2009 at 12:05 PM, Darrick Hartman > <dha...@dj... <mailto:dha...@dj...>> wrote: > > I don't think you can label vfat partitions with tune2fs > ------Original Message------ > From: Michael Keuter > To: da...@ke... <mailto:da...@ke...> > To: AstLinux Developers Mailing List > ReplyTo: AstLinux Developers Mailing List > Subject: Re: [Astlinux-devel] /oldroot/cdrom > Sent: Jan 30, 2009 10:31 AM > > >That may be the problem but... > > > >pbx ~ # dosfslabel /dev/hda1 RUNNIX > >-sh: dosfslabel: command not found > > > >same error on my CentOS system too. > > > >Any other way to set the name? Is this a new requirement (to have > >file system labeled RUNNIX) ? As far as I know I have not done > >anything different. > > > >Thanks > >David > > Hi David, > > yes, you can use also: > > tune2fs -L RUNNIX /dev/hda1 > > Michael > > -- > Email: mailto:mk...@we... <mailto:mk...@we...> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > <mailto:Ast...@li...> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr... <mailto:pa...@kr...>. > > > Sent from my BlackBerry® wireless device from U.S. Cellular > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > <mailto:Ast...@li...> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr... <mailto:pa...@kr...>. > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ------------------------------------------------------------------------ > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: David K. <Da...@Ke...> - 2009-01-30 17:57:49
|
I will rebuild my image from the 0.6.2 image this evening and see how it goes. Thanks David On Fri, Jan 30, 2009 at 12:05 PM, Darrick Hartman <dha...@dj... > wrote: > I don't think you can label vfat partitions with tune2fs > ------Original Message------ > From: Michael Keuter > To: da...@ke... > To: AstLinux Developers Mailing List > ReplyTo: AstLinux Developers Mailing List > Subject: Re: [Astlinux-devel] /oldroot/cdrom > Sent: Jan 30, 2009 10:31 AM > > >That may be the problem but... > > > >pbx ~ # dosfslabel /dev/hda1 RUNNIX > >-sh: dosfslabel: command not found > > > >same error on my CentOS system too. > > > >Any other way to set the name? Is this a new requirement (to have > >file system labeled RUNNIX) ? As far as I know I have not done > >anything different. > > > >Thanks > >David > > Hi David, > > yes, you can use also: > > tune2fs -L RUNNIX /dev/hda1 > > Michael > > -- > Email: mailto:mk...@we... > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > > Sent from my BlackBerry(R) wireless device from U.S. Cellular > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > |
|
From: Darrick H. <dha...@dj...> - 2009-01-30 17:05:43
|
I don't think you can label vfat partitions with tune2fs ------Original Message------ From: Michael Keuter To: da...@ke... To: AstLinux Developers Mailing List ReplyTo: AstLinux Developers Mailing List Subject: Re: [Astlinux-devel] /oldroot/cdrom Sent: Jan 30, 2009 10:31 AM >That may be the problem but... > >pbx ~ # dosfslabel /dev/hda1 RUNNIX >-sh: dosfslabel: command not found > >same error on my CentOS system too. > >Any other way to set the name? Is this a new requirement (to have >file system labeled RUNNIX) ? As far as I know I have not done >anything different. > >Thanks >David Hi David, yes, you can use also: tune2fs -L RUNNIX /dev/hda1 Michael -- Email: mailto:mk...@we... ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... Sent from my BlackBerry® wireless device from U.S. Cellular |
|
From: Lonnie A. <li...@lo...> - 2009-01-30 16:39:55
|
On Jan 30, 2009, at 10:31 AM, Michael Keuter wrote: >> That may be the problem but... >> >> pbx ~ # dosfslabel /dev/hda1 RUNNIX >> -sh: dosfslabel: command not found >> >> same error on my CentOS system too. >> >> Any other way to set the name? Is this a new requirement (to have >> file system labeled RUNNIX) ? As far as I know I have not done >> anything different. >> >> Thanks >> David > > Hi David, > > yes, you can use also: > > tune2fs -L RUNNIX /dev/hda1 > > Michael Are you sure tune2fs works for vfat partitions? Lonnie |
|
From: Michael K. <mk...@we...> - 2009-01-30 16:32:06
|
>That may be the problem but... > >pbx ~ # dosfslabel /dev/hda1 RUNNIX >-sh: dosfslabel: command not found > >same error on my CentOS system too. > >Any other way to set the name? Is this a new requirement (to have >file system labeled RUNNIX) ? As far as I know I have not done >anything different. > >Thanks >David Hi David, yes, you can use also: tune2fs -L RUNNIX /dev/hda1 Michael -- Email: mailto:mk...@we... |
|
From: Lonnie A. <li...@lo...> - 2009-01-30 15:22:08
|
David, trunk has the dosfslabel command, but unfortunately the 0.6 branch does not. All the latest astlinux-0.6.2.<arch>.img.gz images contain the proper RUNNIX label, you could build a fresh setup from that. Finally, a third option is to create the file "/mnt/kd/rc.local", containing the line: mount -t vfat -o ro /dev/hda1 /oldroot/cdrom where "/dev/hda1" is your vfat, runnix partition, and make sure the file is executable: chmod 755 /mnt/kd/rc.local Lonnie On Jan 30, 2009, at 8:42 AM, David Kerr wrote: > That may be the problem but... > > pbx ~ # dosfslabel /dev/hda1 RUNNIX > -sh: dosfslabel: command not found > > same error on my CentOS system too. > > Any other way to set the name? Is this a new requirement (to have > file system labeled RUNNIX) ? As far as I know I have not done > anything different. > > Thanks > David > > On Fri, Jan 30, 2009 at 12:05 AM, Lonnie Abelbeck <li...@lo... > > wrote: > > On Jan 29, 2009, at 9:06 PM, David Kerr wrote: > > Is /oldroot/cdrom supposed to be left mounted (read-only) or > unmounted after boot? I ask because a while ago there was some > discussion and I thought that the conclusion was to leave it mounted > read-only. However I noticed today on my generic i586 build (serial > console) that it was unmounted after boot. > > Thanks > David > > The initrd unmounts the vfat partition and then the /etc/rc remounts > the vfat partition. > > The end result is that the vfat partition should be mounted 'ro'. > > If it is not getting remounted, then the partition label must be > missing or incorrect. > > dosfslabel /dev/hda1 RUNNIX > > should fix it (assuming /dev/hda1 is your vfat partition), a message > should be logged to that effect on startup. > > Lonnie > > > |
|
From: David K. <Da...@Ke...> - 2009-01-30 14:42:38
|
That may be the problem but... pbx ~ # dosfslabel /dev/hda1 RUNNIX -sh: dosfslabel: command not found same error on my CentOS system too. Any other way to set the name? Is this a new requirement (to have file system labeled RUNNIX) ? As far as I know I have not done anything different. Thanks David On Fri, Jan 30, 2009 at 12:05 AM, Lonnie Abelbeck <li...@lo... > wrote: > > On Jan 29, 2009, at 9:06 PM, David Kerr wrote: > > Is /oldroot/cdrom supposed to be left mounted (read-only) or unmounted >> after boot? I ask because a while ago there was some discussion and I >> thought that the conclusion was to leave it mounted read-only. However I >> noticed today on my generic i586 build (serial console) that it was >> unmounted after boot. >> >> Thanks >> David >> > > The initrd unmounts the vfat partition and then the /etc/rc remounts the > vfat partition. > > The end result is that the vfat partition should be mounted 'ro'. > > If it is not getting remounted, then the partition label must be missing or > incorrect. > > dosfslabel /dev/hda1 RUNNIX > > should fix it (assuming /dev/hda1 is your vfat partition), a message should > be logged to that effect on startup. > > Lonnie > > > |
|
From: Lonnie A. <li...@lo...> - 2009-01-30 05:05:24
|
On Jan 29, 2009, at 9:06 PM, David Kerr wrote: > Is /oldroot/cdrom supposed to be left mounted (read-only) or > unmounted after boot? I ask because a while ago there was some > discussion and I thought that the conclusion was to leave it mounted > read-only. However I noticed today on my generic i586 build (serial > console) that it was unmounted after boot. > > Thanks > David The initrd unmounts the vfat partition and then the /etc/rc remounts the vfat partition. The end result is that the vfat partition should be mounted 'ro'. If it is not getting remounted, then the partition label must be missing or incorrect. dosfslabel /dev/hda1 RUNNIX should fix it (assuming /dev/hda1 is your vfat partition), a message should be logged to that effect on startup. Lonnie |
|
From: Philip P. <phi...@re...> - 2009-01-30 04:04:35
|
Sorry, read it to quickly: that was a calloc() and not malloc() call, but I still don't see what this fix changes, frankly... unless ast_calloc() is a macro and it's applying some funky magic to figure out what the alignment should be... The while () loop changes look more substantive... I'll dig deeper later. Never mind. I'm just rambling. Lonnie Abelbeck wrote: > Philip, > > This was not my fix, but found and committed here: > http://bugs.digium.com/view.php?id=14308 > > It appears getting the num_dials correct was the problem. > > Lonnie > > On Jan 29, 2009, at 7:24 PM, Philip Prindeville wrote: > > >> abe...@us... wrote: >> >>> Revision: 2423 >>> http://astlinux.svn.sourceforge.net/astlinux/?rev=2423&view=rev >>> Author: abelbeck >>> Date: 2009-01-29 21:46:16 +0000 (Thu, 29 Jan 2009) >>> >>> Log Message: >>> ----------- >>> Patch to fix app_page called with more than one extension >>> >>> Added Paths: >>> ----------- >>> branches/0.6/package/asterisk/asterisk-1-4-23-1-app_page.patch >>> >>> Added: branches/0.6/package/asterisk/asterisk-1-4-23-1-app_page.patch >>> =================================================================== >>> --- branches/0.6/package/asterisk/asterisk-1-4-23-1- >>> app_page.patch (rev 0) >>> +++ branches/0.6/package/asterisk/asterisk-1-4-23-1-app_page.patch >>> 2009-01-29 21:46:16 UTC (rev 2423) >>> @@ -0,0 +1,22 @@ >>> +--- asterisk-1.4.23.1.orig/apps/app_page.c 2009/01/14 19:34:35 >>> 168608 >>> ++++ asterisk-1.4.23.1/apps/app_page.c 2009/01/25 13:33:20 170979 >>> +@@ -120,12 +120,15 @@ >>> + /* Count number of extensions in list by number of ampersands + >>> 1 */ >>> + num_dials = 1; >>> + tmp2 = tmp; >>> +- while (*tmp2 && *tmp2++ == '&') { >>> +- num_dials++; >>> ++ while (*tmp2) { >>> ++ if (*tmp2 == '&') { >>> ++ num_dials++; >>> ++ } >>> ++ tmp2++; >>> + } >>> + >>> +- if (!(dial_list = ast_calloc(num_dials, sizeof(void *)))) { >>> +- ast_log(LOG_ERROR, "Can't allocate %ld bytes for dial list\n", >>> (long)(sizeof(void *) * num_dials)); >>> ++ if (!(dial_list = ast_calloc(num_dials, sizeof(struct ast_dial >>> *)))) { >>> >>> >> Not getting this... both sizeof(void *) and sizeof(struct ast_dial *) >> are 4 bytes (on a 32-bit machine). So the first change is a no-op. >> >> And you're not scaling it by * num_dials, as the log message claims >> you >> are... >> >> >> >>> ++ ast_log(LOG_ERROR, "Can't allocate %ld bytes for dial list\n", >>> (long)(sizeof(struct ast_dial *) * num_dials)); >>> + ast_module_user_remove(u); >>> + return -1; >>> + } >>> |
|
From: David K. <Da...@Ke...> - 2009-01-30 03:06:10
|
Is /oldroot/cdrom supposed to be left mounted (read-only) or unmounted after boot? I ask because a while ago there was some discussion and I thought that the conclusion was to leave it mounted read-only. However I noticed today on my generic i586 build (serial console) that it was unmounted after boot. Thanks David |
|
From: David K. <Da...@Ke...> - 2009-01-30 02:49:46
|
Thanks. That also turns out to be the reason why I could not get the generic i586 image to boot on my Alix board. Now it does. I wonder why it took me so long to figure it out! David On Wed, Jan 28, 2009 at 10:49 PM, Darrick Hartman <dha...@dj... > wrote: > David Kerr wrote: > > Found a bug building generic i586 with serial console. If you select > > this build option for target device in menuconfig then the > > astlinux-0.6-xxxx.run.conf file contains the line... > > > > KCMD="root=/dev/ram0 rw init=/linuxrc console=ttyS0,19200n8 > > astlinux=geni586 astimg=astlinux-0.6-2415.run astkd=/dev/sda1 astlive > > ide=nodma" > > > > when built without serial console selected you get... > > > > KCMD="root=/dev/ram0 rw init=/linuxrc astlinux=geni586 > > astimg=astlinux-0.6-2415.run astkd=auto asturw=auto astlive ide=nodma" > > > > Notice that the asturw= is missing and that the astkd= is pointing at > > /dev/sda1 instead of auto. Not surprisingly this causes problems after > > boot ! > > > > > > Can someone look into a fix please? > > Done. Update your svn copy and you should be good to go. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > |
|
From: Lonnie A. <li...@lo...> - 2009-01-30 02:06:37
|
Philip, This was not my fix, but found and committed here: http://bugs.digium.com/view.php?id=14308 It appears getting the num_dials correct was the problem. Lonnie On Jan 29, 2009, at 7:24 PM, Philip Prindeville wrote: > abe...@us... wrote: >> Revision: 2423 >> http://astlinux.svn.sourceforge.net/astlinux/?rev=2423&view=rev >> Author: abelbeck >> Date: 2009-01-29 21:46:16 +0000 (Thu, 29 Jan 2009) >> >> Log Message: >> ----------- >> Patch to fix app_page called with more than one extension >> >> Added Paths: >> ----------- >> branches/0.6/package/asterisk/asterisk-1-4-23-1-app_page.patch >> >> Added: branches/0.6/package/asterisk/asterisk-1-4-23-1-app_page.patch >> =================================================================== >> --- branches/0.6/package/asterisk/asterisk-1-4-23-1- >> app_page.patch (rev 0) >> +++ branches/0.6/package/asterisk/asterisk-1-4-23-1-app_page.patch >> 2009-01-29 21:46:16 UTC (rev 2423) >> @@ -0,0 +1,22 @@ >> +--- asterisk-1.4.23.1.orig/apps/app_page.c 2009/01/14 19:34:35 >> 168608 >> ++++ asterisk-1.4.23.1/apps/app_page.c 2009/01/25 13:33:20 170979 >> +@@ -120,12 +120,15 @@ >> + /* Count number of extensions in list by number of ampersands + >> 1 */ >> + num_dials = 1; >> + tmp2 = tmp; >> +- while (*tmp2 && *tmp2++ == '&') { >> +- num_dials++; >> ++ while (*tmp2) { >> ++ if (*tmp2 == '&') { >> ++ num_dials++; >> ++ } >> ++ tmp2++; >> + } >> + >> +- if (!(dial_list = ast_calloc(num_dials, sizeof(void *)))) { >> +- ast_log(LOG_ERROR, "Can't allocate %ld bytes for dial list\n", >> (long)(sizeof(void *) * num_dials)); >> ++ if (!(dial_list = ast_calloc(num_dials, sizeof(struct ast_dial >> *)))) { >> > > Not getting this... both sizeof(void *) and sizeof(struct ast_dial *) > are 4 bytes (on a 32-bit machine). So the first change is a no-op. > > And you're not scaling it by * num_dials, as the log message claims > you > are... > > >> ++ ast_log(LOG_ERROR, "Can't allocate %ld bytes for dial list\n", >> (long)(sizeof(struct ast_dial *) * num_dials)); >> + ast_module_user_remove(u); >> + return -1; >> + } |
|
From: Philip P. <phi...@re...> - 2009-01-30 01:24:44
|
abe...@us... wrote: > Revision: 2423 > http://astlinux.svn.sourceforge.net/astlinux/?rev=2423&view=rev > Author: abelbeck > Date: 2009-01-29 21:46:16 +0000 (Thu, 29 Jan 2009) > > Log Message: > ----------- > Patch to fix app_page called with more than one extension > > Added Paths: > ----------- > branches/0.6/package/asterisk/asterisk-1-4-23-1-app_page.patch > > Added: branches/0.6/package/asterisk/asterisk-1-4-23-1-app_page.patch > =================================================================== > --- branches/0.6/package/asterisk/asterisk-1-4-23-1-app_page.patch (rev 0) > +++ branches/0.6/package/asterisk/asterisk-1-4-23-1-app_page.patch 2009-01-29 21:46:16 UTC (rev 2423) > @@ -0,0 +1,22 @@ > +--- asterisk-1.4.23.1.orig/apps/app_page.c 2009/01/14 19:34:35 168608 > ++++ asterisk-1.4.23.1/apps/app_page.c 2009/01/25 13:33:20 170979 > +@@ -120,12 +120,15 @@ > + /* Count number of extensions in list by number of ampersands + 1 */ > + num_dials = 1; > + tmp2 = tmp; > +- while (*tmp2 && *tmp2++ == '&') { > +- num_dials++; > ++ while (*tmp2) { > ++ if (*tmp2 == '&') { > ++ num_dials++; > ++ } > ++ tmp2++; > + } > + > +- if (!(dial_list = ast_calloc(num_dials, sizeof(void *)))) { > +- ast_log(LOG_ERROR, "Can't allocate %ld bytes for dial list\n", (long)(sizeof(void *) * num_dials)); > ++ if (!(dial_list = ast_calloc(num_dials, sizeof(struct ast_dial *)))) { > Not getting this... both sizeof(void *) and sizeof(struct ast_dial *) are 4 bytes (on a 32-bit machine). So the first change is a no-op. And you're not scaling it by * num_dials, as the log message claims you are... > ++ ast_log(LOG_ERROR, "Can't allocate %ld bytes for dial list\n", (long)(sizeof(struct ast_dial *) * num_dials)); > + ast_module_user_remove(u); > + return -1; > + } > > > |
|
From: Lonnie A. <li...@lo...> - 2009-01-29 23:52:34
|
Thanks to Darrick's tip, this is fixed in [2423] branches/0.6
The problem occurs for any app Page() called with more than one
destination extension.
Otherwise, I'm finding 1.4.23.1 working quite well.
Lonnie
On Jan 29, 2009, at 9:08 AM, Darrick Hartman wrote:
> Sounds like an Asterisk bug. I'll try to get this built and tested
> internally to see if I see the same error.
>
> Darrick
>
> Lonnie Abelbeck wrote:
>> I've been testing "astlinux-0.6-2415 - Asterisk 1.4.23.1" and I ran
>> into a problem, after a successful Page() session, on the Hangup,
>> asterisk exits, gone.
>>
>> I have no ZAP/Dahdi/Whatever hardware, a pure SIP/IAX system.
>>
>> ; Page
>> exten => 1177,1,Answer
>> exten => 1177,n,SIPAddHeader(Call-Info: \;answer-after=0)
>> exten => 1177,n,PAGE(${PAGEINSIDEPHONES},d)
>> exten => 1177,n,Hangup
>>
>> With the output...
>>
>> ==============
>> -- Executing [1177@from-local:3] Page("SIP/1016-081efc58",
>> "SIP/...
>> -- <SIP/1016-081efc58> Playing 'beep' (language 'en')
>> -- SIP/... answered
>> -- Created MeetMe conference 1023 for conference '389633976d'
>> -- SIP/... answered
>> -- Hungup 'Zap/pseudo-1561947004'
>> voip*CLI>
>> Disconnected from Asterisk server
>> Executing last minute cleanups
>>
>> ==============
>>
>> This worked fine with 0.6.2
>>
>> Is this a ZAP - Dahdi issue?
>>
>> Lonnie
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...
>> .
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...
> .
>
>
|
|
From: Darrick H. <dha...@dj...> - 2009-01-29 15:08:17
|
Sounds like an Asterisk bug. I'll try to get this built and tested
internally to see if I see the same error.
Darrick
Lonnie Abelbeck wrote:
> I've been testing "astlinux-0.6-2415 - Asterisk 1.4.23.1" and I ran
> into a problem, after a successful Page() session, on the Hangup,
> asterisk exits, gone.
>
> I have no ZAP/Dahdi/Whatever hardware, a pure SIP/IAX system.
>
> ; Page
> exten => 1177,1,Answer
> exten => 1177,n,SIPAddHeader(Call-Info: \;answer-after=0)
> exten => 1177,n,PAGE(${PAGEINSIDEPHONES},d)
> exten => 1177,n,Hangup
>
> With the output...
>
> ==============
> -- Executing [1177@from-local:3] Page("SIP/1016-081efc58", "SIP/...
> -- <SIP/1016-081efc58> Playing 'beep' (language 'en')
> -- SIP/... answered
> -- Created MeetMe conference 1023 for conference '389633976d'
> -- SIP/... answered
> -- Hungup 'Zap/pseudo-1561947004'
> voip*CLI>
> Disconnected from Asterisk server
> Executing last minute cleanups
>
> ==============
>
> This worked fine with 0.6.2
>
> Is this a ZAP - Dahdi issue?
>
> Lonnie
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2009-01-29 15:02:55
|
I've been testing "astlinux-0.6-2415 - Asterisk 1.4.23.1" and I ran
into a problem, after a successful Page() session, on the Hangup,
asterisk exits, gone.
I have no ZAP/Dahdi/Whatever hardware, a pure SIP/IAX system.
; Page
exten => 1177,1,Answer
exten => 1177,n,SIPAddHeader(Call-Info: \;answer-after=0)
exten => 1177,n,PAGE(${PAGEINSIDEPHONES},d)
exten => 1177,n,Hangup
With the output...
==============
-- Executing [1177@from-local:3] Page("SIP/1016-081efc58", "SIP/...
-- <SIP/1016-081efc58> Playing 'beep' (language 'en')
-- SIP/... answered
-- Created MeetMe conference 1023 for conference '389633976d'
-- SIP/... answered
-- Hungup 'Zap/pseudo-1561947004'
voip*CLI>
Disconnected from Asterisk server
Executing last minute cleanups
==============
This worked fine with 0.6.2
Is this a ZAP - Dahdi issue?
Lonnie
|
|
From: Philip A. P. <phi...@re...> - 2009-01-29 06:25:25
|
Philip A. Prindeville wrote: > Darrick Hartman wrote: > >> David Kerr wrote: >> >> >>> Found a bug building generic i586 with serial console. If you select >>> this build option for target device in menuconfig then the >>> astlinux-0.6-xxxx.run.conf file contains the line... >>> >>> KCMD="root=/dev/ram0 rw init=/linuxrc console=ttyS0,19200n8 >>> astlinux=geni586 astimg=astlinux-0.6-2415.run astkd=/dev/sda1 astlive >>> ide=nodma" >>> >>> when built without serial console selected you get... >>> >>> KCMD="root=/dev/ram0 rw init=/linuxrc astlinux=geni586 >>> astimg=astlinux-0.6-2415.run astkd=auto asturw=auto astlive ide=nodma" >>> >>> Notice that the asturw= is missing and that the astkd= is pointing at >>> /dev/sda1 instead of auto. Not surprisingly this causes problems after >>> boot ! >>> >>> >>> Can someone look into a fix please? >>> >>> >> Done. Update your svn copy and you should be good to go. >> >> > > Is that needed in trunk? > > -Philip > Asked and answered: no, it's already in there. |
3 messages has been excluded from this view by a project administrator.
