OpenTLE Devel



31 พฤษภาคม 2547

LinNeighborhood Come Back

หลังจากที่ได้ถอดถอน LinNeighborhood ออกจาก LinuxTLE 5.5 เนื่องจากความไม่เข้ากันของ Samba 3 ได้มีเสียงบ่นและเรียกร้องโปรแกรมตัวนี้กันมากเหลือเกิน รับปากหลายคนไว้ว่าจะเอากลับมาให้ วันนนี้เลยลองหา patch มาดู ได้มาสอง patch จาก Debian และ Mandrake เลย build เข้า samila ให้ได้ใช้งานกันครับ อยู่ในส่วนของ updates นะครับ

# apt-get update
# apt-get install LinNeighborhood

หวังว่าคงมีความสุขกับการทำงานร่วมกับ Window$ อีกครั้งหนึ่งนะครับ

28 พฤษภาคม 2547

Big changes on libsigc++

libsigc++ มีสามเวอร์ชัน 1.0, 1.2, และ 2.0 ทั้งสามตัวลงขนานกันได้ แต่ที่ผ่านมาผมไม่ได้ทำให้ลงขนานกันเลยใช้ชื่อแพ็กเกจตัวเดียว ซึ่งจะส่งผลให้ติดตั้งอัปเกรดทับเวอร์ชันเก่ากว่าไปเรื่อยๆ

ตอนนี้เท่าที่เช็ค มีแอพพลิเคชันที่บางตัวที่จำเป็นต้องใช้ 1.0 บางตัวใช้ 1.2 และบางตัวใช้ 2.0 ดังนั้นจึงต้องทำแพ็กเกจ libsigc++ ให้ลงขนานกันได้ทั้งสามตัว ผมเลยจะ rename package libsigc++ เป็นชื่อใหม่ ตามนี้นะครับ

libsigc++ = libsigc++ 1.0
libsigc++12 = libsigc++ 1.2
libsigc++2 = libsigc++ 2.0

ผลของการ rename นี้กระทบแพ็กเกจทั้งหมด 12 ตัวใน samila repository main, update, และ kitty .. 11 จาก 12 ตัวอยู่ในการดูแลของผมเอง จะ rebuild / upgrade ให้เสร็จในวันศุกร์นี้

ส่วนอีกหนึ่งตัวที่เหลือคือ arnthai หลังจากเปลี่ยนมาใช้แพ็กเกจ libsigc++ ในชื่อใหม่แล้ว ผมขอฝากให้คนที่ดูแลอยู่ rebuild ใหม่เพื่อปรับ dependencies ด้วยครับ

อย่างไรก็ตาม ทั้งหมดนี้ผมจะส่งเข้า proposed-updates และเข้า unstable หากเห็นว่าเป็นการอัปเกรดแพ็กเกจเยอะเกินไป จะไม่เอาเข้า updates ก็ได้ครับ (จริงๆ แล้วแพ็กเกจส่วนใหญ่ของ libsigc++ ผู้ใช้ทั่วไปไม่ได้ติดตั้งใช้งาน เอาเข้า updates ก็คงไม่กระทบผู้ใช้มากนัก) แต่อยากให้เอาเข้า testing เพื่อทะเลเวอร์ชันถัดไปจะได้เปลี่ยนไปใช้ libsigc++ ชื่อใหม่ทั้งหมด จะได้ไม่มีปัญหาตามมาอีกในภายหลัง

เรื่องนี้สอนให้รู้ว่า มีไลบรารีจำนวนไม่น้อยที่ติดตั้งขนานกันได้หลายๆ เวอร์ชัน เวลา build แพ็กเกจไลบรารีเวอร์ชันใหม่ ควรรอบคอบเป็นพิเศษ ดูให้ดีว่าเวอร์ชันใหม่นั้นมันตั้งใจออกมาเพื่ออัปเกรดตัวเก่า หรือติดตั้งขนานกับตัวเก่า

27 พฤษภาคม 2547

IP Telephony for LinuxTLE

ข่าวดีครับ เมื่อเช้านี้ผมได้รับ E-Mail จากทาง ม.สงขลา เรื่องการมอบผลงานวิจัย ให้ผนวกไปกับ LinuxTLE รุ่นถัดไป (จริงๆ แล้วได้มีการพูดคุยกันก่อน LinuxTLE 5.5) ขอยกเนื้อความใน E-mail มาให้ดูครับ

Dear Dr. Virach,

