Theppitak's blog

My personal blog.

24 พฤษภาคม 2549

Prepared for GNOME 2.15

สุดสัปดาห์ที่ผ่านมา พยายาม build GNOME 2.15 แล้วก็เริ่มงานแปลใน head แต่พอดีมีญาติแต่งงาน ก็ถูกขัดจังหวะเล็กน้อย กลับจากงานก็มา build ต่อ ต้องมีการแก้เพิ่มเติมประปราย ตามธรรมดาของ CVS snapshot บางแพกเกจก็เป็นผลมาจากการปรับ GNU coding standard ทำให้ autotools ที่ไม่ sync จะ build ไม่ผ่าน ต้องเข้าไป hard code บางอย่างใน Makefile.am (เช่น เรื่อง datarootdir) รวมทั้ง CVS ก็ค้างขณะ checkout ไม่รู้ว่าเป็นที่เน็ตเรา หรือว่าเป็นที่ server

เท่าที่ดูคร่าวๆ ความเปลี่ยนแปลงที่เห็นชัดที่สุดในขณะนี้ คือที่ gnome-icon-theme ที่มีการใช้ icon จาก Tango Desktop Project ทำให้ดูแปลกหูแปลกตาเล็กน้อย (IMO: ดูซีดๆ สู้ stock icon ของ GTK+ ไม่ได้)

กับที่พบระหว่างแปลเพิ่ม ก็คือ GTK+ 2.9 ที่ merge เรื่องการพิมพ์เข้ามาแล้ว ตามแนวทางใน Project Ridley ซึ่งจะไล่ obsolete GNOME library ต่างๆ ที่ทำงานซ้ำซ้อนกัน โดย merge เข้าใน GTK+ แหล่งเดียว (สารภาพว่าติดคำว่า "TLE Must Die" มาจาก "LibgnomeMustDie" นี่แหละ ในระหว่างที่พยายามหาคำสั้นๆ มาเรียกแนวคิดที่ยืดยาว หุๆ)

เริ่มอุ่นเครื่องแปล GNOME 2.16 ไปบ้างแล้ว ต่อไปคงทยอยแปลต่อไปเรื่อยๆ โดยอาจสลับกับ debian-installer บ้าง ไว้ให้เคลียร์งานบางชิ้นที่แบ่งเวลาไปอาทิตย์ละหลายวันได้ก่อน ค่อยทำงาน development มากกว่านี้ :P

22 พฤษภาคม 2549

"Upstream"

ตั้งแต่กลับมาอยู่ขอนแก่น รู้สึกว่าได้พบผู้คนหลากหลายมากขึ้น คนอ่าน blog ของผมก็หลากหลายตามไปด้วย เรื่องบางเรื่อง เขียนแล้วคนกลุ่มหนึ่งเข้าใจตรงกัน แต่อีกกลุ่มอาจจะเข้าใจไปอีกอย่างก็มี เลยคิดว่า นานๆ เอาประเด็นเก่ามาพูดซ้ำบ้าง ก็คงจะดี

อย่างวันนี้ นึกถึงประเด็นของคำว่า ต้นน้ำ (upstream) เช่น การทำงานกับ GNOME ของผม อาจจะไม่เป็นที่ฮือฮาเมื่อเทียบกับการได้ไป Ubuntu Localisation Sprint ซึ่งใน blog วันนั้น คุณ donga ก็ถามในเชิงว่านี่เป็นการทำงานที่ต้นน้ำ จนต้องตั้งคำถามว่า จะเหลืออะไรให้ Linux TLE ทำ กับอีกครั้งหนึ่ง เมื่อได้ ตอบสัมภาษณ์ Blognone โดยพูดถึงคำว่า ต้นน้ำ ก็มีคนมาทักเมื่อเจอกัน โดยพูดถึงการทำงานกับ Ubuntu หรือ Debian ของผมในทำนองว่าเป็นการทำงานที่ ต้นน้ำ อย่างที่ตอบสัมภาษณ์ ทั้งที่ความจริงแล้ว ทั้งสองงานนั้น ยังไม่ใช่ ต้นน้ำ ที่มุ่งจะพูดถึง

อันที่จริง สำหรับคุณ donga นั้น พอเข้าใจความหมายของแกอยู่ ว่าพูดเทียบกับ Linux TLE ซึ่งถ้าเทียบแล้ว Ubuntu ก็ถือเป็นต้นน้ำ แต่ Ubuntu ก็ยังใช้ Debian เป็นแหล่ง และ Debian เองก็ยังเอาซอร์สโค้ดต่างๆ มาจากโครงการที่เป็นต้นน้ำจริงๆ อีกที และ ต้นน้ำ ที่ผมมุ่งสู่ ก็คือต้นน้ำเหล่านั้น มากกว่าที่จะเป็น Ubuntu หรือ Debian เอง

อันที่จริง หลายคนคงเข้าใจความหมายผมอยู่ แต่คนอื่นๆ ที่ยังไม่คุ้นกับคำเหล่านี้ อาจจะต้องอธิบายเพิ่ม

คิดว่าความเข้าใจเรื่องนี้ ค่อนข้างสำคัญต่อการเกิดของชุมชนโอเพนซอร์สในเมืองไทย เพราะในภาพที่ปรากฏต่อสาธารณชนในขณะนี้ คำว่า คนทำงานลินุกซ์ คงจะหมายถึงทีมงาน Linux TLE เพียงกลุ่มเดียวเท่านั้น โดยเร็วๆ นี้ ก็มีทีม SIPA เพิ่มขึ้นมาอีกหนึ่ง ซึ่งทั้งหมดนั้น ก็มุ่งไปที่การสร้าง distro ทั้งนั้น ยังมีภาพของ ต้นน้ำ จริงๆ ที่ซึ่งเป็นหัวใจของโอเพนซอร์ส น้อยมากๆ

