pardus | {Yaratıcı Bir Başlık}

Category Archives: pardus

>Pardus günleri iyiye gidiy…

>

Pek çok arkadaş bu iyiye gidiy muhabbetini merak ediyor(Saçma buluyor olabilir). Şu video linki ile muhabbeti bilmeyenleri bilgilendirmek isterim.

http://www.youtube.com/watch?v=Eciwebcba48

Peki pardus günlerinde ilk gün geçti. Güzel bir kalabalık vardı, Pardus standı etrafında kalabalık yogun olarak gözledim(Bir grup şeker ve katalog alarak geçti).

Stand etrafında gezindim, birilerin fotoğraf makinasını ele geçirdiğimde bir kaç poz çektim. Kendi adıma zevkli bir gündü. Seminerlerde gözlemlediğim birşey ise sorular sorulmasıydı. Bu da daha ilgili bir topluluk olduğunu gözlemledim.

Yarın 12.40 sunumumuz var herkesi bekleriz. Umarım terletecek sorular sorulmaz 🙂

>Lib64 sorunsalı…

>

Linux bilgisi olan mutlaka lib dizinleri ile karşılaşmıştır iyi ya da kötü şekilde. Burada paylaşımlı olarak kullanılan kütüphanelerin derlenmiş halleri bulunur. Programlar çalışırken de bunları isterler ararlar. Kendi içerisinde bir linklenme vardır yani…


Peki nedir bu lib64 muhabbeti?

x86_64 işlemciler kendi üzerinden x86 mimarisine de destek verdikleri için, x86_64 bir işletim sisteminde 32bitlik kod çalıştırılabilir.(Tabi ki çekirdeğin bu çevirme işi için açık olması gerekmektedir.) 32 Bit derlenmiş programlar için dizin hiyerarşisinde ise lib32 dizinleri oluşmuştur. 64 bit derlenen kütüphaneler içinse (programın derlenme şekline göre değişebiliyor tabi) lib64 dizinine konuluyor. Sonuçta elimizde 3×2 lib dizinimiz olur. Biri kökte, diğeri ise /usr altında. Peki ya elimizde hiç 32 bitlik paylaşımlı kütüphane olmayacaksa (şu anki kurumsal 2 x86_64 gibi)?

Burada bir çözüm olarak lib64 dizinlerini lib dizinine linklemek en basit ve en mantıklı çözüm gibi geldi bize. Neden bu linke ihtiyacımız var sorusuna gelecek olursak; belirli programların lib64 e ihtiyaç duyması ve araması. Hatta bu lib64 sorunu yüzünden bir süre kurulan cd hazırlayamadık.


Peki bu linki kaldırmak mümkün değil mi?

Tabi ki mümkün, tool chain’i düzenlemek gerekiyordu. Burada yapılanlar tabi ki 32bit’lik halini etkilemeyecek şekilde olması gerekiyor. Bunu Onur Küçük bir hafta sonunda yaptı. Diyecek bir söz bırakmadı 🙂 Ancak her paket bu yöntem izlenemiyor. Çünkü ati’nin ekran kartı gibi sürücüleri istediği gibi at koşturabiliyor hala…

>fPIC…

>

Sanki uzun zaman oldu blog girdisi yapmayalı diyerek bir giriş yapmış bulunayım 🙂 Bir süredir Necdet Yücel tarafından sıkça “Blog yazın….” çağrılarına cevap vermek istedim.

Girdi konusu olarak da bir süre önce Gökmen Görgen ile konuştuğumuz bir konu olan fPIC olmasını tercih ettim. Neden olduğunu ise not olarak koyacağım. Konuyu daha çok dağıtmadan bi giriş yapayım konuya,

Nereden geldi bu fPIC?