First of all, congratulations of the success of Linux TLE opening ceremony.
I would like to contribute one of my work to Linux TLE.
Regarding to funding of NECTEC to my IP Telephony project (which has been closed), I would propose to put this IP Tel software on Linux TLE. We have tested with the latest version of TLE. We use Java to develop this one.
So, its function seems to similar to Microsoft NetMeeting. Its features are:
- real time voice and video communications,
- chat,
- drag-and-drop file transfer,
- can work with point-to-point, and using a server.
- based on IETF SIP (Session Initiation Protocol),
- work on both IPv4 and IPv6.
Please let me know you idea.

Best Regards,
Sinchai

ผมเคยชมผลงานชิ้นนี้มาแล้วครั้งหนึ่งก็ประทับใจครับ สามารถใช้งานได้จริงๆ และถือว่าดีมากระดับหนึ่ง

26 พฤษภาคม 2547

TLC และ TLE

สรุปคร่าวๆ เท่าที่เข้าใจนะครับ

Thai Linux Core (TLC) เป็นโครงการในการพัฒนาแกนของดิสโตรไทย แนวคิดก็คือให้ดิสโตรแต่ละค่ายในเมืองไทยมาร่วมมือกันพัฒนาแพ็กเกจแกนกลาง เน้นเรื่องของภาษาไทย เพื่อให้รูปแบบการทำงานของแกนส่วนภาษาไทยมีลักษณะเหมือนๆ กัน รวมไปถึงเรื่อง UI และการสนับสนุนภาษาไทยในแอพพลิเคชันแต่ละตัวด้วย นอกจากนี้ TLC อาจช่วยเป็นตัวกลางในการส่งแพตช์กลับเข้าต้นน้ำ (credits to นักพัฒนาโดยตรง) และเก็บรักษาแพตช์ที่เราเห็นว่าจำเป็น แต่ทางต้นน้ำปฏิเสธ ผลของ TLC ก็หวังไว้ว่าจะทำมีคนเข้ามาร่วมพัฒนาแกน ลดภาระของการพัฒนาดิสโตรที่เดิมแยกกันทำ และกระตุ้นให้ดิสโตรไทยเข้ามาใช้แกนกลางตัวเดียวกัน เป็นการลดปัญหาเรื่อง dependencies ที่ต่างกัน ซึ่งอาจช่วยให้ดิสโตรต่างค่ายสามารถแชร์การใช้งานแพ็กเกจเดียวได้ด้วย

ภาระงาน TLC จะหนักไปในเรื่องการพัฒนาแกนของดิสโตร (คือมีเป้าหมายที่ดิสโตร - แพ็กเกจ) โดยทำหน้าที่รวมรวมเอาซอร์ส แพตช์ ที่เสถียรเอามาใช้ และอัปเดตตามต้นน้ำอย่างต่อเนื่อง หน้าที่ของ TLC จึงไม่ซ้ำซ้อนกับ LTN / TLWG ซึ่งมุ่งพัฒนาแอพพลิเคชันเป็นตัวๆ ไป

ที่คุยกันไว้คร่าวๆ TLC จะเก็บต้นฉบับ แพตช์ และไฟล์ที่จำเป็นในการสรา้งแพ็กเกจของแอพพลิเคชัน โดยจัดโครงสร้างเป็น

TLC/
app-aaa/
app-aaa-1.0-tar.gz
app-aaa-1.0-do-something.patch
app-aaa-1.0-do-another-thing.patch.gz
app-aaa-1.0.spec
app-aaa-1.0.dsc
app-aaa-1.0.ebuild
MD5SUM
....
app-bbb/
app-bbb-1.2.3-tar.bz2
app-bbb-1.2.3.spec
...

ตอนนี้ยังไม่ชัดเจนว่า แอพพลิเคชัน ไลบรารี ฯลฯ ตัวไหน เวอร์ฃันใด จะรวมอยู่ใน TLC บ้าง แต่กะเอาไว้ว่าฐานของ TLC จะมาจาก TLE 5.5 และดิสโตรอื่นๆ (ถ้ามี) ต่อยอดไปเรื่อยๆ โดยการอัปเดต/อัปเกรดจะดึงซอร์สมาจากต้นน้ำโดยตรง ..

ในส่วนของ TLE รีลีสหน้าจะใช้แกนจาก TLC แน่นอน และตั้งใจไว้ว่าจะไม่อิงดิสโตรสากลตัวใดตัวหนึ่งเหมือนที่ผ่านมา แต่จะพัฒนาจาก TLE 5.5 และดึงซอร์สจากต้นน้ำโดยตรง หวังเอาไว้ว่า TLE รีลีสหน้า (และ/หรือตัวถัดไป) จะไม่ใช่ดิสโตรที่ based on Red Hat หรือ Fedora Core อีกต่อไป แต่จะเป็น rpm-based distro ที่สมบูรณ์ตัวนึง มีแนวทางการพัฒนาของตัวเอง เทียบได้ในระดับเดียวกับดิสโตรสากลอย่าง Fedora Core, Mandrake หรือ SuSE :)