มองในแง่หนึ่ง ความเข้าใจตรงนี้ อาจเป็นการกลั่นกรองบุคลากรก็ได้ โดยคนที่เข้าใจเรื่อง ต้นน้ำ จริงๆ ก็ต้องได้ศึกษากลไกต่างๆ ของห่วงโซ่อาหารในลินุกซ์มาพอสมควร แต่ถ้าความตระหนักเรื่องนี้ ไม่ขยายตัวออกไป ก็คงไม่สามารถปลดล็อคปัญหา ใครให้ใครรับ ในวงการโอเพนซอร์สได้

ไหนๆ ก็ได้พูดถึงเรื่องนี้แล้ว โยงไปถึงประเด็นอย่าง OS แห่งชาติ หน่อยก็ดี คือรู้สึกว่า การที่ยังมีการยกประเด็นนี้ขึ้นในที่ต่างๆ ทั้งๆ ที่นานาประเทศเขาได้ก้าวข้ามความเข้าใจขั้นนี้ไปแล้ว ดังจะเห็นในการประชุมต่างๆ หรือในแหล่งต้นน้ำ จะเริ่มเห็นเพื่อนบ้านของเราให้ความสำคัญกับต้นน้ำมากกว่า distro แห่งชาติกันแล้ว อาจสะท้อนให้เห็นการย่ำอยู่กับที่ของเรา บางที แนวคิดเรื่อง "TLE must die" ที่ผมเคยบรรยายด้วยคำพูดว่า "ที่สุดแห่งกระบี่ คือไร้กระบี่ ที่สุดแห่งทะเล คือไร้ทะเล" น่าจะยังต้องพูดย้ำกันต่อไป

16 พฤษภาคม 2549

Typespeed: First Contact

นานจนแทบลืมไปแล้ว ว่าได้ทำภาษาไทยใน typespeed (เกมฝึกพิมพ์ดีด) เอาไว้ (debian/changelog ของแพกเกจเก่าที่ build ไว้ ลงวันที่ 1 ธันวา 2546 และอีกทางหนึ่ง คุณพูลลาภก็ ทำเหมือนกัน โดยไม่ได้นัดหมาย) แล้วก็ได้ส่ง patch ไปที่เจ้าของโครงการแล้วด้วย แต่ไม่มีคำตอบใดๆ จนกระทั่งเมื่อวันก่อน ผู้ดูแลโครงการคนใหม่ได้ตอบกลับมา ว่าจะ apply patch ผม แล้วก็ทดสอบกันไปกันมา ในระหว่างพักแปล d-i จนในที่สุด typespeed ใน CVS ก็สนับสนุนภาษาไทยเรียบร้อย

สองปี ยังไม่สาย :-)

ปล. งานแปล d-i เกือบผ่าน level 2 แล้ว รอเขา commit คำแปลให้ แล้วก็ ขาดชื่อเมืองต่างๆ ใน iso-codes แต่เรื่องนี้คงยาว น้องๆ gnome-applets po-locations น่ะแหละ แต่อาจจะดีหน่อย ที่อาจจะหาข้อมูลอ้างอิงง่ายกว่า เพราะเป็นรายชื่อเขตการปกครอง ไม่ใช่ชื่อสนามบินที่ไม่รู้คนจะไปสร้างที่ไหนไว้มั่ง แต่ก็ต้องปล่อยไว้ก่อน ตอนนี้ข้ามไปทำ level 3 ละ (ทีม Ubuntu ยังสนใจร่วมแปลอยู่มะ อิๆ)

15 พฤษภาคม 2549

Debian L10N Level 1 Passed

อาทิตย์ที่ผ่านมา ได้คำแปล debian-installer จาก Ubuntu โดยคุณ Roys Hengwatanakul (ไม่รู้ตัวสะกดภาษาไทยแฮะ) ทำให้เปอร์เซ็นต์แปลเพิ่มขึ้นโขอยู่ เมื่อวานวันอาทิตย์ เลยถือโอกาสลุยต่อจนครบ 100% ทำให้ภาษาไทยใน debian ผ่าน level 1 แล้ว ต่อไปก็ลุย level 2 ต่อละ (tasksel, newt เสร็จไปแล้วเหมือนกันเมื่อคืนนี้)

ความเคลื่อนไหวอื่นๆ คือ thailatex 0.3.7-1 ย้ายเข้า testing (etch) ไปเมื่อวันพฤหัสฯ (11 พ.ค.) ตามมาด้วย gtk-im-libthai 0.1.3-3 วันนี้

กะว่า อาทิตย์นี้คงลุย debian ให้ได้มากที่สุด อาทิตย์หน้าคงเริ่ม build GNOME 2.16 แล้วก็ตามแปลใน HEAD ละ (วันนี้ tarballs due 2.15.2 แล้ว)

13 พฤษภาคม 2549

สวัสดี พ.ศ. ๒๕๔๙

ในคืนอุบัติแห่งองค์มหาศาสดาของโลก และคืนเริ่มต้นแห่งพุทธศักราช ขอรำลึกถึงพระปัญญาคุณ พระวิสุทธิคุณ และพระกรุณาธิคุณ แห่งองค์พระสัมมาสัมพุทธเจ้า ที่ได้ทรงประกาศพระธรรม อันเป็นทางแห่งความรู้แจ้ง

อย่างที่เคยเขียนเมื่อวิสาขบูชาปีที่แล้ว หากนับตามนิยามพุทธศักราช คืนนี้ก็เป็นคืนขึ้นปีใหม่ของชาวพุทธ สวัสดีปีใหม่ จะอวยพรอะไรกันดี.. ขอปัญญาจงเกิดกับท่าน ขอสันติสุขจงเกิดกับโลก :-)

