Re: [Gelistirici] /boot dizini olarak raid device md0
2010/12/20 Mete Alpaslan m...@pardus.org.tr Slm, $SUBJECT anlaşıldığı üzere bir dizi hatamız vardı RAID deviceların /boot dizini olarak kullanılmasıyla ilgili sıkıntıları ekteki yamayla çözdüm ama konu grub olunca tam da emin olamadım. Biraz ön bilgi; grub.conf yazarken RAID aygıtları oluşturan fiziksel bölümler kullanılıyor yani md0 = sda1 + sdb1 oluşuyorsa; root için (hd0,0) ya da (hd1,0) kullanabiliyoruz ama UUID desteğiyle birlikte eldeki fiziksel bölümlerin formatı olmadığından uuid oluşmuyor böylece sda1 yada sdb1 uuid desteğiyle kullanılamıyor o yüzden md0 raid device'ların kendi uuid kullandım sistem açıldı. Emin olamadığım yerde tam burası; Grub UUID desteğiyle kullanırken, Raid Dizileri /boot dizini altında bağlanıyorsa kendi UUID lerini kullanmak doğru metod mu? Ben grub'dan tam olarak anlamam, nasil kernel ve initramfs'i okudugundan emin degilim. Ancak eger ext okumayi becerebiliyor ve kernel ve initramfs'i dosya sisteminden okuyorsa, o zaman boot bolumunun RAID1 de olsa normal bir partition olmasi gerekiyor (yani ext2 ext3 ext4 vs.). Sonucta grub esnasinda RAID cihazlari (mdX) hazir degil, bunlar ancak kernel yuklenip initramfs raid'leri probe edince ortaya cikan aletler. -- Emre ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] Çomar ve Yanlışlar
Selamlar, Bildiğiniz gibi manager-* ailesi ile uğraşıyorum ve bu uygulamaların herbiri aslında Çomar çağrıları yapan arayüzler. Bu uygulamarla uğraşırken karşı karşıya kaldığım birçok yanlış var Çomar ile ilgili, ki bu yanlışlar geliştirme sürecine olumsuz etki ediyor. Bir liste halinde yazayım, üzerinden geçebiliriz; - Model dosyaları comar paketinden geliyor, modelde bir değişiklik yapmak ya da model üzerinde bir değişiklik yapmak için comar paketinin güncellenmesi gerekiyor. - Model dosyalarında olduğu gibi haliyle policy dosyaları da (PolicyKit için) comar paketinden geliyor. Aynı problem burada da var. - Çomar bacakları konu ile ilgili olduğu düşünülen paketlerden çıkıyor ki bu bacaklardaki en ufak bir değişiklikte de aynı problem ortaya çıkıyor; Boot.Loader bacağındaki bir değişiklik için grub paketi güncellemeniz gerekiyor. Önerim, paketler ile dağıtılan çomar bacakları ve comar paketi ile dağıtılan model/policy dosyaları için ilgili çomar bacağını ifade eden başka bir paket oluşturalım (örn. backend-boot-loader.xx.pisi) ve gerekli uygulamalara bu paketler için bağımlılık yazalım. Bu şekilde bir düzene geçtiğimiz taktirde, mevcut manager-* aliemizin başka dağıtımlarda kullanılabilmesi için şu anda zorunlu olan çomar bağımlılığından da rahatlıkla kurtulabiliriz; diğer dağıtımlar için hazırlanacak pakette, çomar bacaklarının KAuth için uygun hale getirilmesi ve söz konusu manager'ın yanında dağıtılıyor olması yeterli olacaktır. Çomar'ın genişletilebilir yapısının mevcut düzende pek gerçekçi olduğunu düşünmüyorum. İyi çalışmalar, -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
Selamlar, [İlk mail HTML olmuş, kusura bakmayın.] Bildiğiniz gibi manager-* ailesi ile uğraşıyorum ve bu uygulamaların herbiri aslında Çomar çağrıları yapan arayüzler. Bu uygulamarla uğraşırken karşı karşıya kaldığım birçok yanlış var Çomar ile ilgili, ki bu yanlışlar geliştirme sürecine olumsuz etki ediyor. Bir liste halinde yazayım, üzerinden geçebiliriz; - Model dosyaları comar paketinden geliyor, modelde bir değişiklik yapmak ya da model üzerinde bir değişiklik yapmak için comar paketinin güncellenmesi gerekiyor. - Model dosyalarında olduğu gibi haliyle policy dosyaları da (PolicyKit için) comar paketinden geliyor. Aynı problem burada da var. - Çomar bacakları konu ile ilgili olduğu düşünülen paketlerden çıkıyor ki bu bacaklardaki en ufak bir değişiklikte de aynı problem ortaya çıkıyor; Boot.Loader bacağındaki bir değişiklik için grub paketi güncellemeniz gerekiyor. Önerim, paketler ile dağıtılan çomar bacakları ve comar paketi ile dağıtılan model/policy dosyaları için ilgili çomar bacağını ifade eden başka bir paket oluşturalım (örn. backend-boot-loader.xx.pisi) ve gerekli uygulamalara bu paketler için bağımlılık yazalım. Bu şekilde bir düzene geçtiğimiz taktirde, mevcut manager-* aliemizin başka dağıtımlarda kullanılabilmesi için şu anda zorunlu olan çomar bağımlılığından da rahatlıkla kurtulabiliriz; diğer dağıtımlar için hazırlanacak pakette, çomar bacaklarının KAuth için uygun hale getirilmesi ve söz konusu manager'ın yanında dağıtılıyor olması yeterli olacaktır. Çomar'ın genişletilebilir yapısının mevcut düzende pek gerçekçi olduğunu düşünmüyorum. İyi çalışmalar, -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
On Monday 20 December 2010 10:49:53 Gökmen Göksel wrote: Çomar'ın genişletilebilir yapısının mevcut düzende pek gerçekçi olduğunu düşünmüyorum. Katılıyorum. Bu sorunlar yüzünden artık comar kullanmamaya çalışıyorum (Sorunları son comar refaktörü öncesi söylemiştim; ama dikkate alınmadı). zorg atılmak üzere. Xorg.Driver bacağı artık kullanılmıyor. Yeni ekran kartı sürücüsü seçimi yapacak arayüz de KAuth ile yazılıyor. signature.asc Description: This is a digitally signed message part. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] Audacity paketi hakkında
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Audacity paketinin corporate2'ye alınması ile ilgili bir istek var [1]. Paket şu anda sadece 2009 deposunda var; ancak bakıcısız olarak işaretlenmiş (bkz. devel/unmaintained_packages). Eğer itiraz eden yoksa paketin bakımını üstlenip, 2011 ve corporate2'ye alınması ile uğraşabilirim. [1] http://bugs.pardus.org.tr/show_bug.cgi?id=15705 İyi çalışmalar. - --- Metin Akdere -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with PardusCorporate - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNDxu6AAoJEOnnAJ6Y6ZkwNIwH/A+2/+t6kNbYc4FAtgVe7BZz p2CWAzT1pxijWBw+t3jJEOnQMAlGFh0JtoxRfIWNqYWrp1lDYyAkL2aoUyAo1RSG wlgdnW23wsNCaHAavIe2QZAUgSxIua1CRofMPXxO/RklHug3TZFCaq2ZAtANRKmE +jktM7G+NXLd4Hjz3WR0GfKZqKLhE4vTOOk5AWZBDiAwD5UnH4BkHel6yTzXzwpk gmgtUh+akofeIXiU/F2J1T62Go3cKtxQrBCkrqPIxp7ktiGacVWUi/Ev8HzNAhoo 8Xho8sEWjAW9qVEAqXLMWaHW2db0ZQSroWXh6o7hEHavdRdOhy5PisJvUEtXlvk= =IqYy -END PGP SIGNATURE- ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
On Monday 20 December 2010 11:08:04 Bahadır Kandemir wrote: 20 Aralık 2010 Pazartesi günü (saat 11:02:09) Fatih Aşıcı şunları yazmıştı: On Monday 20 December 2010 10:49:53 Gökmen Göksel wrote: Çomar'ın genişletilebilir yapısının mevcut düzende pek gerçekçi olduğunu düşünmüyorum. Katılıyorum. Bu sorunlar yüzünden artık comar kullanmamaya çalışıyorum (Sorunları son comar refaktörü öncesi söylemiştim; ama dikkate alınmadı). zorg atılmak üzere. Xorg.Driver bacağı artık kullanılmıyor. Yeni ekran kartı sürücüsü seçimi yapacak arayüz de KAuth ile yazılıyor. Modellerin ÇOMAR ile, betiklerin paketlerle dağıtılmasının release beklemek dışındaki bottleneck'i nedir bir anlatın bana, hatırlamıyorum önceki tartışmayı. Mevcut yapı hata yapmaya çok müsait. En son bir package-manager hatasını düzeltmek için comar'daki modeli düzelttik ve release çıkardık. Ardından pisi paketindeki betiği düzelttik ve release çıkardık. Ardından PM'yi release ettik; sonra da comar'daki .policy dosyasını unuttuğumuzu fark edip tekrar comar release ettik. En ufak değişikliklerde bile bu kadar paket ile uğraşmak bence gereksiz yere işimizi zorlaştırıyor. signature.asc Description: This is a digitally signed message part. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
On Monday 20 December 2010 11:22:01 Fatih Aşıcı wrote: On Monday 20 December 2010 11:08:04 Bahadır Kandemir wrote: 20 Aralık 2010 Pazartesi günü (saat 11:02:09) Fatih Aşıcı şunları yazmıştı: On Monday 20 December 2010 10:49:53 Gökmen Göksel wrote: Çomar'ın genişletilebilir yapısının mevcut düzende pek gerçekçi olduğunu düşünmüyorum. Katılıyorum. Bu sorunlar yüzünden artık comar kullanmamaya çalışıyorum (Sorunları son comar refaktörü öncesi söylemiştim; ama dikkate alınmadı). zorg atılmak üzere. Xorg.Driver bacağı artık kullanılmıyor. Yeni ekran kartı sürücüsü seçimi yapacak arayüz de KAuth ile yazılıyor. Modellerin ÇOMAR ile, betiklerin paketlerle dağıtılmasının release beklemek dışındaki bottleneck'i nedir bir anlatın bana, hatırlamıyorum önceki tartışmayı. Mevcut yapı hata yapmaya çok müsait. En son bir package-manager hatasını düzeltmek için comar'daki modeli düzelttik ve release çıkardık. Ardından pisi paketindeki betiği düzelttik ve release çıkardık. Ardından PM'yi release ettik; sonra da comar'daki .policy dosyasını unuttuğumuzu fark edip tekrar comar release ettik. En ufak değişikliklerde bile bu kadar paket ile uğraşmak bence gereksiz yere işimizi zorlaştırıyor. Ha bir de bu tür durumlarda kullanıcının sadece comar'ı güncelleyip PM'yi güncellemediği durumda yaşayacağı problemlerden hiç bahsetmeyeyim. comar system.base'de olduğu için bağımlılık yazmıyoruz ve revDepUpdate de işe yaramıyor. signature.asc Description: This is a digitally signed message part. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
Pazartesi 20 Aralık 2010 günü (saat 11:06:46) Bahadır Kandemir şunları yazmıştı: Önerdiğin bu yollar ile, model değişikliği için başka paketin release edilmesini bekleme problemi ortadan kalkmıyor. Paketlerin sahibi değişiyor sadece. Onur ve beni değil de, Mehmet'i bekleyeceksin sürüm için. Hayır, kimseyi beklemeyeceğim, o paket ile ilgisi olan kişi güncelleyebilecek paketi, çünkü paketin içeriği atomik olacak başka bir sürece zarar ver(e)meyecek. Ufak değişiklik için GRUB güncellenmesin deme, değişiklik ufaksa zaten xdelta hallediyor o kısmı. Öyle birşey demedim ama bir çok makinede istediğin kadar delta teknolojisi kullan grub yeniden kurulduğunda, makine açılmıyor. Mac'lerdeki EFI ile ilgili bir grub problemi yüzünden. Diğer dağıtımlar kartını oynamasaydın keşke. İki sene evvel, Manager'ları port ederken de yaptık benzer bir tartışma. Modüller yapacaktık, arayüz ve kod ayrılacaktı, diğer dağıtımlara beş dakikada port edecektik tüm arayüzleri. Merak edenler şu adrese bakabilir, birkaç gün içinde bu tartışmanın ona ne kadar benzeyeceğini görebilir: http://lists.pardus.org.tr/gelistirici/2009-January/016107.html Bu yazdıkların senin sadece bir türlü karşı argüman bulamadığın iletiler için olayı kişiselleştirdiğini gösterir. Konu ile alakası olmayan bir yıl önceki bir threadi buraya taşıyarak olayı kişiselleştirdiğini düşünüyorum. ÇOMAR bağımlı ne varsa backend.py içine attık, projedeki tek dosyayı ÇOMAR bağımlı hale getirdik, sonra ne oldu? Hiçbir şey olmadı. Bu yazdığın ilk aşamaydı, ikincisi de Çomar'ı ortadan kaldırmak. Diğer dağıtımlar yalanını bir kenara bırakalım artık. Başka argümanlar bul Bahadır, bu işin altına sen elini sokmasanda olur, ortada herhangi bir yalan yok, Zorg arayüzünün diğer dağıtımlarda kullanılabilmesi için de bir engel yok. ÇOMAR'la ilgili sıkıntılar var, lakin argümanların tutarlı değil. Sen pek tutarlı değilsin gibi geliyor. -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] /multimedia/sound/vmpk
Sakıncası yoksa contrib'deki sahipsiz gözüken vmpk paketini üzerime alıyorum. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
Pazartesi 20 Aralık 2010 günü (saat 11:41:15) Bahadır Kandemir şunları yazmıştı: Sürüm çıkarma adımlarını minimuma indirmek gerek, doğru. Ama DBus+Polkit böyle olmasını gerektiriyor. API kırınca RevDepUpdate yazmaktan sıkıldığımız bir gün de PiSi'den vazgeçecek miyiz? Kendi NM'mizi attık, sabit IP kullanamadığımız bir NM'miz var; herkese manager'larımızı kullanabilsin diyoruz ama KDE bağımlı KAuth'a yöneliyoruz; PackageKit'e geçecekken vazgeçiyoruz... KAuth'a geçmek için herhangi bir şey yapmayacağız ki ? Bacakların dönüş değerlerini KAuth için düzenleyeceğiz sadece, kaldı ki KAuth ile kullanılabilecek seviyeye indirdikten sonra başka _olası_ bir yetkilendirme teknolojisine geçirmek çok basit olacaktır. - Lütfen son cümlemi baz alarak ama başta KAuth demiştin, şimdi argüman değiştiriyorsun diye yazma, sadece örnek o, ilk hedef Comar'ın parçalanması, ikincisi de KAuth kullanılabilecek hale getirerek (yeni bir branch altında belki) diğer dağıtımlarda kullanılabilir hale getirilmesi. - Olmadı deyip atmaktan ne zaman vazgeçeceğiz? Vazgeçmeyelim diye bunları yapalım diyorum zaten, Çomar'dan vazgeçmiyoruz, sadece süreci daha küçük parçalara bölüyoruz. -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
On Monday 20 December 2010 11:41:15 Bahadır Kandemir wrote: 20 Aralık 2010 Pazartesi günü (saat 11:22:01) Fatih Aşıcı şunları yazmıştı: Mevcut yapı hata yapmaya çok müsait. En son bir package-manager hatasını düzeltmek için comar'daki modeli düzelttik ve release çıkardık. Ardından pisi paketindeki betiği düzelttik ve release çıkardık. Ardından PM'yi release ettik; sonra da comar'daki .policy dosyasını unuttuğumuzu fark edip tekrar comar release ettik. En ufak değişikliklerde bile bu kadar paket ile uğraşmak bence gereksiz yere işimizi zorlaştırıyor. Sürüm çıkarma adımlarını minimuma indirmek gerek, doğru. Ama DBus+Polkit böyle olmasını gerektiriyor. API kırınca RevDepUpdate yazmaktan sıkıldığımız bir gün de PiSi'den vazgeçecek miyiz? Sorun sıkılıyor olmam değil. RevDepUpdate system.base paketlerinde işe yaramıyor. Çomar modellerini kullanan tüm uygulamalara comar bağımlılığı yazmamız gerekiyor işe yaraması için. Kendi NM'mizi attık, sabit IP kullanamadığımız bir NM'miz var; herkese manager'larımızı kullanabilsin diyoruz ama KDE bağımlı KAuth'a yöneliyoruz; PackageKit'e geçecekken vazgeçiyoruz... Olmadı deyip atmaktan ne zaman vazgeçeceğiz? Sabit IP alamama sorunu düzeltilebilir; ama 3G desteği veren, yüzlerce modeme destek veren bir NM yazamayız. Elimize geçmesi neredeyse imkansız donanımlar için backend yazıp test et(tir)menin de elimizdeki imkanlarla mümkün olduğunu düşünmüyorum. Bir 3G modem almak için verdiğimiz uğraşlar bile bana komik geliyor. PackageKit işi hala planlarımız arasında; ama 2011 için değil. Ondan önce düzeltmemiz gereken birçok şey var. Yoksa Packagekit pisi backend'ine girişmek için git deposuna erişim hakkı da aldım; fakat mevcut pisi api'si ile bazı şeyleri yapmak çok zor. Olmadı deyip atmamak için açık yazılım dünyasındaki teknik gidişatı yakından takip ederek sürece katılıp bu alanlarda yönledirici hale gelmemiz lazım. Sadece kendimizi düşüneceğimiz yere RedHat gibi başkalarının da faydalanacağı projeler üretsek herkes kazanır. Bu projenin sorunu bu bence. signature.asc Description: This is a digitally signed message part. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
Pazartesi 20 Aralık 2010 günü (saat 11:58:53) Bahadır Kandemir şunları yazmıştı: Backend betiklerini elden geçirip ÇOMAR bağımsız modüller hale getirmek, ÇOMAR betikleride bu modülleri kullanmak ve KAuth için de benzer bir yol izlemek yeterli diyorsun, haklısın da, bunu şimdi de yapabiliriz, ÇOMAR'la ilgisi yok ki bunun. Ortak kodları pardus-python içine koymamızın sebebi bu, birşeyler yapmak için ÇOMAR'ın ölmesini ya da değişmesini beklemeye gerek yok. Baştan beri söylediğim şey bu değil Bahadır, pardus-python'un içine koyduğunda da Çomar ile ilgili bahsettiğim sorunlar yaşanacak, çözüm küçük parçalara bölmek ve ayrı ayrı dağıtmak/geliştirmek. Hangisi doğru? Vazgeçelim mi, vazgeçmeyelim mi? İkisi de, çünkü ikisi de farklı şeylerin altına yazıldı, tam medya çalışanı gibisin. 20 Aralık 2010 Pazartesi günü (saat 11:53:32) Gökmen Göksel şunları yazmıştı: Vazgeçmeyelim diye bunları yapalım diyorum zaten, Çomar'dan vazgeçmiyoruz, sadece süreci daha küçük parçalara bölüyoruz. Bu Çomar'ı şu anda adam akıllı kullanabilmek için. 20 Aralık 2010 Pazartesi günü (saat 11:36:08) Gökmen Göksel şunları yazmıştı: Bu yazdığın ilk aşamaydı, ikincisi de Çomar'ı ortadan kaldırmak. Bu vazgeçme managerların başka dağıtımlarda kullanılması için, bizim dağıtım için değil. Sende ne yazdığımı adın gibi biliyorsun ya neyse. -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
Pazartesi 20 Aralık 2010 günü (saat 12:02:50) Bahadır Kandemir şunları yazmıştı: Model güncellemesi için ÇOMAR release etmek demek, PiSi paketine yama eklemek demek. Başkasının release etmesini ÇOMAR'ın en büyük problemi olarak nitelendirmekten vazgeç, daha sağlıklı yürür tartışma. Başkasının release etmesi değil, tüm Çomar'ın ya da bacakla ilgili tüm paketin yeniden release edilmesi zorunluluğu sorun olan. Testi kırılmadan atayım dedim tokadı. Grub'ın postInstall'ı umduğumuz gibi çalışmıyorsa, çalışır hale getirmemiz gerek. Buyur getir o zaman, bu sorun postInstall ile ilgili değil, birebir Grub ve Efi ile ilgili bir sorun, bütün dağıtımlar yaşıyor. Gerçi geçelim bu diğer dağıtımlar yalanını di mi ? Ofiste tartışma kodu kendin yazdın diye... şeklinde başlayınca kişiselleşmiş oldu. Evet, bu listedeki herkes ofiste çünkü. ÇOMAR'ın neden merkezde olması gerektiğiyle ilgili sağlam bir kavga yaşandı, Çomar hala merkezde, yazdıklarımı tekrar oku. Diğer dağıtımlar diye başlayan her proje eninde sonunda kendimize ait kaldı, örnekleri yok. PackageKit vardı mesela, COMAR olmayacaktı içinde; makul bir çözümdü, o ne oldu mesela? PackageKit ile ilgili sorunlar var, Fatih ilgileniyor o konuyla. ÇOMAR'da (/usr/bin/comar değil, iskelet olan) yenilikler gerekiyor, buna katılıyorum. ÇOMAR'ı atarak birşeylerin düzeleceğine inanmıyorum, geliştirme sürecinin düzelmesi gerek. Gerekirse Çomar'ı da atarız ama bu şimdilik gerekli değil diyorum; sadece küçük parçalara bölmekten bahsediyorum, dediğin gibi geliştirme sürecini düzeltmeye çalışıyorum; 1 - Boot Manager -- Package Manager -- Service Manager || || || 2 -Backend-BM - Backend-PM --- Backend-SM || || || \\--||// 3 - COMAR Her satırdaki her kelime için ayrı paketler olsun, ikinci satırdaki paketler; - Backend betiği - Policy dosyası - Model dosyası içersin. İyi çalışmalar, -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
On Monday, December 20, 2010 12:22:11 pm Gökmen Göksel wrote: Buyur getir o zaman, bu sorun postInstall ile ilgili değil, birebir Grub ve Efi ile ilgili bir sorun, bütün dağıtımlar yaşıyor. Thread konusunun dışında ama ufak bir parantez açayım diğer dağtımlar EFI tablolarını(REFIT sanırım ismi) değiştirmek(mıncıklamak) için efibootmgr kullanıyorlar. -- Mete ALPASLAN Pardus Core Developer mete.--.-.pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] [Buildfarm] [2011/devel/i686] error: game/sports/supertuxkart
On Monday 20 December 2010 11:41:45 Pardus 2011 i686 Buildfarm wrote: Hello, An error occured while building the package supertuxkart (maintainer: Onur Küçük). The last 50 lines of the log before the error happens is as follows: -- Building PiSi source package: supertuxkart -- Plain log file: http://packages.pardus.org.tr/logs/2011/devel/i686/supertuxkart.log Fancy log file: http://packages.pardus.org.tr/logs/2011/devel/i686/supertuxkart.html Hata bu: Error occured while building game/sports/supertuxkart: Patch file is missing: duplicate_files_am.patch signature.asc Description: This is a digitally signed message part. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
On Pazartesi 20 Aralık 2010 10:43:20 Gökmen Göksel wrote: Önerim, paketler ile dağıtılan çomar bacakları ve comar paketi ile dağıtılan model/policy dosyaları için ilgili çomar bacağını ifade eden başka bir paket oluşturalım (örn. backend-boot-loader.xx.pisi) ve gerekli uygulamalara bu paketler için bağımlılık yazalım. Bu benim de aklıma yatıyor, güzel olur bence -- Onur Küçük Knowledge speaks, onur.--.-.pardus.org.tr but wisdom listens ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
Pazartesi 20 Aralık 2010 günü (saat 13:21:02) Bahadır Kandemir şunları yazmıştı: Eninde sonunda bir paket release edilecek sonunda? Evet ama bunu sen release etmek zorunda kalmayacaksın. O bacağı geliştiren kişi de sana bağlı olmak zorunda kalmayacak. Ayrıntıları Onur söylesin, paketin bakıcısı o. GRUB'da sadece COMAR backend güncellemesi var diyelim, delta pakete dosya girmez bu durumda, sadece ÇOMAR betiği girer. PostInstall'da bir sorun yoksa zaten bu problem yaratmaz, eğer benim hatırladığım gibi postInstall sorunu ise GRUB yazma hatası oluşur. Yine de çözülmesi gereken bir problem olduğu gerçeğini değiştirmiyor bu. ÇOMAR'ın betik dağıtım politikasını bir pakete bakarak değiştirmemeliyiz. Her bacak/model için geçerli olabilecek bir durum bu, Boot.Loader sadece bir örnek. Evet, bu listedeki herkes ofiste çünkü. ? Bu listedeki insanlar senin daha önce ne gibi hayal kırıklıkları yaşadığını nereden bilecek onu kastediyordum. 1 - Boot Manager -- Package Manager -- Service Manager 2 -Backend-BM - Backend-PM --- Backend-SM \\--||// 3 - COMAR Model'i COMAR paketine ekleyip release etmek yerine ayrı 10 paket maintain etmenin teknik bir farkı yok, diğer tarafına bakınca da elbet bu paketleri birileri maintain edecek. Model/Policy ve betikler birbirinden ayrı dağıtılmalı. Bir yerde API tanımı, bir yerde de bu API'yi sağlayacak uygulama var. Neden ? Uygulama ve API tanımını bir araya getirdikten sonra abstaction falan kalmıyor. Bu yukarıdaki şema abstraction değil mi ? Fatih'in daha önce verdiği bir örneği de tekrar hatırlatayım yeri gelmişken (aman yine başta söylediğin argüman bu değildi deme, bu önceki dediklerime ek bir örnek, öncekiler hala geçerli): X firması yetki işlemleri gerektiren bir comar bacağı tasarladı ve kendi paketini yaptı, fakat durun büyük bir sorun var; adam comar'a model olarak kendi geliştirdiği bacağı nasıl ekleyecek ? Hemen Bahadır'ı bulacak, binbir dil döküp ikna edecek ve Pardus'un system.base bileşeni paketi comar paketine X firmasının model.xml'i girecek. -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
Pazartesi 20 Aralık 2010 günü (saat 14:08:42) Bahadır Kandemir şunları yazmıştı: API tanımını ve API'yi sağlayacak kodu, API yazarlarından birinin tekeline vermiş oluyorsun bu durumda. Şu anda ne yazılıp ne yazılmayacağı kimin elinde ? Yine API yazarlarının elinde değil mi ? Model.xml'i de kendileri hazırlayıp koymuyorlar mı ? Sen sadece onları comar paketine dahil etmiyor musun ? Sen sadece kontrol ederken modeli kontrol etmiyor musun ? Model standartını belirledikten sonra bu şartlara uymayan modelleri depoya almazsın olur biter. Tüm sorumluluğun tek bir kişide olması süreçleri uzatıyor. Sanki milyonlarca geliştiricimiz var da sen bunların kotrol dışına çıkacağında ısrarcı oluyorsun. Bu hale bile getirsek 1 bilemedin 2 kişi daha dahil olacak koda. Bu kadar önemli, yapılması imkansız gibi gözüken ne hala anlamış değilim. Kötü bir abstraction. Model ve kod ayrı olmalı. Model ve kod ayrı zaten, sadece aynı paket ile geliyorlar. Bu saatten sonra başka birşey yazmayı düşünmüyorum ve şu anda konuşmayan tüm geliştirici arkadaşların bu konuda sorumlu olduğunu ve tartışmaya katılmaları gerektiğini düşünüyorum. Saygılarımla, -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] playground/ertugrul/for2011 - asymptote t exlive-core çakışması
2010/12/20 Ertuğrul Erata paketler-comm...@pardus.org.tr Author: ertugrul Date: Mon Dec 20 16:41:07 2010 New Revision: 107563 Added: playground/ertugrul/for2011/a.patch playground/ertugrul/for2011/b.patch Log: asymptote texlive-core çakışması ? --- a.patch | 614 b.patch | 257 ++ 2 files changed, 871 insertions(+) ___ paketler-commits mailing list paketler-comm...@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/paketler-commits Selamlar, texlive-core ile asymptote içerisinden çıkan asycolors.sty, asymptote.sty ocg.sty çalışıyor. asymptote.sty ile ocg.sty nin texlive-core ile asymptote arasındaki farklar aşağıda, benim fikrim texlive-core den silinmesi asymptote ile beraber gelmesi. düşüncesi olan ? http://svn.pardus.org.tr/pardus/playground/ertugrul/for2011/a.patch http://svn.pardus.org.tr/pardus/playground/ertugrul/for2011/b.patch -- Ertuğrul Erata Pardus Devel. // http://ertugerata.mp/ ##biraz tembelim. itiraf ediyorum## ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] paketler sayfası hakkında
On Mon, 20 Dec 2010 10:04:34 +0200 Bahadır Kandemir baha...@pardus.org.tr wrote: Kurulumu yeniden yaptım, sorunsuz indekslemeye başladı. E modeli yapısını ellediğimi söylemiştim. Tabloları yeniden oluşturman gerekiyordu yani. 2011 ve Kurumsal 2 için XZ uzantısı desteklenmesi için trunk'taki pisi'yi kuracağım Noan dizinine. Testleri K2 ya da 2011 ile yapıyorsan sorun çıkarmadan çalışacaktır. 2009 kullanıyorum. 2011 kurayım yakın zamanda bakayım. Bir de, artık tek depoyla birden fazla mimari desteklediğimiz için dağıtım adına göre indeksleme yapmak yetersiz. mimari bilgisini de dbde tutuyorum. Sizin yazdığınız tablo yapısını ben değiştirdim. Eklemeler ve bazı değişiklikler var. -- Oguz Yarimtepe oguzyarimt...@gmail.com ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] paketler sayfası hakkında
On Mon, 20 Dec 2010 18:04:57 +0200, Oguz Yarimtepe oguzyarimt...@gmail.com wrote: E modeli yapısını ellediğimi söylemiştim. Tabloları yeniden oluşturman gerekiyordu yani. Syncdb deyince olur sandım, aldandım :) -- Bahadır Kandemir ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] playground/ertugrul/for2011 - asymptote t exlive-core çakışması
On Mon, Dec 20, 2010 at 04:59:01PM +0200, Ertuğrul Erata wrote: 2010/12/20 Ertuğrul Erata paketler-comm...@pardus.org.tr Selamlar, texlive-core ile asymptote içerisinden çıkan asycolors.sty, asymptote.sty ocg.sty çalışıyor. Diğer paketlerdeki çakışmaları engellemek için texlive-core yamalamıştım. Bunlar incelediğim kadarıyla, betik oluşturan yamanın dışında olan dosyalar. benim fikrim texlive-core den silinmesi asymptote ile beraber gelmesi. düşüncesi olan ? Öyle yapalım. Bu dosyaları texlive-core'den siliyorum ben. Zaten texlive-core'un içinden çıkan ağaçlar eski oluyor. Boş bir vaktimde tex.* işine de el atmam lazım, lakin bu aralar pek zamanım olmuyor. Paketi bu akşam, olmadı en geç yarın güncellemeye çalışacağım. Kolay gelsin -- Fatih Arslan ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] paketler sayfası hakkında
Daha önce paketler sayfasında ne gibi değişiklikler iyi olur diye fikirler alınmıştı. (1) Belki bu önerilerden iyi bir şeyler çıkar. (1) http://tr.pardus-wiki.org/Pardus:Paketler.pardus.org.tr'deki_degisiklikler Saygılarımla Ertan Argüden ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] playground/ertugrul/for2011 - asymptote t exlive-core çakışması
On Mon, Dec 20, 2010 at 08:02:13PM +0200, Fatih Arslan wrote: Paketi bu akşam, olmadı en geç yarın güncellemeye çalışacağım. Biraz önce değişiklikleri commit ettim. Lakin texlive'in başka bir ağacında Asymptote dosyaları mevuct. Paketi etkilemez diye düşünüyorum şimdilik. -- Fatih Arslan ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
On Mon, Dec 20, 2010 at 10:49:53AM +0200, Gökmen Göksel wrote: Önerim, paketler ile dağıtılan çomar bacakları ve comar paketi ile dağıtılan model/policy dosyaları için ilgili çomar bacağını ifade eden başka bir paket oluşturalım (örn. backend-boot-loader.xx.pisi) ve gerekli uygulamalara bu paketler için bağımlılık yazalım. Bu şekilde bir düzene geçtiğimiz taktirde, mevcut manager-* aliemizin başka dağıtımlarda kullanılabilmesi için şu anda zorunlu olan çomar bağımlılığından da rahatlıkla kurtulabiliriz; diğer dağıtımlar için hazırlanacak pakette, çomar bacaklarının KAuth için uygun hale getirilmesi ve söz konusu manager'ın yanında dağıtılıyor olması yeterli olacaktır. Çomar'ın genişletilebilir yapısının mevcut düzende pek gerçekçi olduğunu düşünmüyorum. Herhangi bir uygulamayı kurmak/güncellemek için sistemin temel bileşenlerine bağlı olmak can sıkıcı olabiliyor. Aynı şeyi Texlive/Pisi ikilisinde yaşadım. Zamanında 2011'de kurabildiğim ve derleyebildiğim Texlive paketini, pisi'nin yeni sürümü C2'de yok diye kuramamıştım. Yani yeni Texlive paketi C2'de kurulamıyordu. Çomar hakkında şu ana kadar hiç bir geliştirme yapmadım. Ama Texlive örneğindeki gibi, ileride Çomar'ın _güncellemesini_ bekleyeceksem bu işin sağlıklığı olmadığını gösteriyor. Burada Pisi sadece bir örnek, asıl demek istediğim _bağımlılığın_ artması konusundaki endişem. Herhangi bir işlevin _sadeleştirilmesi_ her zaman iyidir (Gökmen'in söylediğin argümanların çoğunun sonu sadeleştirmeye gittiğinden söylüyorum). Bugün Mehmet'in: Bir şeyi bölebiliyorsak, en küçük tanesine kadar bölmemiz gerekiyor sözü de bana bu konuda eskiden izlediğim bir video'yu aklıma getirdi. George Whitesides'in TED'deki _simplicity_ hakkındaki video'su: http://www.ted.com/talks/lang/eng/george_whitesides_toward_a_science_of_simplicity.html İzlemeyenlere kesinlikle tavsiye ederim. Çünkü demek istediğimi çok iyi anlatyıor. -- Fatih Arslan ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] paketler sayfası hakkında
On Mon, 20 Dec 2010 23:14:20 +0200 ertan ert...@gmail.com wrote: Daha önce paketler sayfasında ne gibi değişiklikler iyi olur diye fikirler alınmıştı. (1) Belki bu önerilerden iyi bir şeyler çıkar. (1) http://tr.pardus-wiki.org/Pardus:Paketler.pardus.org.tr'deki_degisiklikler Bunları okumuştum zamanında ama bir daha bir hatırlamamda fayda var -- Oguz Yarimtepe oguzyarimt...@gmail.com ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
On Tuesday, December 21, 2010 12:02:42 am Fatih Arslan wrote: Herhangi bir uygulamayı kurmak/güncellemek için sistemin temel bileşenlerine bağlı olmak can sıkıcı olabiliyor. Aynı şeyi Texlive/Pisi ikilisinde yaşadım. Zamanında 2011'de kurabildiğim ve derleyebildiğim Texlive paketini, pisi'nin yeni sürümü C2'de yok diye kuramamıştım. Yani yeni Texlive paketi C2'de kurulamıyordu. Yaşadığın sıkıntı paketin postinstall daki Çomar çağrısı yüzünden miydi yoksa başka birşey mi biraz açabilir misin? -- Mete ALPASLAN Pardus Core Developer mete.--.-.pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
On Tue, 21 Dec 2010 00:02:42 +0200, Fatih Arslan fars...@pardus.org.tr wrote: Burada Pisi sadece bir örnek, asıl demek istediğim _bağımlılığın_ artması konusundaki endişem. Herhangi bir işlevin _sadeleştirilmesi_ her zaman iyidir (Gökmen'in söylediğin argümanların çoğunun sonu sadeleştirmeye gittiğinden söylüyorum). Bugün Mehmet'in: Bir şeyi bölebiliyorsak, en küçük tanesine kadar bölmemiz gerekiyor Simplicity, böl ve yönet ve görev temelli yaklaşımdan vazgeçerek bağımlılık sayısını düşürmek aynı kefeye nasıl giriyor? PiSi talihsiz bir örnek olmuş doğru, herkesin depoya girecek 2 paketi beklemeyecek kadar acelesi olduğunu düşünmeye başlatıyor bana. Modeller ile, yapılacak bir görevin iskeletini çıkarıyoruz. Burada, standart belirleyen bir otorite gibi, arayüzden ve arayüzün istediği görevleri yerine getiren uygulamadan bağımsız (böylece arayüz ve backend bağımsız) bir API tanımı yapmış oluyoruz. Arayüz(ler)de değişiklik olunca backend(ler), backend(ler)de değişiklik olunca arayüz(ler) etkilenmiyor. API'yi başta kötü tasarlayıp hem arayüzü hem de backend'i bir arada değiştirmemiz gereken zamanlarda ise model güncellemesi için bir paketi beklemek 2011 ve Kurumsal 2'nin çıkmasını haftalarca geciktirecek beklemeler de ben mi farkında değilim? Görev ve backend bir arada dağıtılmaz. Comar ve görev tanımlarını (Model/API) ayrı paketlere almak da bekleme sürecini yokedecek birşey değil, pspec.xml'e bir Package ekleriz olur biter. Burada sorun, görev tanımını dağıtan paketi arayüzü ve backend'i yazanın eline bırakmamak, tek ben geliştiriyorum deyip görev tanımını uygulamaya bağımlı hale getirmesini engellemek. Model ve backend tek kişi tarafından tanımlanacaksa, görev temelli yaklaşımdan vazgeçip uygulamalara Polkit desteği ekleyip setuid verelim, iyi mi? -- Bahadır Kandemir ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
20 Aralık 2010 Pazartesi 12:03:30 tarihinde Fatih Aşıcı şunları yazmıştı: Olmadı deyip atmamak için açık yazılım dünyasındaki teknik gidişatı yakından takip ederek sürece katılıp bu alanlarda yönledirici hale gelmemiz lazım. Sadece kendimizi düşüneceğimiz yere RedHat gibi başkalarının da faydalanacağı projeler üretsek herkes kazanır. Bu projenin sorunu bu bence. Hayır, bence bu projenin sorunu bu değil. Konuyu biraz dağıtacak ama, daha önce iç toplantılarımızda söylediğimi tekrarlamak ihtiyacı duyuyorum: Linux'un kimi çözümleri yanlış, hatta pek çoğu son kullanıcı için tasarlanmamış diye girdiğimiz yolda en iyi akıl bizim aklımız mantığı ile tasarlanan ve geliştirilen Pardus teknolojileri, düzgün görsel sunum ile birleşince 5 yıldır sürekli pek kullanışlı ve kolay bir dağıtım diye özgüler alan bir ürün çıktı ortaya. Teknolojilerin sürdürülebilirliği, alternatifleri ile rekabet edebilirliği farklı düzeyde farklı bir konu. Ama *doğru sorulara* *doğru* yanıtlar oldukları konusunda benim bir şüphem yok. NM'nin (kısmen) bırakılması pratik durumun bizi mecbur kıldığı bir sonuçtu, ama kullanışlılık açısından yerini alan ürünlerden daha iyi olduğuna kalıbımı basarım. Kaynaklarımızın daha genişlediği, teknoloji geliştirme bazı konulara daha fazla zaman ve işgücü ayırabileceğimiz 10'lu yıllarda başlangıç felsefemizi terkedip Linux treninin ardına takılmanın doğru bir karar olmadığını düşünüyorum. Sanırım 2011 yılı içerisinde ve Pardus 2012'ye giderken PTK ve benzer organlarımız ile sıkça tartışacağımız en ateşli konulardan biri Pardus teknolojilerinin akıbeti olacak... ET ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
Salı 21 Aralık 2010 günü (saat 06:30:07) Bahadır Kandemir şunları yazmıştı: Simplicity, böl ve yönet ve görev temelli yaklaşımdan vazgeçerek bağımlılık sayısını düşürmek aynı kefeye nasıl giriyor? PiSi talihsiz bir örnek olmuş doğru, herkesin depoya girecek 2 paketi beklemeyecek kadar acelesi olduğunu düşünmeye başlatıyor bana. Evet, herkesin acelesi var; zira bir iş bitmeden diğerine başlamak, onun sonuçlarını test etmek gittikçe zorlaşıyor. Modeller ile, yapılacak bir görevin iskeletini çıkarıyoruz. Burada, standart belirleyen bir otorite gibi, arayüzden ve arayüzün istediği görevleri yerine getiren uygulamadan bağımsız (böylece arayüz ve backend bağımsız) bir API tanımı yapmış oluyoruz. Arayüz(ler)de değişiklik olunca backend(ler), backend(ler)de değişiklik olunca arayüz(ler) etkilenmiyor. O backendleri sanki uzaylılar için tasarladık ya başta. Pisi backendini package-manager'da başka kim kullanıyor ? pisi-cli dahi kendi apisini kullanıyorken, müthiş tasarlanmış bir dünyada yaşıyormuşuz gibi davranmaktan vazgeç artık. API'yi başta kötü tasarlayıp hem arayüzü hem de backend'i bir arada değiştirmemiz gereken zamanlarda ise model güncellemesi için bir paketi beklemek 2011 ve Kurumsal 2'nin çıkmasını haftalarca geciktirecek beklemeler de ben mi farkında değilim? İlla haftalarca bekletmesi gerekmiyor, 1 saat bile bekliyor olsa insanların işi aksayabiliyor. Görev ve backend bir arada dağıtılmaz. Comar ve görev tanımlarını (Model/API) ayrı paketlere almak da bekleme sürecini yokedecek birşey değil, pspec.xml'e bir Package ekleriz olur biter. Burada sorun, görev tanımını dağıtan paketi arayüzü ve backend'i yazanın eline bırakmamak, tek ben geliştiriyorum deyip görev tanımını uygulamaya bağımlı hale getirmesini engellemek. Tartışmanın başından beri aynı argümanlarla gelip duruyorsun, kaç tane backend geliştiren geliştirici var burada ? Model ve backend tek kişi tarafından tanımlanacaksa, görev temelli yaklaşımdan vazgeçip uygulamalara Polkit desteği ekleyip setuid verelim, iyi mi? ... -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
Salı 21 Aralık 2010 günü (saat 08:21:53) Erkan Tekman şunları yazmıştı: 20 Aralık 2010 Pazartesi 12:03:30 tarihinde Fatih Aşıcı şunları yazmıştı: Olmadı deyip atmamak için açık yazılım dünyasındaki teknik gidişatı yakından takip ederek sürece katılıp bu alanlarda yönledirici hale gelmemiz lazım. Sadece kendimizi düşüneceğimiz yere RedHat gibi başkalarının da faydalanacağı projeler üretsek herkes kazanır. Bu projenin sorunu bu bence. Hayır, bence bu projenin sorunu bu değil. Konuyu biraz dağıtacak ama, daha önce iç toplantılarımızda söylediğimi tekrarlamak ihtiyacı duyuyorum: Linux'un kimi çözümleri yanlış, hatta pek çoğu son kullanıcı için tasarlanmamış diye girdiğimiz yolda en iyi akıl bizim aklımız mantığı ile tasarlanan ve geliştirilen Pardus teknolojileri, düzgün görsel sunum ile birleşince 5 yıldır sürekli pek kullanışlı ve kolay bir dağıtım diye özgüler alan bir ürün çıktı ortaya. Bu ürünlerin kabul görmesindeki en büyük sebebin backendlerden ziyade arayüzler ile ilgili olduğunu düşünüyorum. Yani arkaplanda neler gerçekleştiğinin son kullanıcının pek farkında olduğu birşey olmadığı kanaatindeyim. Teknolojilerin sürdürülebilirliği, alternatifleri ile rekabet edebilirliği farklı düzeyde farklı bir konu. Ama *doğru sorulara* *doğru* yanıtlar oldukları konusunda benim bir şüphem yok. NM'nin (kısmen) bırakılması pratik durumun bizi mecbur kıldığı bir sonuçtu, ama kullanışlılık açısından yerini alan ürünlerden daha iyi olduğuna kalıbımı basarım. Yukarıda dediğim gibi, şu andaki NetworkManager backendinin arayüzünü bizimkisi gibi adam ettiğimizde o da kabul edilebilir bir ürün olacak. Kaynaklarımızın daha genişlediği, teknoloji geliştirme bazı konulara daha fazla zaman ve işgücü ayırabileceğimiz 10'lu yıllarda başlangıç felsefemizi terkedip Linux treninin ardına takılmanın doğru bir karar olmadığını düşünüyorum. Teknolojilerimizi diğer özgür yazılımlar için de kullanılabilir kılmanın Linux treni nin ardına takılmak diye görmüyorum ben, biz yine teknolojilerimizi geliştirelim; yanlış gördüğümüzü gerekirse yeniden yazalım ama bunu diğer insanların da faydalanabileceği şekilde yazalım; Fatih'te bundan bahsediyor sanırım. Sanırım 2011 yılı içerisinde ve Pardus 2012'ye giderken PTK ve benzer organlarımız ile sıkça tartışacağımız en ateşli konulardan biri Pardus teknolojilerinin akıbeti olacak... -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Çomar ve Yanlışlar
On Monday 20 December 2010 08:43:20 Gökmen Göksel wrote: - Model dosyaları comar paketinden geliyor, modelde bir değişiklik yapmak ya da model üzerinde bir değişiklik yapmak için comar paketinin güncellenmesi gerekiyor. - Model dosyalarında olduğu gibi haliyle policy dosyaları da (PolicyKit için) comar paketinden geliyor. Aynı problem burada da var. Modellerin paketlerden değil de COMAR'dan gelme nedeni sanırım aynı işlevi örneğin ağ işlemleri yapan 2 alternatif paketin aynı modeli sağlayabilmesi ve istenen durumda, istenenin tercih edilebilmesiydi. Yani COMAR sabit bir API/Model tanımlar, isteyen her paket bu Modeli sağlayan bir bacak taşır. İsterse birden çok paket de aynı modeli sağlayacak şekilde bacak taşıyabilir. Mesela bir nedenden hem kendi ağ yönetim altyapımızı geliştirmeye devam ediyor olsaydık hem de Gnome NM kullanmak durumunda olsaydık, Gnome NM ve Pardus NM, COMAR'ın Ağ Yönetimi için tanımladığı Model'i sağlardı ve 2009'da kullandığımız kendi arayüzümüz (teorik olarak) hiç değişikliğe uğramadan, sistemde Gnome NM kuruluysa onunla, Pardus NM kuruluysa da onunla çalışabilirdi. Modellerin COMAR'dan gelme nedeni bu. Bence, _manager'ların COMAR kullanmaya devam edeceğine karar verirsek_, Modellerin ve policylerin bu şekilde COMAR'da durması, olması gereken bir davranış. Belli bir olgunluğa eriştiğinde artık modellerde çok fazla değişiklik olmuyor, isterseniz bakın model dosyalarına ne sıklıkta commit gelmiş. - Çomar bacakları konu ile ilgili olduğu düşünülen paketlerden çıkıyor ki bu bacaklardaki en ufak bir değişiklikte de aynı problem ortaya çıkıyor; Boot.Loader bacağındaki bir değişiklik için grub paketi güncellemeniz gerekiyor. Önerim, paketler ile dağıtılan çomar bacakları ve comar paketi ile dağıtılan model/policy dosyaları için ilgili çomar bacağını ifade eden başka bir paket oluşturalım (örn. backend-boot-loader.xx.pisi) ve gerekli uygulamalara bu paketler için bağımlılık yazalım. Bu şekilde bir düzene geçtiğimiz taktirde, mevcut manager-* aliemizin başka dağıtımlarda kullanılabilmesi için şu anda zorunlu olan çomar bağımlılığından da rahatlıkla kurtulabiliriz; diğer dağıtımlar için hazırlanacak pakette, çomar bacaklarının KAuth için uygun hale getirilmesi ve söz konusu manager'ın yanında dağıtılıyor olması yeterli olacaktır. Ben de, manager'ların diğer dağıtımların kullanabileceği şekle sokulmasını istiyorum ama doğru çözümü bilemiyorum. Üzerine daha fazla düşünmek lazım. Manager'ları COMAR'dan ayırmak için, bacakları site-packages'a herhangi bir kitaplık olarak gönderip, DBus aktivasyon ile çalışan wrapper'ler yazıp, Manager'ları bu wrapper'ları kullanacak hale getirebiliriz. O zaman örneğin User Manager, tr.org.pardus.UserManager arayüzünün addUser method'unu çağırdığında doğrudan bacak işini yapar ve kullanıcıyı ekler ve bu, wrapperlar ile manager kodları ayrı olduğu için abstraction da sağlar, fakar COMAR'ın modellerinden daha ince bir abstraction sağlar. Bu yaklaşımı yukardaki hayali Pardus NM / Gnome NM senaryosunu çözmek için kullanmak daha zor olur, çünkü COMAR modeli, bacağı, o modeli implement etmeye _zorluyor_. Ama sadece DBus aktivasyonla çalışan ayrı betikler haline getirdiğimizde bir bacağın _tam olarak_ neleri sağlaması gerektiğiyle ilgili bir kısıtlama olmayacak. Tabi bu kısıtlamalara ve geniş abstractionlara ne kadar ihtiyacımız var onu bilmiyorum. -- Gökçen Eraslan signature.asc Description: This is a digitally signed message part. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] Comar model ve bacaklarının ayr ı bir paket ile sunulması
Selamlar, Bir önceki thread ısrarlı bir şekilde farklı bir yöne ilerlediğinden ve geleneksel Pardus Geliştirici Listesi Threadlerinden biri olma yönünde ilerlediğinden sadece konuya yorumlarınızı yazmanız için ayrı bir threade geçelim dedim; Önerimi tekrarlıyorum; Paketler ile dağıtılan çomar bacakları ve comar paketi ile dağıtılan model/policy dosyaları için ilgili çomar bacağını ifade eden başka bir paket oluşturalım (örn. backend-boot-loader.xx.pisi) ve gerekli uygulamalara bu paketler için bağımlılık yazalım. Bu önerime Onur ve Fatih (Aşıcı/Arslan) destek verdiler bir önceki threade göre, Bahadır karşı çıkıyor; sebeplerini bir önceki threadde bulabilirsiniz. ~ Biraz önce Grub paketinden çıkan Boot.Loader bacağı için yaptığım değişiklikleri sistemlere yansıtabilmek için Grub paketinin release'ini arttırdım, toplamda 91 release var ve bu releaselerin 37 si sadece Boot.Loader bacağı için yapılmış. ~ Ben önerimi son kez tekrarlıyorum (bir kez olsun bu listeden bir sonuç çıkabilsin diye) ve konu ile ilgili olan herkesin fikrini belirtmesini rica ediyorum. ~ Yollamadan önce Gökçen'in önerisini okudum ki (bir önceki threadde yine) bu öneri bile şu an için yeterli olabilir; model ve policy dosyaları yine Comar ile dağıtılsın ki bu da zaman zaman sorun yaratacak fakat betikler ayrı paketler halinde dağıtılsın ~ -- Gökmen Göksel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