fPIC ile karşılaşmam ilk olarak 64bit için paketleri hazır hale getirirken karşılaştım. Derleme sırasında aldığım hata ise;
“relocation R_X86_64_32 against `a local symbol’ can not be used
when making a shared object; recompile with -fPIC .libs/assert.o: could not
read symbols: Bad value”

Oradaki 32’yi görünce kıllanıyor tabi insan. Güzelce derle şunu diyesi geliyor insanın, yoksa hata GCC de mi diye düşünebiliyor insan 😉 Peki ufak bir araştırmadan sonra sorunu gördük ki paylaşımlı kütüphaneler için oluşturulan nesnelerin düzgün şekilde linklenebilmesi için -fPIC parametresi ile derlenmesi gerekiyormuş. Tabi ki sorunun çözülmüş oldu.

Kendisi bi gcc bayrağıdır. “Position-Independent Code”un kısaltılmasıdır. Türkçe’ye çevirdiğimizde konum bağımsız kod oluyor herhalde 🙂 PIC, çıkan ikilik dosyanın belirli bir taban adresine yüklenmesini beklemez, bellekteki herhangi bir yerde mutlu olmayı bilir anlamına geliyor 😉
Kendisi i686 mimarisinde kullanıldığında bir fark oluşturmadığı söyleniyor. Bilemiyorum nedir, ne değildir. Ancak x86_64 mimarisi için daha yavaş çalıştığına dair rivayetler dolaşıyor. Alpha, SPARC64 ve iirc HP-PA mimarileri içinde gerekli olduğundan bahsi geçiyor.

Daha ayrıntılı bakmak isteyenler için :

http://www.technovelty.org/code/c/amd64-pic.html
http://en.wikipedia.org/wiki/Position-independent_code
http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3
http://www.redhat.com/archives/fedora-maintainers/2005-August/msg00094.html

Not: Herhangi bir yerde hata görürseniz bildirmekten çekinmeyin. Herkes herşeyi bilemez sonuçta 😉

>1 şubat

>

Uzun çalışmamız ürünü olan pardus kurumsal 2 64 bit pardus alfa sürümü çıktı. Uzun günler boyunca çalıştık, sorun çözdük hep beraber(Pardus ekibine yardımları için çok teşekkür ederiz) ve ilk kurulan cd’miz artık hazır. Tabi ki içerisinde hatalar olabilir sonuçta alfa sürümü 😉 Hataları bildirmekten çekinmeyiniz, yardım etmekten ise hiç çekinmenize gerek yok tabi ki.

Bu sürüm’ü kuracak ve kullanacak olan tüm arkadaşlara sesleniyorum, güle güle kullanın. Çalışmaya devam edeceğiz yakından takip ediniz;)

ps: bir iki link vermeden bu yazıyı sonlandırmak gereksiz olacağı için,

Şurada ilk alfa sürümümüz : http://members.comu.edu.tr/nyucel/Pardus-C2-x86_64-alfa.iso
Burada da depomuz : http://x86-64.comu.edu.tr/pisi-index.xml.bz2
Bu da sha1sum’ı tabiki : http://members.comu.edu.tr/nyucel/Pardus-C2-x86_64-alfa.iso.SHA1SUM

>BuildFarm

>

Build farm hakkında bir ufak çaplı bir yazmıştım ancak kaza sonucu yok olunca kısa ve öz bir şekilde build farmdan bahsetmeyi daha doğru buldum.

Buildfarm bizim elimizle yaptığımız paket derlemeyi otomatikleştirmeye yarayan bir buluş diye adlandırabiliriz. Kendisini doğru yapılandırınca, verilen xml’lerin paketlerini yapıyor, svn’de paketlerde bir değişiklik oluştuğunda haberdar olup onların paketlerini yapıyor, şu paketleri yapmaya başlıyorum, şu paketleri bitirdim ve şu paketlerde sorunlar yaşadım diye mail atıyor. Yapamadığı paketleri de bekletiyor…

Peki çalışır hale nasıl getirilir?

Başlangıçta svndeki son revizyonunda bir takım sorunlar var. Pardus ekibinden yeniden yazıldığı hakkında bilgi aldım. O yüzden sayın Türker Sezer ile konuşmamdan sonra açıklayıcı bilgilerinin ışında revizyon 24480 kullanmaya başladım(Ve onu anlatacağım).

Teknik olarak buildfarm pisinin yapacağı birşeyi yapmıyor. Bizim ile pisi arasında duruyor diyebilirim. Biz buildfarm’a toplu görevler veriyoruz, o da pisiye sırası ile iletiyor, oluşan paketleri bir yere topluyor ve index oluşturuyor(wrapper olarak kullanılıyor yani). Hayat kurtarıyor bile diyebilirim.

İki şeye ihtiyacımız olacak başlangıç olarak;
– buildfarm kaynak kodlarına,
– Buildfarm’a verilecek olan paketlerin pspec.xml ve actions.py içeren havuzu(repository).(Birde pardus’a tabiki)

İlk olarak /root un içerisine indirmemenizi tavsiye ediyorum. Çünkü disk dolsa bile root için ufak bir alanın kalması gerektiği ve böylece sisteme müdahale edebilme imkiyanının bulunabilmesi için…

Örnek olsun diye ben /hede diye bir dizin açtım kabul edelim.

ilk olarak;

# cd /hede
# svn co -r 24480 http://svn.pardus.org.tr/uludag/trunk/buildfarm

Bu sayede build farm kaynak kodlarını sistemimize indirmiş bulunuyoruz.

# svn co http://svn.pardus.org.tr/pardus/2009/devel

Bu sayede havuzu /hede dizinimize indirmiş bulunuyoruz. Bu havuzun svn yapısı ile tutulması buildfarm içinde gereklidir çünkü kendisi bu havuzdaki güncellemeleri kontrol edebiliyor. Böylece kendisine bunları ekledim, bi zahmet yapı ver dememize gerek kalmıyor.

# cd /hede/buildfarm

Bu dizinde bulunan config.py python kodunu düzenleyerek buildfarm’ı çalışır hale getireceğiz(python bilmenize gerek yok bunun için).

localPspecRepo = “/hede/2009/devel” -> Burada indirmiş olduğumuz paket havuzumuzun yolunu gösteriyoruz. Böylece buildfarm ne üzerinde çalışacağını öğreniyor.

logFile = “/var/cache/pisi/buildfarm.log” -> Buildfarm’ın temel loglarının bulunacağı dosyayı belirtiyoruz.

outputDir = “/var/cache/pisi/buildlogs/” -> Yapılmaya çalışılan paketler ile ilgili logların tutulacağı dizini belirtiyoruz.

binaryPath = “/var/cache/pisi/packages/” -> Oluşan paketlerin koyulacağı dizin

testPath = “/var/cache/pisi/packages-test/” -> Build farm’ın kendi oluşturduğu paketlerin dizini

debugSupport = False

debugPath = “/var/cache/pisi/packages-debug/”

ignoreCheck = True -> Actions.py’lerde check kısımlarının geçilmesini sağlar. Pek çok pakette bu testler düzgün yapılamadığı için ön tanımlu true gelir.

sendEmail = True -> Yaptıklarını bize haber verecek olan güzel teknoloji.

mailFrom = “buildfarm@pardus.org.tr” -> Gönderilecek mail’de kimden gelmiş kısmı

announceAddr = “buildfarm@pardus.org.tr” ->

ccList = [“buildfarm@pardus.org.tr”] -> Kime ek olarak gönderilecek

smtpServer = “mail.pardus.org.tr” -> Smtp servisi veren ve mail’in gönderileceği sunucu

useSmtpAuth = True -> Smtp gönderirken kimlik kanıtlaması yapılacağını belirtiyor.

generateDelta = True -> Hayatı kolaylaştıran delta paketlerin yapılacağını belirtiyor.

deltaBlacklist = [] -> Bu liste ise delta paketlerinin yapılmaması gereken paketlerin isimleri yazılması gerekiyor.

Şimdi bir adet mailauth.py diye dosya oluşturuyoruz. Çünkü mail gönderirken hangi kullanıcı ve parolası ile göndereceğini buraya bakarak söyleyecek. İçerisine

username = “hede@hodu.org.tr”
password = “xxxxxxxxxxxxxxxx”

yazılması yeterli. Çalıştırırken ilk olarak repomanager.py çalıştırılması daha sonra ise main.py çalıştırılması gerekmektededir.

Buildfarm çalıştıktan sonra /var/pisi altında iki tane dosya oluşacak;

workQueue, -> Burada yapılacak olan paketlerin pspec.xml’lerinin tam yolları yazılıyor,
waitQueue -> Burada ise yapılmasında bir sorun oluşmuş paketlerin bir sonraki çalışmada yeniden yapılabilmesi için sırada beklemeleri için tam yolları yazılı.

Ek olarak da /etc/pisi/pisi.conf’da bir kaç düzenlemeyle daha hızlı bir buildfarm elde edebiliriz;

[build]
buildhelper = ccache -> Bu seçenek derleme yaparken ccache paketinden yardım alır. Daha hızlı bir derleme oluşur.

buildno = True -> Bu seçenek ile aynı sürümden iki paketin çakışması engellenir.

cflags = -mtune=generic -march=i686 -O2 -pipe -fomit-frame-pointer -fstack-protector -D_FORTIFY_SOURCE=2 -g3 -ggdb -> Sona gelen -g3 -ggdb ile debug parametresi verilmiş olur. Oluşan hatalarda daha anlaşışır çıktılar gözlemlenebilir.

compressionlevel = 9 -> Paketlerdeki sıkıştırma oranını arttırır. Ancak sistemin canına okur.

cxxflags = -mtune=generic -march=i686 -O2 -pipe -fomit-frame-pointer -fstack-protector -D_FORTIFY_SOURCE=2 -g3 -ggdb -> Sona gelen -g3 -ggdb ile debug parametresi verilmiş olur. Oluşan hatalarda daha anlaşı
şır çıktılar gözlemlenebilir

enableSandbox = True -> Paket derlenirken temel sisteme erişim kontorlü yapmasını sağlar.

fallback = ftp://ftp.pardus.org.tr/pub/source/2009 -> Paketin kaynak kodunun adresi cevap vermiyorsa buradan indirmeye çalış.

generateDebug = True ->

host = i686-pc-linux-gnu -> Üzerinde bulunan gcc’nin hangi mimari için derlendiği(biraz karışık oldu galiba 🙂

jobs = -j5 -> Yapılan derleme işleminin paralelleştirilme sayısı(çekirdek sayısı +1 diye hesaplayabiliriz.)

ldflags = -Wl,-O1 -Wl,-z,relro -Wl,–hash-style=gnu -Wl,–as-needed -Wl,–sort-common -> Dinamik kütüphaneler için gerekli bayraklar.

Not: Buildfarm kurarken kullandığınız dağıtımın o sürümünün havuzunu almaya dikkat ediniz(2008 üzerinde 2009 buildfarm’ı mantıklı değil;)

>Dayanılmaz sona yaklaşırken…

>

Başlıktan pek bir şey anlaşılmasa da son gelişmeler hakkında ekipteki herkes bir şeyler yazdı.[0][1][2] Bu konu hakkında bir iki satır karalama ihtiyacı hissettim bende.

Uzun bir süredir sıkı çalıştığımızı bilmeyen kalmadı herhalde ancak meyvelerini toplamaya başladık. İlk meyve olarak chroot olduğumuz zaman aldık(Ekip dışında bulunanları pek az tat veren ilk meyveydi. Ekip içinde ise ufak bir kutlama havası esmişti). Daha sonra pisi’yi ayağa kaldırdığımızda aldığımız meyve çok tatlıydı(özellikle pisinin yapması gereken her şeyi ellerimizle yapan bizler için. Ekip dışına da tat veren bir meyveydi bu). Daha sonra boot edebilmemiz, şimdi bir masa üstü ortamımız var (en çok sevinen de herhalde links ile pek haşır neşir olan metin oldu diye biliyorum.) Şimdi ise kurulan bir cd için çabalıyoruz. Onu yaptığımızda öncekiler gibi yine çok çalışmanın bir meyvesi ancak hem ekibe hemde Pardus’a gönül verenlere de tat vereceğini düşünüyorum. Bu meyveyi paylaşmaya açığız… Çünkü paylaştıkça artar diye düşünüyoruz.

ps: Daha teknik konularda yazıları [3] wiki sayfamızda bulabilirsiniz…

[0] http://m-akdere.blogspot.com/2009/12/ve-pardus64-uzerinde-masaustu-ortam.html
[1] http://nyucel.blogspot.com/2009/12/64-bit-kurulan-cd-icin-eksik-paket.html
[2] http://meltemparmaksiz.blogspot.com/2010/01/kurulan-cdye-bir-adm-kala.html
[3] http://tr.pardus-wiki.org/Pardus%27un_X86_64-64_Mimarisine_Port_Edilmesi

>64 bit geliyor mu ne?

>

Necdet hocam’ın da yazdığı gibi rootfs yakında yayınlanacak. Bir çok kişinin büyük merakla beklediğini hepimiz biliyoruz. Ancak rootfs sürecinde sadece konsol ekranı olan bir sistem olacak. Bu yüzden gerçekten ne yapacağını bilen arkadaşların rootfs’i denemesini öneriyoruz. Diğer arkadaşların ise bir süre daha sabretmesini içten arzuluyorum.

Diğer arkadaşlara ise rootfs ile iyi eğlenceler diliyorum. Umarım bunun 3 üniversite son sınıf öğrencisinin uzun süreler boyunca çalışarak meydana getirdiği bir sürüm olduğunu unutmazsınız.

Artık bizler daha çok çalışarak alfa için daha uzun bir mesafeyi kat etmemiz gerekiyor. Bize yardımcı olanlara şimdiden teşekkür ederiz.

Not: gelişmeler için bizi takip edin(Necdet Yucel, Metin Akdere, Meltem Parmaksız, wiki).

>Yaşıyor, yaşıyor, yaşıyor…. Pisi yaşıyor…

>

Bilindiği üzere Pardus 64 üzerinde uğraşıyorduk(biraz çok uğraşıyorduk gerçi:), pek az bir şey yazmış olabilirim kendi adıma… Ama gecelere kadar çalıştık pisi’nin bağımlılıkları ile haşır neşir olduk(şimdi paket yöneticisini daha bi sevmiyor değilim)

Tüm paketleri ellerimizle derledik, linkledik, non-shared lib’leri kaldırdık…(birazcık cinnet geçirdik gerçi bağımlılıklarla ) Ancak sonunda şu çıktıyı almak bu zahmete ve zamana değdi galiba 🙂

root@pardus64 /#pisi rm libsigsegv

Safety switch: the component system.base cannot be found

The following minimal list of packages will be removed

in the respective order to satisfy dependencies:

libsigsegv

Removing package libsigsegv

Running pre removal operations for libsigsegv

Running post removal operations for libsigsegv

Removed libsigsegv

root@pardus64 /# pisi it libsigsegv-2.6-3.pisi

Installation order: libsigsegv

Installing libsigsegv, version 2.6, release 3, build None

Extracting the files of libsigsegv

Configuring libsigsegv package

Configured libsigsegv

Installed libsigsegv

Şimdi azıcık paket yapmak gerekiyor galiba 🙂

>Belirli bi konuma geldik. Yazmak gerek…

>

   Uzun bir zamandır yoğun bir çalışma süreci içerisinde olduğumuz için pek bir blog girdisi yapamıyordum. Yaklaşık olarak 1 aydır Pardus’un x86_64 portunu hazırlamaya çalışıyorduk.

Başlangıçta Pardus 2008 üzerinde çapraz derleme ile 64 bit olarak başladığımız ve üzerinde chroot yapacağımız sistem için uzun saatler geçirdik. Chroot’da bir takım sorunlar yaşadık ve 2008’den 2009’a geçildiği haberi ile beraber bizde yeni yönümüzü o tarafa çevirdik. 2008’de bir kısmını öğrendiğimiz süreci daha hızlı bir şekilde ilerletebildik. Ancak hedef olarak chroot dan boot edilebilir bir sisteme çevirdik. Bu süre zarfında clfs belgesini takip ettik, sürümler arası farklara bakarak yamalar bulduk, bir kısmını kendi aramızda tartışarak değiştirdik, derlenmeyen araçlar için çince bile okuduk. (google translate’e teşekkürü bir borç biliriz.) Çekirdek derledik, nasıl derlememiz gerektiği konusunda biraz tartıştık. Pardus’un kullandığı çekirdeği ve config dosyasını biraz değişiklik yaparak kullandık. (debian ve ubuntu gibi dağıtımların 32bit ve 64bit çekirdek config’lerinden yola çıkarak.) İnitramfs oluşturmak için uzun süredir çabalıyorduk. Coolplug isimli pardus teknolojisi biraz uğraştırdı bizi gerçi. Derlemek için elimizde olan çapraz derleme yapabilen gcc kullanmıştık. Hata almadığımız için oldu herhalde demiştik. Ancak coolplug’ı initramfs de çalışmadığını gördüğümüzde klibc’yi sistem için derlesek mi acaba diye düşünmeye başladık. Ancak çapraz derleme yapabilmesini sağlayabilmemiz için elle tutulur bir belge bulamadığımız için 64bit olan debian 5 üzerinde klibc – klcc kurduk (libklibc-dev paketinden geliyor klcc) ve coolplug’ı derledik. İnitramfs’in içerisine dahil ettik. Boot sırasında bu seferde en azından coolplug çalıştığını gördük. Ancak sabit diski göstermeyi başaramadık. Coolplug’dan kaynaklı bir sorun olduğunu düşündüğümüz için ve daha fazla motivasyon kaybetmemek için (tek bir noktada takıldığımız için elimiz kolumuz bağlanmış durumdaydık.) Bu yüzden hızlı bir şekilde cumartesi akşamı alternatif yol olarak chroot değerlendirdik.(debian 5 – 64bit üzerinde) Ufak bir sorun yaşadık. Ancak lib64 -> lib’e kopyaladık.(bir birlerine döngü olarak linklendiğini gördük ihtiyaç duyduğu kütüphaneyi ve o da lib64 içinde bulduk.) ve chroot yaptık sorunsuz bir şekilde. Vatana millete hayırlı olsun.

>sanal makina

>

Sonunda teknoloji çok ilerledi arkadaşlar…Kullandığım Pardus’dan vazgeçmedim ( neden mi basit c# dersi için tabiki de mono ile yapamayınca ödevi) sadece zorunluluktan dolayı virtualbox kurup üzerine xp kurdum.Gayet performanslı çalışıyor kendisi;) Bir süre başka işle meşkul olurken geri geldiğimde çok ilginç bir manzara ile kaldım.(unutmuşum bu manzarayı ama gerçekten) windows’un mavi ekranı ile karşı karşıyaydım.Virtualbox ekibi gerçekten bir makina yaratmış;) resmini çekmeyi unuttuğum için koyamıyorum ne yazık ki:( ama bir daha başıma malum olay gelirse sizinle paylaşmayı gerçekten istiyorum…Pardus for ever….