08 พฤษภาคม 2549

Intro to Debian Process (ตอนจบ)

ตอนก่อน:

เอาละ พูดถึงกระบวนการทั่วไปมาแล้ว ถ้าคุณสนใจจะ build debian package สำหรับซอฟต์แวร์โปรดของคุณ ก็อาจจะเริ่มจากฝึก build จาก New Maintainers' Guide แต่ถ้าคุณ build คล่องถึงระดับหนึ่งแล้ว การจะเริ่มอัปโหลดแพกเกจเข้า debian จะมีประเด็นต่างๆ ที่จะถูกตรวจสอบเยอะแยะ เพื่อให้เป็นไปตาม Debian Policy เครื่องมือหลักที่จะช่วยคุณได้ก็คือ lintian และ linda ซึ่งเป็นเครื่องมือตรวจสอบความถูกต้องของ debian package คล้ายๆ กับ lint สำหรับโปรแกรมภาษา C น่ะแหละ

ต่อไปนี้เป็นประเด็นที่พบบ่อย พึงระวังขณะสร้าง debian package:

  • CVS directories ควรลบไดเรกทอรี CVS ทั้งหลายที่ยังตกค้างอยู่ โดยเฉพาะถ้าคุณ maintain debian script ใน CVS เรื่องนี้เป็นเรื่องที่พบบ่อยมาก ถ้าไม่อยากถูกตรวจพบด้วยข้อหาตื้นๆ ก็ควรเตือนตัวเองเสมอๆ ให้ลบ CVS ก่อน build ซึ่งหมายความว่า คุณไม่ควร build debian package ภายใน CVS working copy แต่ควรคัดลอกออกมา build ข้างนอก จะสะดวกกว่า
  • native/non-native ถ้าแพกเกจที่คุณ build มี upstream source ไม่ใช่เป็นแพกเกจเฉพาะใช้ใน debian ก็ควรจะ build เป็นแบบ non-native โดยใช้ upstream tarball ที่เปลี่ยนนามสกุลจาก .tar.gz เป็น .orig.tar.gz และ ห้ามแตะต้อง ข้อมูลใดๆ ใน upstream tarball ปล่อยให้เป็น pristine source ไว้ แล้ว dpkg-buildpackage จะสร้าง .diff.gz เพื่อใช้เพิ่ม debian script ให้ ถ้ามันไม่ gen แบบนี้ให้ ก็ควรตรวจสอบ ว่าคุณได้เปลี่ยนชื่อ upstream tarball (หรือทำ symlink ในอีกชื่อ) ก่อน build หรือไม่ มีเหตุผลดีๆ มากมายในการทำให้แน่ใจว่ามีการแยก .orig.tar.gz กับ .diff.gz เช่น ทุก release จะใช้ pristine source ร่วมกัน ต่างกันแค่ .diff.gz ที่ใช้เพิ่ม debian script ทำให้ประหยัดเนื้อที่และ bandwidth ในการ upload/download รวมทั้งสะดวกในการตรวจสอบความเปลี่ยนแปลงเทียบกับ upstream และระหว่าง release ต่างๆ เป็นต้น
  • copyright เรื่องนี้จะถูกตรวจสอบเป็นเรื่องแรกๆ เลย คุณควรแน่ใจว่ากรอกข้อมูลเกี่ยวกับแหล่งต้นตอของ upstream source, ข้อมูลลิขสิทธิ์ของ upstream และไฟล์ต่างๆ ที่ใช้ประกอบการสร้าง debian package ต้องให้ครบ และที่สำคัญ อย่าลืมใส่ข้อความ disclaimer ที่มีมากับข้อความลิขสิทธิ์เสมอ และถ้าแพกเกจนั้นใช้ license ที่เป็นที่รู้จัก เช่น GPL, LGPL, BSD, Artistic ก็ไม่ต้องใส่ไฟล์ COPYING มา แต่เขียนข้อข้อความสั้นๆ ที่ท้าย disclaimer ว่าใน debian ให้อ่านข้อความเต็มของ license ดังกล่าวได้ที่ /usr/share/common-licenses/<license> มีการพูดถึงรายละเอียดเรื่องนี้ใน กระทู้ ใน debian-legal
  • debhelper comment ชาว debian เขาค่อนข้างเนี้ยบกับแฟ้ม debian/rules ว่าควรจะสะอาด คุณอาจใช้ debhelper ช่วยสร้างสคริปต์ต่างๆ โดยอัตโนมัติ รวมทั้ง debian/rules นี้ด้วย แต่คำสั่ง dh_* ที่คุณไม่ใช้ คุณอาจเสียดายที่จะลบทิ้ง โดยใส่คอมเมนต์ไว้ ขอบอกว่าอย่าทำ ควรลบทิ้งไปเลย ถ้าไม่อยากถูก sponsor ตีมือ
  • debian/rules พยายามให้ debian/rules สะอาดที่สุดเท่าที่จะทำได้ แฟ้มนี้โดยเนื้อหาก็คือ Makefile นั่นเอง แต่พยายามอย่าใช้ script เฉพาะกิจมากเกินไป เช่น สั่ง cp ตรงโน้น rm ตรงนี้ แต่ควรพยายามใช้คำสั่ง dh_* ของ debhelper ถ้าเป็นไปได้ ซึ่งถ้าตรวจสอบดีๆ จะพบว่ามีคำสั่งครอบคลุมหลายๆ งานที่ไม่คิดว่าจะมีใน distro อื่น (ทุกคำสั่งมี man page ให้อ่าน!) ซึ่งการใช้คำสั่งเหล่านี้ นอกจากจะง่ายแล้ว ยังมีผลดีตรงที่ไม่เสี่ยงต่อการละเมิด debian policy ด้วย โดยเฉพาะเวลามี transition ใหญ่ๆ ของระบบ (เช่น Xorg 7 ที่ผ่านมาหมาดๆ) จะเห็นประโยชน์ชัดมาก โดยแค่ build แพกเกจใหม่ด้วย debhelper ตัวใหม่ โดยแทบไม่ต้องแก้อะไรเลย ก็ transition ไปกับหมู่คณะได้แล้ว
  • NMU ตรงนี้เป็นประเด็นปลีกย่อย สำหรับกรณีที่คุณ build package ของคนอื่น เพื่อแก้ปัญหาอะไรบางอย่าง พยายามทำตาม policy เรื่อง Non-maintainer upload กล่าวคือ ใช้เลข release แบบทศนิยม และระบุ * NMU หรือ * Non-Maintainer Upload ใน debian/changelog ด้วย

