OpenTLE Devel



30 มิถุนายน 2547

AowThai Base 30/06/2004

ตอนนี้ระบบ update Samila 5.5 ไปเป็น AowThai 5.5.90 ใช้งานได้ระดับหนึ่งแล้วครับ สามารถทดสอบได้โดยใช้

rpm ftp://ftp.nectec.or.th/pub/linux-distributions/Linux_TLE/ aowthai/i386/TLE main

ตอนนี้มีระบบหลักๆ ดังนี้

- Base
- Gcc 3.3.3
- Kernel 2.6.7
- Gnome 2.6.1
- kde 3.2.3

ทดสอบกันนะครับรายงานมาด้วยยิ่งดี

25 มิถุนายน 2547

AowThai Base 25/06/2004

ตอนนี้ AowThai Base ได้เพิ่ม

KDE 3.2.3

เข้าไปเรียบร้อยแล้วครับ สนใจทดสอบก็เชิยได้เลย ส่วน ftp.nectec ณ เวลานี้ผมยังไม่สามารถ sync ขึ้นไปได้กำลังติดต่อพี่ที่ดูแลอยู่ครับ ต้อง apt จาก opentle.org ไปก่อน

21 มิถุนายน 2547

AowThai Base 21/06/2004

สำหรับผู้สนใจร่วมพัฒนา LinuxTLE ตอนนี้สามารถ update ระบบจาก LinuxTLE 5.5 ไปเป็น AowThai Base ได้แล้วครับซึ่งขณะนี้จะประกอบด้วย ฺ


  • system base

  • Xorg base

  • Gnome 2.6.1 base



แนะนำสำหรับท่านที่จำนำ base ไปพัฒนาต่อทำได้โดยการติดตั้งระบบ LinuxTLE 5.5 แบบ mini ก่อนเมื่อลงเสร็จให้แก้ /etc/apt/sources.list ให้ชี้ไปที่

rpm ftp://ftp.nectec.or.th/pub/linux-distributions/Linux_TLE/ aowthai/i386/TLE main

แล้วทำการ update

ยังไม่แนะนำให้ลง base นี้เป็นระบบหลังครับ เพราะยังไม่ เสถียรมากนัก

16 มิถุนายน 2547

Comment from P' Thep

เรื่องของเรื่องคือ อาทิตย์ก่อน พี่เทพเข้า #TLWG บอกให้ช่วยทดสอบบั๊กของ GTK เรื่องหนึ่ง เพื่อให้เข้าไปยืนยันบั๊ก ปรากฏว่า ผมลองแล้วไม่เห็นเกิด คุยกันไปมา เลยพบว่า บั๊กนี้ หลังจากที่พี่เทพทำแพตช์แก้แล้ว MrChoke เอาแพตช์ของพี่เทพ มาแพตช์ แล้วออกอัพเดททันที พี่เทพก็เลยบ่นและให้คำแนะนำทำนองว่า "เพราะลินุกซ์ทะเล ทำอะไรให้ผู้ใช้หมด เลยเป็นการปิดบังบั๊กไม่ให้ผู้ใช้เห็น ทำให้ผู้ใช้ติดตามบั๊กไม่ได้ เพราะฉะนั้นทีมพัฒนาลินุกซ์ทะเล ต้องทำหน้าที่ในส่วนนี้แทนผู้ใช้ด้วย"

ก็เลยเอาข้อคิดนี้มาฝากกันครับ สรุปว่า ใครเอาแพตช์ที่อยู่ในช่วงการติดตามบักมาใช้ ขอให้ช่วยติดตามบักนั้นๆ ด้วย เช่นเข้าไปยืนยันบัก และทดสอบแพตช์แล้วรายงานผล เป็นต้น

14 มิถุนายน 2547

Static-only library

ปรกติไลบรารี จะแยกเป็นสองแพ็กเกจคือ name เก็บไฟล์ dynamic library และ name-devel เก็บ static library + header + devel doc.

พอดีว่าเจอไลบรารีบางตัวที่ติดตั้งเฉพาะ static (*.a) อย่างเดียว ไม่มี dynamic (*.so*) ก็เลยมานั่งคิดว่าจะแพ็กเกจไฟล์พวกนี้ยังไงดี ปรึกษากับคุณกำธรแล้วตกลงว่า ไลบรารีที่ไม่มี dynamic (*.so*) จะแพ็กเกจเฉพาะ name-devel อย่างเดียว เผื่อว่าในอนาคตมี dynamic จะได้ไม่เกิดปัญหาอะไรภายหลัง

มีความเห็นอย่างไรบ้างครับ ?