ขาดตกบกพร่องประการใด comment ได้ครับ ..

เสนอความคิดเรื่องการพัฒนาและ repository

จากที่สอบถามพี่เทพ ต้น แล้วก็อ่านเรื่อง repository และการพัฒนาของ Debian ผมเห็นว่าวิธีการเขาดูชัดเจนดี เลยอยากเสนอให้เราใช้วิธีการพัฒนาทะเลแบบเดียวกันกับที่ Debian ใช้ ..

ก่อนอื่น ขอสรุปเรื่องการพัฒนาดิสโตรของ Debian อย่างคร่าวๆ ได้ตามนี้ครับ

ดิสโตรของ Debian เขาแบ่งออกมาเป็นสามอัน คือ stable (woody) testing (sarge) และ unstable (sid) ทั้งสามอันนี้รันขนานกันไป การพัฒนาดิสโตรจะเริ่มต้นที่ unstable ซึ่งผู้ร่วมพัฒนาช่วยกันพัฒนาแพ็กเกจใส่ลงไปได้ตลอดเวลา unstable จึงมีการเปลี่ยนแปลงได้ทุกวัน เมื่อแพ็กเกจใน unstable บางตัวได้รับการทดสอบจนคุณภาพผ่านตามเงื่อนไขที่กำหนด (ตรงนี้เดี๋ยวต้องมาคุยกันอีกที) แพ็กเกจนั้นจะย้ายมาเก็บใน testing

เมื่อแพ็กเกจใน testing ได้รับการทดสอบลงตัวแล้ว ผู้ดูแลดิสโตรจะกำหนดให้ testing อยู่ในสถานะ 'frozen' ซึ่งอนุญาตให้ย้ายแพ็กเกจ unstable เข้ามาใน testing ได้ถ้าเป็นการแก้บั๊กเท่านั้น หลังทดสอบ testing ในสถานะ frozen จนเป็นที่พอใจแล้ว ผู้ดูแลดิสโตรจะกำหนดให้ testing อยู่ในสถานะ 'deep freeze' ซึ่งอนุญาตให้ย้ายแพ็กเกจจาก unstable เข้ามาใน testing ได้ถ้าเป็นการแก้บั๊กที่จำเป็นสำหรับการติดตั้งระบบทั้งหมด เมื่อทุกอย่างสมบูรณ์พร้อมรีลีสแล้ว testing ก็จะถูกเปลี่ยนเป็น stable

วงจรข้างบนนี้เรียกว่าเป็นวงจรของการพัฒนาดิสโตร ซึ่งจะรันต่อเนื่องตลอดเวลา แต่เพราะ stable เองก็อาจจะมีบั๊กหลังจากรีลีสแล้ว จึงมีวงจรอีกอันสำหรับอัปเดต stable โดยแพ็กเกจที่แก้บ๊ักของตัว stable จะเข้าไปอยู่ใน proposed-updates (note: บางแพ็กเกจผู้ร่วมพัฒนาอาจจะอัปโหลดเข้าทั้ง unstable และ proposed-updates) .. กรณีของ Debian เมื่อผู้ดูแลดิสโตรมั่นใจว่าแพ็กเกจใน proposed-update มีความสมบูรณ์ก็จะเอาไปรวมเข้ากับ stable แล้วเพิ่มตัวเลข revision ของ stable ขึ้นไป (เช่น 3.0 ก็จะเป็น 3.0r1 3.0r2 ...)

ข้อเสนอสำหรับลินุกซ์ทะเล
ที่จริงพวกเราเคยคุยกันเรื่องนี้หลายทีแล้ว และได้ข้อสรุปบางอย่างออกมาบ้าง ผมอยากเสนอให้เราใช้วิธีการเดียวกันในการพัฒนา Debian ผสมกับระบบที่เราใช้อยู่ในปัจจุบัน และระบบ people ที่เราจะใช้กันต่อจากนี้