โดยส่วนใหญ่แล้ว หลายประเด็นสามารถถูกตรวจสอบได้ด้วย lintian/linda ดังนั้น คุณจะพบว่า สำหรับ debian แล้ว tool ตรวจสอบดังกล่าว ไม่ได้เป็นแค่เครื่องมือประกอบ แต่กลายเป็นส่วนหนึ่งของ build process เลยทีเดียว (ผมจึงใช้ debuild แทน dpkg-buildpackage และถ้าจะให้ดี ควรใช้ pbuilder สำหรับแพกเกจที่เสี่ยงต่อการลิงก์ไลบรารีผิดที่) ถึงจะเป็นแค่ warning ก็ไม่ควรเพิกเฉย

ฟู่.. ปาดเหงื่อหน่อย ในที่สุดก็เขียนจบ ขอขอบคุณที่ติดตามครับ ทั้งหมดนี้คงยังครอบคลุมไม่หมด แต่คงพอให้เห็นภาพของกระบวนการทั้งหมด ความละเอียดลออของ debian ทำให้ยังรักษาคุณภาพไว้ได้ แม้จะเป็นการทำงานร่วมกันของคนเรือนพันทั่วโลก มี package จำนวนมโหฬาร และ architecture ต่างๆ ให้ดูแลมากมาย เข้ามาในโลกของ debian แล้ว จะรู้สึกถึงการใช้คอมพิวเตอร์ให้เป็นประโยชน์มากมาย ความเป็นอัตโนมัติของ apt ยังเป็นแค่มุมมองสำหรับผู้ใช้เท่านั้น แต่สำหรับนักพัฒนา ก็จะพบความเป็นอัตโนมัติอีกหลายอย่าง เช่น build daemon ที่ช่วยการ port และ transition ต่างๆ โดยอัตโนมัติ หรือการเคลื่อนของแพกเกจจาก unstable มา tesing โดยอัตโนมัติ พร้อมกันนั้น ความเข้มแข็งของระเบียบปฏิบัติต่างๆ สำหรับมนุษย์ ก็ทำให้คนที่กระจายอยู่ในส่วนต่างๆ ของโลก สามารถทำงานร่วมกันได้อย่างแน่นแฟ้น

07 พฤษภาคม 2549

Firefox Story

วันนี้ ทำเรื่อง firefox เป็นหลัก โดยพยายามทำ patch ตัดคำด้วย pango ต่อ คราวนี้จัดโครงสร้างของลูปเล็กน้อย โดยใช้ iterator วิ่ง แทนการคำนวณ index ใหม่ในทุกรอบ กะว่าเพิ่มประสิทธิภาพได้อีกนิดหน่อย แล้วก็ใช้วิธีปรับโค้ดของ nsJISx4501LineBreaker ให้ทำงานร่วมกับ pango linebreaker แทนที่จะแทนที่ด้วย pango ทั้งดุ้น

พอได้แล้ว ก็ file Mozilla Bug #336959 เสนอ patch แรก ที่ทำงานได้แล้ว

นอกจากนี้ ไหนๆ ก็ได้ติดต่อ bugzilla แล้ว ก็เลยแวะไปที่ debian แล้วเปิด Bug #366306 (xulrunner) และ Bug #366308 (firefox) เพื่อเสนอ libthai patch ที่ทำไว้ เมื่อวันก่อน ปรากฏว่า Mike Hommey ผู้ดูแลแพกเกจทั้งสอง ตอบมาอย่างรวดเร็วทันใจว่า ไม่รับ โดยบอกว่า ควรจะ link กับ libthai ไปเลย ไม่ใช่ dlopen() หรือถ้าจะไม่ต้องการให้ firefox depend on libthai ก็ควรทำเป็น component ต่างหากออกมา อืม.. กำลังคิดอยู่ ว่าจะตอบเขาว่ายังไงดี.. ในใจนั้น ไม่คิดว่าการ dlopen() เป็นวิธีที่สวยเท่าไรเหมือนกัน แต่ถ้าคิดถึงปัจจัยอื่นๆ เช่น การลาก libthai มาเป็น dependency ผู้ใช้ภาษาอื่นจะว่ายังไง หรือ mozilla จะยอมรับไหม กับถ้าจะทำเป็น component ต่างหาก โครงสร้างส่วนตัดคำของ mozilla ก็ยังไม่พร้อม ต้องแก้เพิ่มเติมก่อน..

ท่าจะยาวแฮะ.. ไปลุ้น pango patch แทนดีมะ :-/

06 พฤษภาคม 2549

Intro to Debian Process (3)

ตอนก่อน:

ก่อนจะพูดเรื่องประเด็นปลีกย่อยของการสร้างแพกเกจ คิดว่าพูดถึงกระบวนการต่อให้จบก่อนดีกว่า