11 มิถุนายน 2547

Zabbix Monitoring Tool

เพิ่ง Build เสร็จแบบสดๆ ร้อนกันเลย ตัวนี้เป็น Monitoring Tool ที่ดูท่าทางจะเก่งเอาเรื่องเลยทีเดียวครับ

การติดตั้ง Zabbix จะต้องมี Package ต่อไปนี้อยู่ในเครื่องก่อนแล้วคือ mysql, httpd หรือ apache, และ net-snmp ซึ่งทั้งหมดจะมีอยู่ใน Linux TLE 5.5 อยู่แล้ว

ลองใช้กันดูนะครับว่ามัน Work ใหม ผมก็กำลังลองใช้อยู่เหมือนกัน :-P

Download Package

http://ftp.opentle.org/pub/linux-tle/5.5/i386/TLE/RPMS.chw/zabbix-1.0-1.1_chw.tle.i586.rpm

http://ftp.opentle.org/pub/linux-tle/5.5/i386/TLE/RPMS.chw/zabbix-agent-1.0-1.1_chw.tle.i586.rpm
http://ftp.opentle.org/pub/linux-tle/5.5/i386/TLE/RPMS.chw/zabbix-phpfrontend-1.0-1.1_chw.tle.i586.rpm

Download Source Code

http://ftp.opentle.org/pub/linux-tle/5.5/i386/TLE/SRPMS.chw/zabbix-1.0-1.1_chw.tle.src.rpm


Web Site: www.zabbix.com

09 มิถุนายน 2547

Code Name

LinuxTLE รุ่นถัดไปยังไม่ได้จัดหาชื่อเลยครับ ร่วมกันเสนอเข้ามา ผมจะได้ทำ vote ต่อ ให้ดีเสนอเหตุผล พร้อมรายละเอียดเล็กมาด้วยนะครับ

04 มิถุนายน 2547

Do we need to put 'requires' ?

อธิบายนิด .. เวลา build rpm บนทะเล โปรแกรม rpmbuild จะทำ autodepend/autorequire ให้อัตโนมัติ โดย autodepend จะใส่ชื่อ dynamic library ที่โปรแกรมนั้นจำเป็นต้องใช้ในบรรทัด requires ให้เอง ทำให้เราไม่จำเป็นต้องกรอกบรรทัด requires ก็ได้ โดยส่วนตัวผมกรอกไว้เพื่อให้ง่ายต่อการติดตั้งผ่าน rpm จะได้รู้ว่าต้องติดตั้งกับแพ็กเกจไหน (autodepend ระบุแต่ไฟล์ library ไม่ใช่ package ของ library)

แต่ ถ้าทะเลใช้ apt เป็นหลัก เราอาจจะไม่จำเป็นต้องกรอก requires เองก็ได้ เพราะ apt จะหาให้เองว่า library นั้นๆ อยู่ใน package ตัวไหน เลยอยากเสนอให้ เลิกระบุ requires สำหรับ library package .. วิธีนี้ ข้อเสียจะเกิดตอนที่ติดตั้งด้วยคำสั่ง rpm เพราะผู้ใช้อาจจะไม่รู้ว่า library ที่ต้องการนั้นอยู่ใน package ไหน (แต่ถ้าเซียน rpm พอ หรือ google เป็น ก็จะหาเองได้อยู่ดี) .. ข้อดีคือ สะดวกสำหรับ packager/contributor ด้วย และง่ายต่อการจัดการ library package หากต้องเปลี่ยนชื่อแพ็กเกจในภายหลัง

ต้องย้ำอีกนิดว่า เสนอให้เลิกระบุ 'เฉพาะ library package' เท่านั้น ถ้า require binary / executable ยังต้องกรอกเหมือนเดิม และ buildrequires ยิ่งควรจะกรอกให้ละเอียดๆ เพื่อเวลา build ในภายหลังจะได้ไม่พลาดครับ

03 มิถุนายน 2547

package naming again !

เรื่องชื่อ package ของ library อีกสักครั้งนะครับ อยากได้ความเห็นเพิ่มเติม พี่เทพแนะนำมาว่าตั้งชื่อตามเวอร์ชันของไลบรารีเลยก็น่าจะเข้าใจได้ง่ายดี เช่น libaaa version 1.0 อาจจะตั้ง package name เป็น 'libaaa10' แทนที่จะตั้งเป็น libaaa เฉยๆ

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