ผู้ร่วมพัฒนาแต่ละคนจะมีที่พื้นที่เก็บ repository ของตัวเอง (a.k.a 'people') เป็นพื้นที่ส่วนหนึ่งของ ftp.opentle.org ให้สร้างไดเรกทอรี่ unstable/ สำหรับเก็บแพ็กเกจ unstable ในการพัฒนาดิสโตร และสร้างไดเรกทอรี่ตาม codename ของ stable สำหรับเก็บแพ็กเกจ propose-updates ของ stable นั้นๆ พร้อมกับ genbasedir ให้ apt-get ได้ด้วย เพื่อให้ผู้ร่วมพัฒนารายอื่นสามารถ apt-get แพ็กเกจล่าสุดได้ง่าย ตัวอย่าง repository ของผมก็จะได้ประมาณ

kitty/
unstable/
RPMS.main/
SRPMS.main/
patches/ <---- to store *.patch
samila/
RPMS.proposed-update/
SRPMS.proposed-update/
patches/
andaman/
RPMS.proposed-update/
SRPMS.proposed-update/
patches/
phiphi/
RPMS.proposed-update/
SRPMS.proposed-update/
patches/

ผู้ดูแลดิสโตร (ต้น/โชค ?) คัดเลือกแพ็กเกจจาก unstable ของ people ย้ายเข้า aowthai ซึ่งถือเป็นตัว testing

kitty/unstable/RPMS.main --> aowthai/RPMS.main
kitty/unstable/SRPMS.main --> aowthai/SRPMS.main

..and so on..

note: แพ็กเกจที่อยู่ใน unstable ของ people ไม่จำเป็นต้องเข้า aowthai ทุกตัว อย่างที่บอกตอนต้นว่า ตรงนี้ขึ้นกับเงื่อนไขที่เราจะตั้งกันต่อจากนี้ (เช่น เรื่องสัญญาอนุญาต สิทธิบัตร ความเสถียร ผลกระทบกับตัวอื่นๆ ฯลฯ) และขึ้นกับดุลพินิจของผู้ดูแลดิสโตร

เมื่อ aowthai สมบูรณ์พร้อมรีลีสแล้วก็เปลี่ยนชื่อไดเรกทอรี่เป็น codename ตัว stable ถัดไปได้เลย เป็นอันจบวงจรการพัฒนาดิสโตรหนึ่งวง จากนั้นก็สร้างไดเรกทอรี่ aowthai ขึ้นใหม่สำหรับวงจรพัฒนาตัวถัดไป

มาถึงเรื่องการอัปเดตตัว stable กันบ้าง ลินุกซ์ทะเลจะไม่เอาแพ็กเกจ proposed-update รวมเข้าใน stable เหมือน Debian ซึ่งแปลว่า RPMS.main และ SRPMS.main ของตัว stable จะไม่ถูกแตะต้องอีกเลยหลังจากรีลีสไปแล้ว แต่จะใช้วิธีย้ายแพ็กเกจที่เสถียรแล้วจาก proposed-updates เข้ามาเก็บใน updates แทน (note: updates ควรจะเสถียรเท่าๆ กับ stable) วงจรการอัปเดต stable ก็จะได้ประมาณนี้

kitty/samila/RPMS.proposed-updates --> samila/RPMS.proposed-updates --> samila/RPMS.updates
kitty/samila/SRPMS.proposed-updates --> samila/SRPMS.proposed-updates --> samila/SRPMS.updates

มีคำแนะนำอะไรเพิ่มเติม เชิญที่ comment ครับ

New Webmin for TLE 5.5

ได้ทำการติดตั้ง SSL ให้เป็น Default และทำการเพิ่ม Module ที่น่าสนใจเช่น
Network Utility, Snort IDS, Certificate Management (OpenSSL),
OpenLDAP Server เป็นต้น สำหรับตัวนี้ต้องติดตั้ง Perl-Net-SSLeay ด้วย ซึ่งมีให้
Download แล้ว

http://ftp.opentle.org/pub/linux-tle/5.5/i386/TLE/RPMS.chw/webmin-1.140_3-1_secure_chw.tle55.noarch.rpm
http://ftp.opentle.org/pub/linux-tle/5.5/i386/TLE/RPMS.chw/perl-Net-SSLeay-1.25-1.1_chw.tle.noarch.rpm


สำหรับ Source Code เดี๋ยว Upload เสร็จแล้วจะบอกอีกที

25 พฤษภาคม 2547

Webmin for Linux TLE 5.5

สามารถติดตั้งได้บน Linux TLE 5.5 แล้วนะครับ ใช้ Config การทำงานของ Linux TLE 5.5 ในรูปแบบ Server ได้

http://ftp.opentle.org/pub/linux-tle/5.5/i386/TLE/RPMS.chw/webmin-1.140_1-1.1_chw.tle55.noarch.rpm