Debian Developer

ก่อนอื่น พูดถึงสภาเจไดก่อน ผู้ที่จะมีสิทธิ์อัปโหลดแพกเกจเข้า debian pool ได้ จะต้องเป็นผู้ที่มี OpenPGP public key อยู่ใน debian keyring ซึ่งกว่าจะได้เอากุญแจไปคล้องได้ ก็ต้องผ่านกระบวนการทำงานต่างๆ เพื่อเป็นการรับประกันว่า คนคนนั้นมีคุณสมบัติเพียงพอที่จะร่วมพัฒนา debian อย่างมีคุณภาพได้ ซึ่งผมก็ได้รับการบอกเล่ามาว่า ต้องใช้เวลาเป็นปีๆ จนหลายคนถอดใจไปก่อน ดังนั้น เวลาที่ได้พบ Debian Developer ผมจึงรู้สึกเหมือน apprentice ได้พบเจได หรือสาวกได้พบนักบุญถ้าเปรียบเทียบกับประชากรในศาสนา ปานนั้นเลย

ตอนนี้ มี Debian Developer (DD) ร่วมๆ สองพันคน จากทั่วโลก นี่ถ้านับ maintainer ทั้งหลายที่ยังไม่ได้ตำแหน่ง DD อีกเยอะแยะ รวมกับ user community ที่คึกคัก ก็นับได้ว่า debian เป็นโครงการที่ใหญ่และเป็นสากลมากโครงการหนึ่ง

ผู้ที่จะเข้าเป็น DD ได้ จะต้องผ่าน New Maintainer Process หรือเรียกย่อๆ ว่า NM (อย่าเพิ่งแปลกใจครับ debian เขายังมีตัวย่ออีกเยอะให้ใช้ เป็นการเจาะจงศัพท์เทคนิคว่าไม่ใช่หมายถึงคำทั่วไป) ซึ่งถ้าดูจาก Checklist แล้ว จะเห็นว่าผู้สมัคร NM จะต้องมีประสบการณ์ทำงานกับ debian มาระยะหนึ่งแล้ว จนมี DD ไว้วางใจ สามารถ advocate ผู้สมัครคนนั้นได้ แล้วก็จะมีการสอบสัมภาษณ์ความเข้าใจในปรัชญาต่างๆ ของ debian ทดสอบความชำนาญต่างๆ จนผ่านทุกขั้นตอนแล้ว จึงจะได้เป็น DD

Web of Trust

ใน NM checklist จะมีขั้นตอนแรกๆ ขั้นตอนหนึ่งที่สำคัญที่ควรกล่าวถึง คือการยืนยันตัวตนด้วย OpenPGP key ที่มี Web of Trust ที่แน่นหนา กล่าวคือ มีผู้เซ็นยืนยันตัวตนของเจ้าของกุญแจเยอะพอ ว่ากุญแจนี้เป็นของคนคนนี้จริงๆ (เพราะในอินเทอร์เน็ต ใครๆ ก็สร้างกุญแจได้ โดยอาจจะแอบอ้างว่าเป็นของธนาคารก็ได้ ถ้าไม่มีการตรวจสอบตัวตนดังกล่าว เป็นต้น แต่กรณีของธนาคาร อาจใช้การตรวจสอบผ่าน Certificate Authorities (CA) มากกว่าแบบกระจายด้วย Web of Trust) และกุญแจนี้ จะใช้ในการเซ็นรับรอง debian package ในวันข้างหน้าเมื่อได้ทำหน้าที่ DD ว่าแพกเกจมาจาก maintainer ตัวจริง หรือมาจากแหล่งที่เชื่อถือได้ โดยตรวจสอบกับ public key ที่ไปคล้องไว้ใน debian keyring เพื่อกันแพกเกจปลอมปนที่จะเข้ามาใน debian pool

เพื่อรับประกัน web of trust นี้ เวลาคน debian มีการพบปะกัน จึงมักถือโอกาสจัด Key Signing Party เสมอๆ เพราะเป็นโอกาสที่จะได้เซ็นยืนยันเจ้าของกุญแจเมื่อได้พบตัวจริง โดยในการเซ็นนั้น จะมีขั้นตอนการตรวจสอบพอควร เช่น ต้องมีบัตรประจำตัวประชาชน หรือหนังสือเดินทาง มายืนยัน (เพื่อไม่ให้มีใครมาแอบอ้างง่ายๆ ว่าตนคือบิล เกตส์ หรือ RMS อะไรทำนองนี้) รวมทั้งคอมพิวเตอร์ที่ใช้ในการเซ็นก็จะต้องแน่ใจว่าปราศจากการปลอมแปลงคำสั่งด้วย

Package Sponsoring

แล้วก็มาถึงคำถามยอดฮิตที่ผมถูกผู้อ่าน blog ถาม และผมเองก็เคยสงสัยเป็นอันดับต้นๆ เหมือนกัน ว่าการ sponsor แพกเกจมันหมายถึงอะไร

จากขั้นตอนการกลั่นกรอง DD สุดหินที่ได้กล่าวไป ความจริงเป็นการรับประกันคุณภาพของ debian เอง แต่ขณะเดียวกัน ก็เปิดโอกาสให้ผู้ที่ไม่ได้เป็น DD ได้ร่วมพัฒนาได้ด้วย โดยอาจจะแสดงความจำนงขอดูแลแพกเกจได้ แต่เมื่อจะอัปโหลดเข้า debian pool ซึ่งจำเป็นต้องมีลายเซ็น DD กำกับ ก็สามารถร้องขอให้ DD คนใดคนหนึ่งช่วยเซ็นและอัปโหลดให้ได้ ซึ่งการเซ็นและอัปโหลดให้ดังกล่าวนี่แหละ ที่เรียกว่าการ sponsor แพกเกจ