ประเด็นปลีกย่อยคือ เราอาจจะต้องคิดเผื่อไว้สองกรณีนะครับ คือ กรณีที่ library ต่างเวอร์ชันกันลงขนานกันได้ กับ กรณีที่ต่างเวอร์ชันกันลงขนานกันไม่ได้ สองแบบนี้ 'อาจจะ' ตั้ง package name ไม่เหมือนกัน เหตุผลก็คือ กรณีที่ลงขนานกันไม่ได้ ควรจะใช้ package name เดียวไปตลอด เพื่อให้อัปเกรดต่อเนื่องอัตโนมัติ ในขณะที่กรณีที่ลงขนานกันได้จะตั้ง package name ตามเวอร์ชันอย่างที่กล่าวมาข้างต้น

ปัญหาคือ เราไม่สามารถทราบล่วงหน้าว่า library เวอร์ชันถัดไปจะลงขนานกันได้หรือเปล่า จึงกำหนด package name ที่เหมาะสมไม่ได้ จนกว่า library เวอร์ชันถัดไปจะออกมา .. คิดดูหยาบๆ แล้ววิธีการอาจจะเป็นแบบนี้นะครับ

1. ให้ตั้ง package name ตามปกติ โดย 'ไม่ต้อง' ใส่เลยเวอร์ชันก่อน
เช่น libaaa v.1.0 ก็จะได้

libaaa v.1.0
name: libaaa
version: 1.0

2. ถ้าเวอร์ชันถัดไป ลงขนานกันไม่ได้ ก็ไม่ต้องเปลี่ยนแปลงอะไรเลย
เช่น libaaa v.1.1 ลงขนานกับ libaaa v.1.0 ไม่ได้ ก็จะกำหนด

libaaa v.1.1
name: libaaa
version: 1.1

.. เมื่อสั่ง upgrade / install ก็จะทับ libaaa v.1.0

3. ถ้าเวอร์ชันถัดไป ลงขนานกันได้ ให้กำหนด package name ตามเวอร์ชัน และ obsolete / provide package เดิมด้วย
เช่น libaaa v.1.1 ลงขนานกับ libaaa v.1.0 ได้ ก็จะ rename package โดย

libaaa v.1.0
name: libaaa10
version: 1.0
provides: libaaa
obsoletes: libaaa

และ

libaaa v.1.1
name: libaaa11
version: 1.1

ทีนี้หากมีอัปเกรดของ lib แต่ละตัวก็วิ่งไปตาม branch ของตัวเองไป เช่น libaaa v.1.0.1 ก็จะไปอัปเดต libaaa10

วิธีปฏิบัติอาจจะยุ่งๆ สักหน่อย แต่ผมว่าได้ความเป็นระเบียบและได้ภาพที่ชัดเจนดี

มีความเห็นกันอย่างไรบ้าง ?

01 มิถุนายน 2547

kitty.in.th repository updated (01.06.05)

สรุปการเปลี่ยนแปลงของ kitty repo ในรอบสัปดาห์ที่ผ่านมาครับ
- ย้ายแพ็กเกจที่คอนทริบิวต์ทั้งหมดเข้า unstable (~220 ตัว)
- อัปเดต rpm เข้า proposed-update (~45 ตัว)
- อัปเดต kitty-extras (~20 ตัว)
- อัปเดต kitty-extras-2 (~50 ตัว)

ผลของการเปลี่ยนชื่อ libsigc++ อาจจะกระทบกับคนที่ติดตั้ง libsigc++-1.2.5 ไปแล้วก่อนหน้านี้ วิธีอัปเดตเป็นตัวใหม่ให้สั่ง

apt-get remove libsigc++

apt (ควร) จะถอด libsigc++-1.2.5 ออกและอัปเดตเป็น libsigc++12-1.2.5 ให้อัตโนมัติ พร้อมทั้งอัปเดตโปรแกรมที่ require lib ตัวนี้ให้ด้วยครับ

โปรแกรมที่ proposed-updates (samila) ที่สำคัญๆ ก็มี :
libsigc++ กับตระกูล gtkmm2 ทั้งหมด (อัปเดตชุดนี้แล้วฝาก rebuild arnthai ด้วยครับ)
cdrecords, cdda2wav, mkisofs 2.01a30
alsa-lib, alsa-utils, alsa-tools, alsa-oss 1.0.5
gthumb 2.4.0
k3b 0.11.10

kitty-extras มีอัปเดต vlc เป็น 0.7.2 ครับ

แจ้งให้ทราบอีกอย่างคือ apt server ของ kitty.in.th ระงับการใช้งานชั่วคราวนะครับ ด้วยทาง ISP กำลังจัดระบบสายใหม่ คาดว่าเสร็จภายในวันนี้ครับ