http://ftp.opentle.org/pub/linux-tle/5.5/i386/TLE/SRPMS.chw/webmin-1.140_1-1.1_chw.tle55.src.rpm

ใน release ถัดไปจะสามารถ Login โดยใช้ SSL เป็นค่า Default เลยครับ ถ้าไม่มีปัญหาอะไรก็จะ Upload ขึ้นมาเร็วๆ นี้ครับ

Spell checking ใน OpenOffice.org

สองสามวันมานี้ ลองดูเรื่องของ spell checking ใน OpenOffice.org เขาใช้ MySpell ของ Kevin Hendricks เลยลอง download ดิกของ en_US มาดู อืมมมม วิธีการของภาษาอังกฤษไม่ยากเลย แต่เอามาลองกับภาษาไทยโดยเอาข้อมูลมาจาก LEXiTRON แล้วยังไม่เวิร์คเลย (เฮ้ออออ) สงสัยต้องแกะ OpenOffice.org อีกสักยกหนึ่ง (งานประจำอีกแล้ว) วันนี้สงสัยต้องกลับไปฝันอีกแน่เลย เหอ เหอ เหอ

ว่าด้วยเรื่อง release-version ของ kitty.in.th

เรื่องแจ้งให้ทราบจาก kitty.in.th repo. ครับ

แพ็กเกจคอนทริบิวต์จาก kitty.in.th กำหนดชื่อไฟล์ตามฟอร์แมต name-version-release.kit.i386.rpm สำหรับ precompiled binary และ name-version-release.src.rpm สำหรับ src rpm. โดยส่วนของ release จะมีฟอร์แมตย่อยต่างๆ กันไป ขึ้นกับเลขเวอร์ชันและเลขรีลีสของแพ็กเกจนั้นๆ

  1. กรณีที่โปรแกรมนั้นไม่ระบุเลขรีลีส ก็จะรันเลขรีลีสเอง (x >= 1) เช่น program v.1.0 ก็จะได้ไฟล์ชื่อ program-1.0-x.kit.i386.rpm หากมีการ rebuild ซ้ำในเวอร์ชันเดียวกัน ก็จะ x++ ทุกครั้งที่ rebuild และจะ reset เป็น 1 อีกครั้งเมื่อโปรแกรมนั้นเปลี่ยนเวอร์ชัน

  2. กรณีที่โปรแกรมระบุเลขรีลีส ส่วนของ release จะใช้ฟอร์แมต 'รีลีสของโปรแกรม.x' เช่น program v.1.0 rel. 2 จะได้ชื่อไฟล์เป็น program-1.0-2.x.kit.i386.rpm

  3. กรณีที่โปรแกรมยังอยู่ในรุ่นพรีรีลีส เช่น alpha, beta, pre, rc ฯลฯ จะใช้ '0.' นำหน้าเพื่อให้ชัดเจนว่าเป็นรุ่นที่ต่ำกว่ารีลีสจริง เช่น program v.1.0 rc 3 ก็จะได้ชื่อไฟล์เป็น program-1.0-0.rc3.x.kit.i386.rpm


ยังมีกรณีย่อยๆ อีกเล็กน้อยเช่น cvs ซึ่งกำหนดเลขรีลีสได้ยาก cvs ควรมีเลขรีลีสสูงกว่าตัว stable ปัจจุบันและต้องน้อยกว่า พรีรีลีล หรือ stable ถัดไปซื่งเป็น unknown .. ตอนนี้แพ็กเกจ cvs ของ kitty.in.th ยังไม่มีรูปแบบตายตัว ก็เลยไม่ค่อยอยากรีลีส ถ้าไม่จำเป็นจริงๆ ครับ .. วิธีนึงที่คิดออกคือใช้วิธีแยกเป็นสองแพ็กเกจคือ program กับ program-cvs แล้วกำหนด obsolete กันตามช่วงการรีลีส หรือ c/o .. หรืออีกวิธีคือใช้ epoch คุมไปเลย .. ผมยังไม่ได้ลองใช้ว่าแบบไหนดีกว่า .. ใครมีความคิดดีๆ ลองเสนอกันเป็น convention ไว้ก็ดีครับ

24 พฤษภาคม 2547

AowThai ก้อนแรก

วันนี้ rsync RPMS ขึ้น AowThai ไปถือเป็นชุดแรก ยังไม่ครอบคลุมเป็น base ซะส่วนใหญ่เดี๊ยวจะทำ stage ให้ Contributor ...

ftp://ftp.opentle.org/pub/linux-tle/aowthai/i386/