แน่นอนว่าลายเซ็นนั้น หมายถึงการร่วมรับผิดชอบกับ maintainer ด้วยส่วนหนึ่ง แม้ข้อมูลในแพกเกจจะแสดงชื่อของ maintainer ว่าเป็นเจ้าของ ไม่ใช่ DD เจ้าของลายเซ็น แต่ในคิวสำหรับอัปโหลดก็จะมีการบันทึกไว้ ว่า DD คนไหนอัปโหลดให้ ดังนั้น กว่าจะเซ็นให้ได้ DD จะต้องตรวจสอบคุณภาพของแพกเกจเสียก่อน โดยปกติจึงมีการตรวจแก้ก่อนอัปโหลด

มีหลายวิธีที่ maintainer จะหา sponsor อาจจะด้วยการทำงานร่วมกันอย่างใดอย่างหนึ่งมาก่อน เช่น คุยงานผ่าน mailing list หรือคุยกันในงานประชุม แต่กรณีอย่างนั้นคงครอบคลุมแพกเกจทั้งหมดได้ยาก โดยทั่วไปจึงมักใช้ debian-mentors mailing list หรือ IRC ห้อง #debian-mentors ที่ irc.debian.org รายละเอียดต่างๆ อ่านได้จาก debian-mentors FAQ

เนื่องจากความยากลำบากในการหา sponsor เมื่อได้ sponsor แล้ว จึงควรถือโอกาสแก้ปัญหาต่างๆ ในแพกเกจตามที่ sponsor ชี้ให้ได้มากที่สุด ด้านหนึ่ง เป็นโอกาสที่จะได้ปรับปรุงคุณภาพแพกเกจ และอีกด้านหนึ่ง เป็นการลดภาระที่ต้องรบกวน sponsor อีกบ่อยๆ ในอนาคต

NEW Queue

สำหรับการอัปโหลดที่มีไฟล์ซอร์สใหม่ที่ไม่เคยอยู่ใน debian pool มาก่อน (ไม่นับ debian diff ที่เป็นเพียงการออก release ใหม่) แพกเกจที่อัปโหลดจะเข้าไปอยู่ในคิว NEW เพื่อรอตรวจรับโดยทีม ftp-master โดยเป็นการตรวจสอบทั่วไปเพื่อกันความเสี่ยงเรื่องการฝังม้าโทรจันหรืออะไรทำนองนี้ โดยปกติจะใช้เวลาเฉลี่ยไม่เกินหนึ่งเดือน

แพกเกจใหม่ที่ผ่านการตรวจรับในคิว NEW แล้ว หรือแพกเกจที่เพียงออกรุ่นใหม่โดยไม่ได้มีซอร์สที่ไม่เคยอัปโหลดมาก่อน ก็จะตรงเข้าสู่ incoming เพื่อรอเข้าสู่ unstable หรือ experimental pool ต่อไป แล้วแต่กรณี

เมื่อแพกเกจสถิตอยู่ใน unstable ครบกำหนด 10 วันโดยไม่มี bug ร้ายแรง แพกเกจนั้นก็จะเคลื่อนเข้าสู่ testing โดยอัตโนมัติ

วันนี้ยาวหน่อย เพราะจะเก็บรายละเอียดที่สำคัญให้ครบ ตอนหน้าน่าจะเขียนถึงประเด็นที่พบบ่อยในการ build debian package ได้

03 พฤษภาคม 2549

New firefox + libthai Patch

คั่นรายการด้วยข่าว:

  • เมื่อวานนี้ เขียน firefox + libthai patch ใหม่ ส่งเข้า Mozilla Bug #7969 โดยจัดโครงสร้างโค้ดใหม่ แยกภาษาไทยออกมาเป็นสัดเป็นส่วน คิดว่าน่าจะทำให้ง่ายต่อการเปลี่ยน engine เป็นอย่างอื่น เช่น ICU ด้วย นอกจากนี้ โครงสร้างที่มีระเบียบหน่อย น่าจะง่ายต่อการ check-in แต่ patch นี้ก็ยังแค่ชั่วคราวสำหรับ 1.8 branch ถ้า upstream ไม่รับ (เนื่องจาก freeze แล้ว) ก็ส่งไปฝากตาม distro ต่างๆ (ดูเหมือน Mark กำลัง ประสานงาน อยู่) ส่วนใน Trunk นั้น คิดว่าจะลองเสนอให้ใช้ Pango/Uniscribe
  • gtk-im-libthai ผ่านการตรวจรับเข้า sid แล้ว

กะว่า สุดสัปดาห์นี้จะลองทำ firefox ที่ trunk ดู.. แต่คอมไพล์โค้ดใหญ่ๆ หลายๆ branch แบบนี้ อยากได้เครื่องแรงๆ ฮาร์ดดิสก์โตๆ ชะมัด T_T

02 พฤษภาคม 2549

Intro to Debian Process (2)

ตอนก่อน:

ว่ากันด้วยเรื่อง debian process ต่อ มาดูเรื่องการเป็นเจ้าของแพกเกจกันบ้าง

ความเป็นเจ้าของในแพกเกจ

ความเป็นเจ้าของในแพกเกจ หมายถึงสิทธิ์ในการอัปโหลดแพกเกจนั้นๆ โดยเป็นผู้ดูแล bug ต่างๆ ในแพกเกจด้วย (คือมีสิทธิ์ปิด bug และได้รับรายงาน bug ทางเมล)

