bug#45645: Please revoke this commit: 7dd1a2174a8376c521dcf271e3b76f64096074fe

[luhux]

Sorry for submitting the wrong patch.

Recently, when I checked the sdcv source code, I found that this environment 
variable does not support multiple paths and is separated by colons.


```
const gchar *stardict_data_dir = g_getenv("STARDICT_DATA_DIR");
std::string data_dir;
if (!opt_data_dir) {
if (!only_data_dir) {
if (stardict_data_dir)
data_dir = stardict_data_dir;
else
data_dir = "/usr/share/stardict/dic";
}
} else {
data_dir = get_impl(opt_data_dir);
}

```

Please revoke the content of this commit.

luhux

bug#41654: test-name: verify-store + check-contents failing on guix-1.2.0rc2-1.0d4b1af

[Stefan]

Hi!

Today I thought that it should be possible to work around this bug on my 
aarch64 system by mounting /tmp as a tmpfs, backed by swap on a small SD card, 
to prevent any issues due to my NFS root. This worked for the 
trap-cleanup-issue. But to my surprise this didn’t work out for the “dtmp/” 
error.

I was wondering, if using /tmp as a tmpfs on my virtual x86_64 system would 
make the test fail there as well. So I did 

sudo mount -t tmpfs -o size=768M tmpfs /tmp
guix build --check --no-grafts guix@1.2.0-8.7624ebb

But there it was passing.

This is the interesting part from the log of the aarch64 system:

test-name: verify-store + check-contents
location: /tmp/guix-build-guix-1.2.0-8.7624ebb.drv-0/source/tests/store.scm:1156
source:
+ (test-assert
+   "verify-store + check-contents"
+   (with-store
+ s
+ (let* ((text (random-text))
+(drv (build-expression->derivation
+   s
+   "corrupt"
+   `(let ((out (assoc-ref %outputs "out")))
+  (call-with-output-file
+out
+(lambda (port) (display ,text port)))
+  #t)
+   #:guile-for-build
+   (package-derivation
+ s
+ %bootstrap-guile
+ (%current-system
+(file (derivation->output-path drv)))
+   (with-derivation-substitute
+ drv
+ text
+ (and (build-derivations s (list drv))
+  (verify-store s #:check-contents? #t)
+  (begin
+(chmod file 420)
+(call-with-output-file
+  file
+  (lambda (port) (display "corrupt!" port)))
+#t)
+  (not (verify-store s #:check-contents? #t))
+  (delete-paths s (list file)))
actual-value: #f
actual-error:
+ (%exception
+   #< message: "path 
`dtmp/guix-tests/store/rn6xq5kaipp8aanhcnz2hvyfmr3y2laa-mirrors' is not in the 
store" status: 1>)
result: FAIL


Bye

Stefan

bug#36900: key-mon crashes on launch

[Alexandros Theodotou]

Hi Tobias,

On Sun, 2021-01-03 at 22:58 +0100, Tobias Geerinckx-Rice wrote:
> guix environment key-mon --ad-hoc key-mon -- key-mon


I tried the command above and this is my output.
```
substitute: updating substitutes from 'https://ci.guix.gnu.org'...
100.0%
1.7 MB will be downloaded
downloading from 
https://ci.guix.gnu.org/nar/lzip/kffsg08xjyzvxddldyqc2xfhiflsk0y6-python2-pygtk-2.24.0-doc
...
 python2-pygtk-2.24.0-
doc  776KiB
   
1.4MiB/s 00:01 [##]
100.0%

The following derivation will be built:
   /gnu/store/mxpnh35lkla14p5f8al3s6vl2sh2w0cd-profile.drv

applying 16 grafts for /gnu/store/p35rw37wg8za9ygwv2q24lcg6a855rw4-
python2-pygtk-2.24.0.drv ...
building CA certificate bundle...
building fonts directory...
generating GLib schema cache...
creating GTK+ icon theme cache...
building cache files for GTK+ input methods...
building directory of Info manuals...
building database for manual pages...
building XDG desktop file cache...
building XDG MIME database...
building profile with 60 packages...

(.key-mon-real:15064): Gtk-WARNING **: 22:14:36.432: Unable to locate
theme engine in module_path: "adwaita",

(.key-mon-real:15064): Gtk-WARNING **: 22:14:36.434: Unable to locate
theme engine in module_path: "murrine",

(.key-mon-real:15064): Gtk-WARNING **: 22:14:36.434: Unable to locate
theme engine in module_path: "murrine",

(.key-mon-real:15064): Gtk-WARNING **: 22:14:36.434: Unable to locate
theme engine in module_path: "murrine",

(.key-mon-real:15064): Gtk-WARNING **: 22:14:36.435: Unable to locate
theme engine in module_path: "murrine",

(.key-mon-real:15064): Gtk-WARNING **: 22:14:36.435: Unable to locate
theme engine in module_path: "murrine",

(.key-mon-real:15064): Gtk-WARNING **: 22:14:36.435: Unable to locate
theme engine in module_path: "murrine",

(.key-mon-real:15064): Gtk-WARNING **: 22:14:36.435: Unable to locate
theme engine in module_path: "murrine",
Traceback (most recent call last):
  File "/gnu/store/fwmb620wk7hadj0iqh8xrxs8a74xhw50-key-mon-
1.17/bin/.key-mon-real", line 3, in 
km.main()
  File "/gnu/store/fwmb620wk7hadj0iqh8xrxs8a74xhw50-key-mon-
1.17/lib/python2.7/site-packages/keymon/key_mon.py", line 1032, in main
keymon = KeyMon(opts)
  File "/gnu/store/fwmb620wk7hadj0iqh8xrxs8a74xhw50-key-mon-
1.17/lib/python2.7/site-packages/keymon/key_mon.py", line 130, in
__init__
self.devices = xlib.XEvents()
  File "/gnu/store/fwmb620wk7hadj0iqh8xrxs8a74xhw50-key-mon-
1.17/lib/python2.7/site-packages/keymon/xlib.py", line 80, in __init__
self.record_display = display.Display()
  File "/gnu/store/ccnd7dx7c1g64mrdhml7vg8qmf65fd67-python2-xlib-
0.27/lib/python2.7/site-packages/Xlib/display.py", line 89, in __init__
self.display = _BaseDisplay(display)
  File "/gnu/store/ccnd7dx7c1g64mrdhml7vg8qmf65fd67-python2-xlib-
0.27/lib/python2.7/site-packages/Xlib/display.py", line 71, in __init__
protocol_display.Display.__init__(self, *args, **keys)
  File "/gnu/store/ccnd7dx7c1g64mrdhml7vg8qmf65fd67-python2-xlib-
0.27/lib/python2.7/site-packages/Xlib/protocol/display.py", line 166,
in __init__
raise error.DisplayConnectionError(self.display_name, r.reason)
Xlib.error.DisplayConnectionError: Can't connect to display ":1": No
protocol specified
```

I get the same error when i launch it as `key-mon` from the console,
after I installed the package.

I tried with `--pure` now and I get your error:
```
No protocol specified
/gnu/store/mzwxwalqni35m1m37xb5qvd0mv1g3sp9-python2-pygtk-
2.24.0/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57:
GtkWarning: could not open display
  warnings.warn(str(e), _gtk.Warning)
Error: Missing xlib, run sudo apt-get install python-xlib
```

> $ sudo apt-get install python-xlib
>  sudo: apt-get: command not found

Lol.

Thanks,
Alex

bug#45517: Failed boot on arm32 with u-boot due to missing requirements with the distro boot protocol

[Danny Milosavljevic]

Hi Mathieu,

On Sat, 02 Jan 2021 11:23:24 +0100
Mathieu Othacehe  wrote:

> > Thanks a lot, that works fine.  
> 
> Glad it works! Maybe we should consider creating a
> gnu/system/images/lime.scm file in the future.

Sure.

I think that Allwinner boards are all similar enough in booting that we could
just have a gnu/system/images/allwinner.scm to support them all--except for
the u-boot package reference they are all the same.

Later Allwinner boards added a reference to an alternative boot sector[1]
for the first part of u-boot into boot ROM *in addition* to the old one--so
even those would still work!

Long story short, all of the Allwinner boards can inherit from the same
allwinner image type--with only the u-boot package (not even the
bootloader-installer) swapped out.

We could have a gnu/system/images/olinuxino-lime2.scm which would inherit
from that common thing somehow (and which would thus have about two lines
of source code total).

But there's a reason I added OS-WITH-U-BOOT and that's because of things
like this.  It can adapt any existing operating-system image, swapping out
the bootloader by an u-boot with a random u-boot board config name and
compile it for a given architecture.

It would be nice to have it integrated into the Guix image generation
process somehow, if possible.  

By automatically calling OS-WITH-U-BOOT (as a fallback), we could avoid ending
up with 1273 similar files in gnu/system/images.  Guix would just call
os-with-u-boot dynamically to generate those image types at runtime
that don't have a special one in that directory.

WDYT?

[1] https://linux-sunxi.org/Bootable_SD_card#SD_Card_Layout


pgpLylZj05rvx.pgp
Description: OpenPGP digital signature

bug#45559: Cuirass has not successfully evaluated the stagig branch in 3 weeks

[Leo Famulari]

I was granted shell access to the Berlin server.

I have been building substitutes for the staging branch from the Git
tree at /home/lfam/staging

I noticed that Cuirass is doing *something* with the staging branch, but
it doesn't seem to have any result that I can observe from the interface
at ci.guix.gnu.org, and package substitutes do not appear.

--
$ ps aux | grep staging
[...]
cuirass   54325  0.0  0.1 509928 223724 ?   Sl2020   0:21 
/gnu/store/0w76khfspfy8qmcpjya41chj3bgfcy0k-guile-3.0.4/bin/guile 
--no-auto-compile -e main -s 
/gnu/store/q2qkcwd82p52x8kdar5kmmhrx464p0vk-cuirass-dev-0.0.1-57.697fa14/bin/evaluate
 ((#:name . "staging-staging") (#:load-path-inputs) (#:package-path-inputs) 
(#:proc-input . "staging") (#:proc-file . "build-aux/cuirass/gnu-system.scm") 
(#:proc . cuirass-jobs) (#:proc-args (systems "x86_64-linux" "i686-linux" 
"aarch64-linux" "armhf-linux")) (#:inputs ((#:name . "staging") (#:url . 
"https://git.savannah.gnu.org/git/guix.git;) (#:load-path . ".") (#:branch . 
"staging") (#:tag . #f) (#:commit . #f) (#:no-compile? . #t))) 
(#:build-outputs)) (((#:input . "staging") (#:directory . 
"/gnu/store/13961d848pgzrbqw4bs4kniv4i4cch9z-guix-64e995b") (#:commit . 
"64e995b4cf473c7f52bad0dea8c27eea6eee662c") (#:timestamp . 1609327975) 
(#:load-path . ".") (#:no-compile? . #t)))
cuirass   62079  0.0  0.1 507644 233260 pts/8   Sl   Jan02   0:17 
/gnu/store/5iisqr9wn9bgg9h52fw86why1xih1gvi-profile/bin/guile --no-auto-compile 
-e main -s /home/mathieu/cuirass/bin/evaluate ((#:name . "staging-staging") 
(#:load-path-inputs) (#:package-path-inputs) (#:proc-input . "staging") 
(#:proc-file . "build-aux/cuirass/gnu-system.scm") (#:proc . cuirass-jobs) 
(#:proc-args (systems "x86_64-linux" "i686-linux" "aarch64-linux")) (#:inputs 
((#:name . "staging") (#:url . "https://git.savannah.gnu.org/git/guix.git;) 
(#:load-path . ".") (#:branch . "staging") (#:tag . #f) (#:commit . #f) 
(#:no-compile? . #t))) (#:build-outputs) (#:priority . 3)) (((#:input . 
"staging") (#:directory . 
"/gnu/store/13961d848pgzrbqw4bs4kniv4i4cch9z-guix-64e995b") (#:commit . 
"64e995b4cf473c7f52bad0dea8c27eea6eee662c") (#:timestamp . 1609610295) 
(#:load-path . ".") (#:no-compile? . #t)))
--


signature.asc
Description: PGP signature

bug#36900: key-mon crashes on launch

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Alexandros Theodotou 写道：

Just FYI this is still broken.


I don't understand how you are reproducing this backtrace:

 $ guix environment key-mon --ad-hoc key-mon -- key-mon
 Error: Missing xlib, run sudo apt-get install python-xlib
 $ sudo apt-get install python-xlib
 sudo: apt-get: command not found

It was worth a try.

How are you launching key-mon?  Is this because I'm not using X?

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#36900: key-mon crashes on launch

[Alexandros Theodotou]

Just FYI this is still broken.

Thanks,
Alex

bug#45633: bcc and bpftrace require kernel headers from system

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

John,

This reminds me of .

John Soo 写道：

Hi Guix,

When I added bcc and bpftrace to guix I didn't think much of 
which

version of the kernel headers would be used.  After a few kernel
updates, it has become clear that the current-system kernel 
headers need


This should probably be booted-system.

to match the kernel headers the packages are compiled with.  Can 
they be

provided with a variant property?  The ocaml packages that need
different ocaml versions seem like a nice model on how to do the 
kernel

headers.


I know exact kernel headers are needed at toolchain run time, when 
building eBPF programmes.  Are they really needed at toolchain 
build time, too?  That sounds wrong (but there are more things 
fundamentally wrong with eBPF on Linux; ask me to rant about 
CONFIG_IKHEADERS).  Still, could pointing bcc/bpftrace to 
booted-system headers at run time not suffice?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#45613: (No Subject)

[John Doe via Bug reports for GNU Guix]

Forgot to mention in the original report: The issue is very similar to the 
following bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38341

bug#41177: Fontconfig issues in Java applications that use fonts

[Fabien SK]

I faced the issue when running josm (downloaded from 
josm.openstreetmap.de, not the guix package). Using "strace" showed me 
that it failed because it cannot load "libfontconfig.so" (it tries in 
several directories). If I add the directory of libfontconfig.so to 
LD_LIBRARY_PATH, then it starts.
I have limited knowledge about how shared libraries are found. I tried 
to understand how "geany" manages to load libfontconfig.so. It looks 
like it depends on libgeany, libgtk3 and libpango which depend on 
libfontconfig. When I do a "readelf -a" on these libraries, I can see in 
their "RUNPATH" the path of "libfontconfig.so":
0x001d (RUNPATH)    Bibliothèque 
runpath:[/gnu/store/avjxs6qgyginkiq6qpk9280zakkaj35h-graphite2-1.3.13/lib:/gnu/store/xwl0p4m34bcan0v9vkjkyzwi6znsv4dm-pixman-0.38.4/lib:/gnu/store/y9fdy234r6hqiacd7hgwlmbdsngbp8p1-fontconfig-2.13.1/lib:…


Regarding Java, I think (but I'm not sure) that it's loaded by 
"libawt_xawt.so". In fontpath.c [1], there is a dlopen of libfontconfig. 
But if I do a "ldd" on the shared library itself, it looks like it does 
not depend on libfontconfig.so.
[1] 
https://github.com/openjdk/jdk16/blob/37043b05576c8b81b43ac41a8f06de0d0bbb3f5b/src/java.desktop/unix/native/common/awt/fontpath.c#L566

Also libfontconfig is not on its RUNPATH:

0x001d (RUNPATH)    Bibliothèque 
runpath:[$ORIGIN:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib:/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib:/gnu/store/w09mqfj1yy32r2fr02nndzs34m4f9ipp-libxext-1.3.4/lib:/gnu/store/4ildmh169dixyn05mlgjz07x4d2hcq2g-libx11-1.6.A/lib:/gnu/store/8m6368gv4z10n6i31ppbr8nxziwmlp3f-libxrender-0.9.10/lib:/gnu/store/cgsk20z1gcw78fdm7bwlb2l49xh7bmzk-libxtst-1.2.3/lib:/gnu/store/b4dk2y4vf98dhxnr0p6f5h4d86vqndkc-libxi-1.7.10/lib:/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/../../..]


I'm quite a beginner in term of Guix (I only played with it in a VM), 
and I hope this information will be useful to somebody. I don't 
understand how the dependencies between executable and libraries are 
supposed to be done in Guix. I can see that sometimes in /gnu/store 
there are symbolic links of shared libraries into other packages. I 
assume that sometimes this RUNPATH is used.

bug#45633: bcc and bpftrace require kernel headers from system

[John Soo]

Hi Guix,

When I added bcc and bpftrace to guix I didn't think much of which
version of the kernel headers would be used.  After a few kernel
updates, it has become clear that the current-system kernel headers need
to match the kernel headers the packages are compiled with.  Can they be
provided with a variant property?  The ocaml packages that need
different ocaml versions seem like a nice model on how to do the kernel
headers.

Thoughts?

 - John

bug#42771: [PATCH] Disable tests for smalltalk and add candidate releases

[Holger Peters]

Hi,

I am not sure I will have the time to solve the remaining issues,
but I would like to share some intermediate results with you.
Find attached the smalltalk file I have in my personal channel,
it contains 2 package definitions.

smalltalk-alt: corresponds to the `normal' smalltalk package with
various fixes over the one currently in gui (a) added
dependencies, (b) uses gcc-5 for building because I found a
reference in the smalltalk mailing list about newer GCC
releases optimizing some statements away that are crucial for
GNU Smalltalk to build.

As a result the test failures for intmath and others that are
present in the current `smalltalk' recipe in guix are
resolved in this variant.

Note that there are still failing tests for this release,
namely all the ANSI compliancy tests. I do feel like since
each and every one of these tests fails, it might be a
build-system-setup/autotest related failure.

`smalltalk-next' is a derived clean build from the VCS. I dropped
the pre-release build as you suggested in (2).


As for going forward I am not quite sure whether I'll find time
to do more debugging.  If I were a heavy GNU Smalltalk user I'd
probably use `smalltalk-next' anyway as it seems to build
flawlessly.


-- Failing Tests for `smalltalk-alt'

ANSI compliancy tests.

 47: ArrayANSITest   FAILED
(testsuite.at:83)
 48: ArrayFactoryANSITestFAILED
(testsuite.at:84)
 49: BagANSITest FAILED
(testsuite.at:85)
 50: BagFactoryANSITest  FAILED
(testsuite.at:86)
 51: BooleanANSITest FAILED
(testsuite.at:87)
 52: ByteArrayANSITest   FAILED
(testsuite.at:88)
 53: ByteArrayFactoryANSITestFAILED
(testsuite.at:89)
 54: CharacterANSITest   FAILED
(testsuite.at:90)
 55: CharacterFactoryANSITestFAILED
(testsuite.at:91)
 56: DateAndTimeANSITest FAILED
(testsuite.at:92)
 57: DateAndTimeFactoryANSITest  FAILED
(testsuite.at:93)
 58: DictionaryANSITest  FAILED
(testsuite.at:94)
 59: DictionaryFactoryANSITest   FAILED
(testsuite.at:95)
 60: DurationANSITestFAILED
(testsuite.at:96)
 61: DurationFactoryANSITest FAILED
(testsuite.at:97)
 62: DyadicValuableANSITest  FAILED
(testsuite.at:98)
 63: ErrorANSITest   FAILED
(testsuite.at:99)
 64: ErrorClassANSITest  FAILED
(testsuite.at:100)
 65: ExceptionANSITest   FAILED
(testsuite.at:101)
 66: ExceptionClassANSITest  FAILED
(testsuite.at:102)
 67: ExceptionSetANSITestFAILED
(testsuite.at:103)
 68: FailedMessageANSITest   FAILED
(testsuite.at:104)
 69: FileStreamFactoryANSITest   FAILED
(testsuite.at:105)
 70: FloatANSITest   FAILED
(testsuite.at:106)
 71: FloatCharacterizationANSITest   FAILED
(testsuite.at:107)
 72: FractionANSITestFAILED
(testsuite.at:108)
 73: FractionFactoryANSITest FAILED
(testsuite.at:109)
 74: IdentityDictionaryANSITest  FAILED
(testsuite.at:110)
 75: IdentityDictionaryFactoryANSITest   FAILED
(testsuite.at:111)
 76: IntegerANSITest FAILED
(testsuite.at:112)
 77: IntervalANSITestFAILED
(testsuite.at:113)
 78: IntervalFactoryANSITest FAILED
(testsuite.at:114)
 79: MessageNotUnderstoodANSITestFAILED
(testsuite.at:115)
 80: MessageNotUnderstoodSelectorANSITestFAILED
(testsuite.at:116)
 81: MonadicBlockANSITestFAILED
(testsuite.at:117)
 82: NilANSITest FAILED
(testsuite.at:118)
 83: NiladicBlockANSITestFAILED
(testsuite.at:119)
 84: NotificationANSITestFAILED
(testsuite.at:120)
 85: NotificationClassANSITest   FAILED
(testsuite.at:121)
 86: ObjectANSITest  FAILED
(testsuite.at:122)
 87: ObjectClassANSITest FAILED
(testsuite.at:123)
 88: OrderedCollectionANSITest   FAILED
(testsuite.at:124)
 89: OrderedCollectionFactoryANSITestFAILED
(testsuite.at:125)
 90: ReadFileStreamANSITest  FAILED
(testsuite.at:126)
 91: ReadStreamANSITest  FAILED
(testsuite.at:127)
 92: ReadStreamFactoryANSITest   FAILED
(testsuite.at:128)
 93: ReadWriteStreamANSITest

bug#45627: Disabling static libraries by default?

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Guix,

One-liners like this[0] one are about as fun to commit as they are 
to see spam up your -commits@ mailbox, and make me wonder why we 
don't pass ‘--disable-static’ ( for other build systems) by 
default in the absence of a :static output.  Has this been 
discussed and rejected?


Guix plays so poorly with static linkage that I'm surprised we 
keep these things lying around at all, like rakes to step on one 
fun day.


Kind regards,

T G-R

[0]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c2c954afb2df5b9926f52b5c14d0213827e3401f


signature.asc
Description: PGP signature

bug#45621: guix refresh -l and deprecated-package issue

[Christopher Baines]

There seems to be some issues with guix refresh -l and/or deprecating
packages.

Take the following example, guile3.0-squee is used by the
guix-data-service. guix refresh -l claims it's not though.

→ ./pre-inst-env guix refresh -l guile-squee
No dependents other than itself: guile-squee@0-2.c1497a2

→ ./pre-inst-env guix refresh -l guile3.0-squee
guix refresh: package 'guile3.0-squee' has been superseded by 'guile-squee'
No dependents other than itself: guile-squee@0-2.c1497a2


signature.asc
Description: PGP signature

bug#45618: development childhurd fails to build: glib@2.62.6: build system `meson'

[Jan Nieuwenhuizen]

Hi,

We have been using the attached devel-hurd.tmpl (see attched) to add a
childhurd service that has a development environment.

On current master

395489cdc959c3f3c026bf545c3ed95efc9919f0
gnu: spice-vdagent: Update to 0.20.0.

building

./pre-inst-env guix system disk-image --target=i586-pc-gnu 
gnu/system/examples/devel-hurd.tmpl

fail with

--8<---cut here---start->8---
guix system: error: gnu/packages/glib.scm:181:2: glib@2.62.6: build system 
`meson' does not support cross builds
--8<---cut here---end--->8---

I guess we are missing a (some?) tests for the Hurd.

Anyway, I started a bisecting round last night and it found

--8<---cut here---start->8---
1b0cda6b44 gnu: qemu: Extend I/O test time-outs.
--8<---cut here---end--->8---

which was an honest debugging leftover, fixed promptly in

--8<---cut here---start->8---
b070e3f810 gnu: qemu: Remove left-over debugging statement.
--8<---cut here---end--->8---

Luckily, this fixed commit also builds the childhurd again...so I'm
starting a new bisect.

This is not funny; it means I either cannot reconfigure, or I'm losing
my childhurd...grmbl.  Sorry for not noticing this earlier!

Greetings,
Janneke



devel-hurd.tmpl
Description: Binary data

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com