การเปลี่ยนแปลงความเป็นเจ้าของแพกเกจเกิดได้หลายแบบ โดยส่วนใหญ่จะทำผ่าน bug ใน wnpp (Work-Needing and Prospective Packages) ดังนี้:

  • request for package หรือ RFP เป็น bug wnpp ที่ผู้ใช้เสนอแพกเกจใหม่ที่ยังไม่มีใน debian รอคอย maintainer ที่สนใจมาทำให้
  • new package เป็นการเปิด bug wnpp ชนิด ITP (Intent To Package) หรือเปลี่ยนสถานะ bug ชนิด RFP เป็น ITP และปิด bug ด้วยการอัปโหลดแพกเกจตัวแรก
  • orphan เมื่อผู้ดูแลไม่สามารถดูแลแพกเกจต่อ ก็อาจสละแพกเกจโดยเปิด bug wnpp ชนิด O (Orphaned) รอจนกระทั่งมีผู้สนใจมารับช่วงต่อ มิฉะนั้น Debian QA Team จะรับดูแลให้ชั่วคราว แพกเกจไหนที่ orphan นานๆ อาจถูกตัดออกจาก debian ในที่สุด
  • adopt คือการรับช่วงดูแลแพกเกจกำพร้าต่อ โดยเปลี่ยนสถานะ bug wnpp ชนิด O เป็น ITA (Intent To Adopt) แล้วปิด bug ด้วยการอัปโหลดแพกเกจรุ่นใหม่ โดยเขียน changelog ว่า * New Maintainer (Closes: #xxxxx)

สำหรับผู้ดูแลแพกเกจที่เริ่มไม่มีเวลา อาจประกาศหาผู้ดูแลต่อแทนการ orphan ได้ โดยเปิด bug wnpp ชนิด RFA (Request For Adoption) หรือ RFH (Request For Help) แทนก็ได้ โดย RFH จะอ่อนกว่า เป็นการขอความช่วยเหลือโดยยังเจตนาจะดูแลแพกเกจต่อไป ส่วน RFA เป็นการประกาศหาผู้ดูแลต่อ โดยในระหว่างนี้ จะยังคงดูแลบ้างถ้ามีโอกาส และ O เป็นการประกาศชัดว่าจะไม่ดูแลต่ออีกเลย

นอกจากนี้ ยังมีความเป็นเจ้าของร่วมแบบไม่ใช่ maintainer คือเป็น uploader โดยมีสิทธิ์เทียบเท่า maintainer ในแง่การอัปโหลดและการดูแล bug อีกด้วย มีหลายแพกเกจที่ช่วยกันดูแลหลายคน ก็อาศัย uploader หลายๆ คนช่วยกันทำผ่าน alioth svn

แต่ก็ไม่ใช่เฉพาะ maintainer และ uploader เท่านั้นที่สามารถอัปโหลดได้ ในบางครั้ง maintainer อาจยื่นมือช่วยแก้แพกเกจอื่นได้ อาจจะเพราะ bug มันเกี่ยวเนื่องกับแพกเกจของตัวเอง หรือเป็นการแก้ไขในเชิงนโยบายภาพรวม หรือด้วยเหตุผลใดก็แล้วแต่ การอัปโหลดดังกล่าวเรียกว่า Non-Maintainer Upload (NMU) โดยในกรณีเช่นนี้ เลข debian release จะใช้จุดทศนิยม เช่น จาก 0.3.3-4 เป็น 0.3.3-4.1 และ bug ต่างๆ ที่ NMU แก้ จะยังไม่ปิด จนกว่า maintainer จะอัปโหลดแพกเกจตัวใหม่เป็น 0.3.3-5 โดย Acknowledge NMU และปิด bug ที่ NMU แก้ ถ้าพิจารณาแล้วว่ายอมรับการแก้นั้น หรืออาจจะใช้วิธีอื่นก็อธิบายใน changelog

ดังนั้น สำหรับผู้มาใหม่ และสนใจจะช่วยทำแพกเกจ อาจจะมองหา bug wnpp ชนิด O, RFA หรือ RFP โดยถ้าเจอแพกเกจที่สนใจ และแน่ใจในวรยุทธ์การ build package ของตนแล้ว ก็อาจจะอาสาโดยเปลี่ยนสถานะ bug ชนิด O หรือ RFA เป็น ITA หรือ bug ชนิด RFP เป็น ITP แล้วเตรียมอัปโหลดแพกเกจ

คราวหน้ามาต่อเรื่องประเด็นปลีกย่อยที่จะพบขณะทำแพกเกจ

01 พฤษภาคม 2549

Intro to Debian Process (1)

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

เอกสารแนะนำ

ก่อนอื่น แนะนำเอกสารที่ควรอ่านเสียก่อน สำหรับผู้สนใจเข้าร่วมพัฒนาเดเบียน:

  • New Maintainers' Guide ให้ข้อมูลเบื้องต้น สำหรับผู้ที่สนใจจะเริ่มทำแพกเกจสำหรับเดเบียน โดยเริ่มตั้งแต่สอนวิธีเริ่มสร้าง debian package จาก source ตั้งต้น, การตรวจสอบแพกเกจด้วย lintian, การอัปโหลด, การออกแพกเกจรุ่นใหม่
  • Developer's Reference เป็นเอกสารอ้างอิงสำหรับนักพัฒนาเดเบียนทุกคน มีเรื่องต่างๆ ที่จำเป็น ตั้งแต่ขั้นตอนการสมัครเป็น maintainer, หน้าที่ของ debian developer, การจัดการ key, การจัดการแพกเกจ, การ sponsor แพกเกจ, internationalization
  • Debian Policy Manual เป็นเอกสารที่จำเป็นต้องอ่าน ถ้าจะ build package เพราะ policy เป็นแนวทางการทำงานร่วมกันของนักพัฒนาเดเบียนเรือนพันทั่วโลก โดยไม่เกิดปัญหาความเข้ากันไม่ได้ระหว่างแพกเกจต่างๆ เริ่มตั้งแต่ filesystem hierarchy standard, ระบบเมนู, นโยบายสำหรับระบบย่อยต่างๆ ที่มีองค์ประกอบหลายชิ้น เช่น Emacs, Java, Perl, Python ฯลฯ

ยังมีเอกสารน่าสนใจอื่นๆ อีก ที่ Debian Developers' Corner

สายการพัฒนา

ทีนี้ สำหรับผู้อ่านที่ยังไม่ทราบวิธีนับรุ่นและสายการพัฒนาต่างๆ ของเดเบียน ขอเกริ่นคร่าวๆ ว่าเดเบียนขณะใดๆ มีสายการพัฒนาหลักๆ 3 สาย คือ stable, testing และ unstable โดย stable คือรุ่นที่คงตัว ไม่ค่อยมีการเปลี่ยนแปลง ยกเว้น security update หรือการแก้ bug ที่ร้ายแรง, testing คือรุ่นทดสอบที่รอปล่อยตัวเป็น stable รุ่นถัดไป มีการเปลี่ยนแปลงค่อนข้างบ่อย แต่ผ่านการทดสอบใน unstable มาระยะหนึ่งแล้ว ส่วน unstable คือรุ่นใหม่สุดที่เปลี่ยนแปลงบ่อยสุด แพกเกจต่่างๆ จะเริ่มอัปโหลดเข้าที่นี่ เพื่อรอ bug report ระยะหนึ่งก่อนย้ายเข้า testing แต่ทั้งนี้ ยังมีแหล่งอัปโหลดที่ใช้ทดสอบในหมู่นักพัฒนากันเองที่ experimental ที่มักใช้เป็นที่พักของแพกเกจที่มีองค์ประกอบหลายส่วน เช่น GNOME ที่ต้องรอย้ายเข้า unstable พร้อมกันเป็นชุด และรุ่นต่างๆ ที่เคลื่อนผ่านสายการพัฒนาเหล่านี้ จะมีชื่อรหัส (codename) ซึ่งได้มาจากชื่อตัวละครใน Toy Story โดยมี sid (เด็กที่ชอบทำลายของเล่น) เป็น unstable เสมอ รายละเอียดอ่านได้จาก FAQ

สำหรับผู้ดูแลแพกเกจ การอัปโหลดแพกเกจโดยปกติจึงมีสองที่ คือ unstable และ experimental แต่โดยทั่วไป ถ้าแพกเกจนั้นไม่ได้เกาะเกี่ยวกับใครมาก หรือไม่ใช่การเปลี่ยนแปลงขนานใหญ่ในโครงสร้างภายใน ก็มักจะอัปโหลดเข้า unstable และเมื่อแพกเกจสถิตอยู่ใน unstable ได้ระยะหนึ่งโดยไม่มี release-critical bug ก็จะย้าย (migrate) เข้า testing โดยอัตโนมัติ

คำที่เกี่ยวกับแพกเกจ

มีคำศัพท์เบื้องต้นที่ควรรู้เกี่ยวกับแพกเกจคือ:

  • upstream หมายถึงผู้พัฒนาต้นน้ำ ได้แก่เจ้าของโครงการต่างๆ ที่พัฒนาและเผยแพร่ซอร์สโค้ดต้นฉบับ เช่น GNOME, KDE, X.org
  • maintainer หมายถึงผู้ดูแล debian package โดยเอาซอร์สจาก upstream มาเพิ่มสคริปต์สำหรับสร้างเป็น debian package และคอยปรับรุ่นใหม่ๆ ใน debian ตามการออกรุ่นของ upstream
  • debian-native หมายถึงแพกเกจที่ไม่มี upstream source แต่เป็นแพกเกจที่พัฒนาภายใน debian เอง เช่น debhelper ซึ่งเป็นเครื่องมือช่วยสร้าง debian package ซึ่งแพกเกจเหล่านี้ จะนับรุ่นเสมือนเป็น upstream โดยไม่มีเลข debian release ต่อท้าย ในขณะที่แพกเกจที่เป็น non-native จะนับรุ่นโดยใช้รุ่นของ upstream ประกอบกับเลข debian release เช่น 0.3.3-4 หมายถึง upstream เป็นรุ่น 0.3.3 และเป็นการทำ debian package รุ่นที่ 4 ใน debian โดยอ้างอิง upstream รุ่นเดียวกันนี้
  • pristine source หมายถึง source tarball ของ upstream ซึ่งใน debian จะแยกออกจากสคริปต์ต่างๆ ที่ใช้สร้างแพกเกจ (ต่างจาก .src.rpm ของ redhat ที่จะรวมทั้ง source ทั้ง RPM spec มาในก้อนเดียวกัน) โดยมี suffix เป็น ".orig.tar.gz" เช่น จาก upstream source thaibrowser-0.3.3.tar.gz ก็จะเปลี่ยนชื่อเป็น thaibrowser-0.3.3.orig.tar.gz เพื่อแยกให้รู้ความแตกต่างจาก tarball อื่นๆ และที่เรียกว่า pristine source (ซอร์สบริสุทธิ์) ก็เพราะ debian จะไม่แตะต้องข้อมูลใน .orig.tar.gz นี้เลย ถ้าจะ patch ก็จะแยก patch ต่างหาก แม้แต่ script ที่ใช้ build package ก็จะอยู่ในรูป patch สำหรับสร้าง debian/ directory ภายใน upstream source tree

ยาวละ ไว้คราวหน้ามาต่อ

hacker emblem