Re: [Gelistirici] review gunu raporu
Pazartesi 27 Eylül 2010 günü (saat 01:04:54) Türker Sezer şunları yazmıştı: > Bu paketi kdm ekranında ekran klavyesi gösterebilelim diye almaya > niyet ettik. (Bugzilladaki bir istek üzerine.) Lakin daha sonra Bence ziyadesiyle gerekli ve alıyorsak hemen alalım, önümüzdeki test sürümlerinde rahatlıkla deneyebilelim... -- Koray Löker <--/ Özgürlük İçin... http://www.pardus.org.tr /--> ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] [Pardus-kullanicilari] 2011 deposu
Pazar 26 Eylül 2010 günü (saat 15:13:31) Süleyman Arıkan şunları yazmıştı: > Merhaba > 2011 deposu ne oldu bomboş halde anlayamadım > Başka bi adresemi taşındı Haftasonu *2011 test* deposunun paketler.pardus.org.tr ile senkronlanması sırasında bir problem yaşandı, Gebze MAM kampüsündeki elektrik altyapısı çalışmaları yüzünden makinaları kapatmak zorunda kaldığımız için müdahale edemedik. Bir saate kadar i686 ve x86_64 depoları güncellenmiş olacak. -- Bahadır Kandemir ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] review gunu raporu
27 Eylül 2010 01:04 tarihinde Türker Sezer yazdı: > Depoda herhangi bir ekran klavyesi programı yoksa (arama yaptım, > çıkmadı) bu paketi elden geçirip depoya alabiliriz. İhtiyacı karşılayacaksa depoya alalım, olmadı review dizininden silelim derim ben. --- Necdet Yücel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] review gunu raporu
2010/9/26 Onur Küçük : > > On Sun, 26 Sep 2010 14:08:05 +0300 > Necdet Yücel wrote: > >> KİM BİLİR: >> util/misc/xvkbd Bu paketi kdm ekranında ekran klavyesi gösterebilelim diye almaya niyet ettik. (Bugzilladaki bir istek üzerine.) Lakin daha sonra uygulama bunu yapabiliyor olmasına rağmen istediğimiz çalışma şeklini karşılayamadı. Biz de yeni sürümlere bakarız dedik. Sonra paket sonu olmayan bir sürece girdi ve bir türlü depoya ulaşamadı. Depoda herhangi bir ekran klavyesi programı yoksa (arama yaptım, çıkmadı) bu paketi elden geçirip depoya alabiliriz. -- Türker Sezer ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] review gunu raporu
Selamlar, 26 Eylül 2010 22:33 tarihinde Onur Küçük yazdı: > "kim bilir" ne demek anlamadım Kimi beklediği belli olmayan demek istemiştim. > 0 ACK ne demek onu da anlamadım, bileşen sorumlusundan inceleme > beklenmiyor mu ? Elbette bileşen sorumlularından gözden geçirme bekleniyor ama daha önce hiç ACK almamış bu paketler. Yukarıdakilerden ayırmak için böyle yazdım, uygun değil derseniz haftaya böyle yapmam. --- Necdet Yücel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] cmemcache hakkinda
26 Eylül 2010 22:51 tarihinde Onur Küçük yazdı: > On Sat, 25 Sep 2010 12:38:00 +0300 > Sitesinde artık ilgilenemiyorum demiş de yukarıdaki cümleyi göremedim ? Bu ifadeyi memcached'in sitesinde görmüştüm: http://code.google.com/p/memcached/wiki/Clients --- Necdet Yücel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] cmemcache hakkinda
On Sat, 25 Sep 2010 12:38:00 +0300 Necdet Yücel wrote: > Selamlar, > > programming/language/python/cmemcache paketinin ev sayfasında (this > library is deprecated, old, buggy, you should not use it) diyor. > Depolarımızda bu pakete bağımlı olan bir paket de yok. Biz de depodan > çıkarsak iyi olacak gibi geliyor bana. Sitesinde artık ilgilenemiyorum demiş de yukarıdaki cümleyi göremedim ? 2009 için paketi depoya çoktan almışız, kullananlar olabilir, 2011 e ve C2 ye almamak bana mantıklı geliyor. -- Onur Küçük Knowledge speaks, but wisdom listens ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] review gunu raporu
On Sun, 26 Sep 2010 14:08:05 +0300 Necdet Yücel wrote: > KİM BİLİR: > server/web/nginx > network/remoteshell/nx > util/misc/xvkbd "kim bilir" ne demek anlamadım > Bahadır Kandemir: > network/connection/tor > network/connection/vidalia > > Fatih Aşıcı: > util/benchmark/expedite > > H. İbrahim Güngör > game/arcade/zaz > > Onur Küçük: > programming/language/python/pyactiveresource Aslında python bileşeni Bahadır'ın üzerinde > programming/profiler/google-perftools > 0 ACK: > server/web/cherokee > server/proxy/havp > server/proxy/polipo > hardware/disk/system-config-lvm > hardware/mobile/synce-hal > hardware/mobile/librra > hardware/mobile/librapi2 > hardware/mobile/kde4-kio-rapip > hardware/mobile/librtfcomp > hardware/mobile/kde4-kcemirror > network/library/openchange > programming/language/python/python-PyCg > programming/environment/gnustep/gnustep-make > programming/environment/gnustep/gnustep-gui > programming/environment/gnustep/gnustep-base > programming/library/libBSUtilities 0 ACK ne demek onu da anlamadım, bileşen sorumlusundan inceleme beklenmiyor mu ? -- Onur Küçük Knowledge speaks, but wisdom listens ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] trunk/pisi/pisi/operations - build: Guess WorkDir from archive name
On Sunday 26 September 2010 12:34:00 Fatih Aşıcı wrote: > > > directory does not exist, first try "srcname-version" then the > > > basename of archive URL after splitting extensions. > > > > > > > > Bu şekilde tahmin etmek yerine ya da son bir seçenek olarak bunlara > > alternatif olarak, ortada hiç dosya yoksa ve bir tek dizin varsa o dizini > > WorkDir bellesek olmaz mı? > > Daha önce bu öneriye listeden itiraz gelmişti diye hatırlıyorum. Arşivlere > bakayım biraz. Yanlış hatırlıyorum sanırım. Yine de aklıma sorun çıkarabilecek bir senaryo geliyor. Paketçi, work dizini altında herhangi bir amaçla dizin oluşturmak isteyebilir. Paketçinin bu özelliğe güvenip WorkDir yazmadığını düşünelim. setup aşamasında bir üst dizinde dizin oluşturuluyorsa yarıda kesilen inşalara "pisi build --package" parametresiyle devam etmek mümkün olmayacak. Çünkü artık work dizini altında iki ayrı dizin bulunacak. Arşiv adına bakmamız zaten paketlerin büyük bir çoğunluğundan WorkDir'i atmamız için yeterli. Bence work dizini gibi değişken bir yerin içeriğine dayalı böyle bir şey yapmayalım. En azından mevcut yöntemin ne kadar işe yaradığını inceleyip bunu yapmaya değip değmeyeceğine bakalım. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] katkı deposunun geleceği
2010/9/26 Necdet Yücel : > Sonuç: > > 2009/stable'ı 2011/devel olarak kopyalayıp yola devam etmek bence iyi > bir fikir değil. Katkı deposu için bir yeniden yapılanmaya ihtiyaç > var. Belki deponun adını değiştirmek (extras), sayısını arttırmak > (extras, contrib) gibi çözümler üzerinde de konuşabiliriz. > > Mutlaka bir depo politikası hazırlamalıyız contrib için diyerek buraya > kadar okuyanlara teşekkür edeyim. Katkıcıların yazabildiği tek depo olma özelliğini çok önceden kaybettiği için contrib ismi depo niteliği ile uyuşmuyor artık. Paket neye göre depoya alınır kısmını karara bağlayamadığımız için contrib deposunun şu anki belirgin farkı güvenlik ekibinin buraya bakmıyor ve paketlerin test sürecinden geçmiyor olması. Dolayısı ile depo adı unsupported ya da benzer manada bir isimle değiştirilebilir bence de. -- Türker Sezer ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] katkı deposunun geleceği
26 Eylül 2010 14:16 tarihinde Fatih Aşıcı yazdı: > On Sunday 26 September 2010 13:44:39 Necdet Yücel wrote: >> * Lisans bilgilerine göre bir ayrım yapılmış değil. Hemen hemen >> hepsinin lisansı Pardus depolarına alınmaya uygun. Kaldı ki Pardus >> depolarında özgür olmayan yazılımlar da mevcut. Demek ki lisans >> bilgisi de ayırıcı etken değil. > > Bazı paketlerin ileride dağıtılmaya devam edip edilmeyeceği belli değil. Söz > konusu bir sürücü paketi olunca kullanıcının güncelleme sonrası bir donanımı > kullanamaması da muhtemel. Bu tür durumlarla ana depoda karşılaşılması hoş > olmaz. Ben depoları lisans kısıtlamalarına göre ayırmıyoruz demek için yazmıştım. Debian'ın non-free deposu gibi değil yani bizim contrib. > Bu saydıklarına göre bence en uygun isim "unsupported" olur. Bana da contrib'den daha uygun geldi bu isim. --- Necdet Yücel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] katkı deposunun geleceği
On Sunday 26 September 2010 13:44:39 Necdet Yücel wrote: > * Lisans bilgilerine göre bir ayrım yapılmış değil. Hemen hemen > hepsinin lisansı Pardus depolarına alınmaya uygun. Kaldı ki Pardus > depolarında özgür olmayan yazılımlar da mevcut. Demek ki lisans > bilgisi de ayırıcı etken değil. Bazı paketlerin ileride dağıtılmaya devam edip edilmeyeceği belli değil. Söz konusu bir sürücü paketi olunca kullanıcının güncelleme sonrası bir donanımı kullanamaması da muhtemel. Bu tür durumlarla ana depoda karşılaşılması hoş olmaz. > Sonuç: > > 2009/stable'ı 2011/devel olarak kopyalayıp yola devam etmek bence iyi > bir fikir değil. Katkı deposu için bir yeniden yapılanmaya ihtiyaç > var. Belki deponun adını değiştirmek (extras), sayısını arttırmak > (extras, contrib) gibi çözümler üzerinde de konuşabiliriz. Bu saydıklarına göre bence en uygun isim "unsupported" olur. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] review gunu raporu
Selamlar, Yarın ders yoğunluğundan yazamayabilirim diyerek bu haftanın raporunu bugün yazıyorum. Geçen hafta cuma yerine hafta başı olsun dediğimizden bir de pazartesi'yi deneyelim bakalım. Bu hafta gözden geçirme bekleyen paketleri kimden ilgi beklediklerine göre sınıfladım. Bunun bileşene göre ayırmaktan daha işlevsel olduğunu düşünüyorum. Kolayca görüleceği gibi paketlerin önemli bir çoğunluğu (43 tanesi) bileşen sorumlusundan değil de ikinci bir geliştiriciden gözden geçirme bekliyor. Herşeyi bileşen sorumluları yapamayacağına göre diğer geliştiricilerin bu konuya biraz olsun eğilmeleri gerekiyor. İlgi bekledikleri geliştiricilere göre rapor şöyle: HERHANGİ BİRİ: server/proxy/sarg network/library/gnet multimedia/library/pigment util/antivirus/squidclamav programming/language/python/python-nltk programming/language/python/python-PyODE programming/language/python/python-pyquante programming/language/python/python-gameobjects programming/language/python/python-rpy programming/language/python/python-pygtksourceview programming/language/python/kaa-base programming/language/python/kaa-metadata programming/language/python/kaa-display programming/language/python/kaa-imlib2 programming/language/python/python-clamav programming/language/python/python-gdata programming/language/python/python-pyRXP programming/language/python/scientificpython programming/language/python/python-irclib programming/language/python/python-pygtkglext programming/language/python/python-zsi programming/language/python/python-pyyaml programming/language/python/python-tk_happy programming/language/python/pigment-python programming/language/python/python-rapyd programming/language/python/python-flickrapi programming/language/python/python-PyMT programming/language/python/python-pmw programming/tool/lemon programming/tool/clearsilver programming/library/oniguruma programming/library/libmowgli programming/library/libmcs programming/library/libconfuse programming/library/libedit programming/library/libtommath programming/library/dxflib programming/library/libbinio programming/library/xylib programming/library/xapian-core programming/library/etl programming/library/loki programming/library/redland-bindings KİM BİLİR: server/web/nginx network/remoteshell/nx util/misc/xvkbd Bahadır Kandemir: network/connection/tor network/connection/vidalia Fatih Aşıcı: util/benchmark/expedite H. İbrahim Güngör game/arcade/zaz Onur Küçük: programming/language/python/pyactiveresource programming/profiler/google-perftools Ozan Çağlayan: hardware/mobile/orange hardware/mobile/synce-sync-engine hardware/mobile/synce-kpm hardware/mobile/FUR hardware/mobile/dynamite hardware/mobile/libmimedir hardware/mobile/libsynce 0 ACK: server/web/cherokee server/proxy/havp server/proxy/polipo hardware/disk/system-config-lvm hardware/mobile/synce-hal hardware/mobile/librra hardware/mobile/librapi2 hardware/mobile/kde4-kio-rapip hardware/mobile/librtfcomp hardware/mobile/kde4-kcemirror network/library/openchange programming/language/python/python-PyCg programming/environment/gnustep/gnustep-make programming/environment/gnustep/gnustep-gui programming/environment/gnustep/gnustep-base programming/library/libBSUtilities --- Necdet Yücel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Build numaraları
25 Eylül 2010 16:39 tarihinde Fatih Aşıcı yazdı: > Kısacası, çok büyük bir kod değişikliği önermiyorum. Üstelik sonunda debug > paketlerini de kolay bir şekilde kullanabileceğiz. Özellikle daha temiz ve > kaliteli bir pisi'ye sahip olacağımız için benim çok işime gelecek :) > > Fikirleriniz? Geliştiricisinin bu kadar ayrıntılı ve olumlu yazdığı bu değişikliğe benden +1 ;) --- Necdet Yücel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] katkı deposunun geleceği
Selamlar, Hazır 2011 için önemli değişiklikler yapılırken katkı deposunda da bir iyileştirme yapalım ve yeniden yapılandıralım diye öneriyorum. Şu anki haliyle contrib depo nedir, bu depoya nasıl paketler alınmalıdır konusunda güncel bir belge yok. Eskiden durum daha farklı olabilir ama şu anki haliyle neden bir katkı depomuz var ben bilmiyorum. * Katkı deposundaki paketlerin tamamının bakımı diğer depolarda da paketleri olan geliştiriciler tarafından yapılıyor. Yani katkıcıların deposu olma gibi bir özelliği yok. * Lisans bilgilerine göre bir ayrım yapılmış değil. Hemen hemen hepsinin lisansı Pardus depolarına alınmaya uygun. Kaldı ki Pardus depolarında özgür olmayan yazılımlar da mevcut. Demek ki lisans bilgisi de ayırıcı etken değil. * Pardus depolarında aynı işi yapan paketler bulunduğundan katkı deposunda bulunmuyor paketlerin büyük çoğunluğu. 2009/contrib deposunda Pardus depolarında muadili olmayan paketler olduğu gibi zaten Pardus depolarında aynı işi yapan programlar da var. Mesela neden enlightenment 2009 deposunda da xfce contrib'te? * Pardus ve contrib depolarına paket alımı konusunda da bir farklılık yok. İki depoya da aynı review sürecini işleterek paket alıyoruz. * Contrib deposundaki paketler 2009'a göre çok daha bakımsız durumda. 200'den fazla paketin translations.xml dosyası bulunmuyor. Uzun süredir güncellenemeyenler, artık sürdürülmeyen projeler saymakla bitmez. * Özellikle contrib/devel playground gibi kullanılmış, hala da öyle kullananlar var. Sonra ilgilenirim diye paketler playground'a değil contrib/devel'e taşınabiliyor. * Güvenlik ekibi contrib deposu ile ilgilenmiyor. Bu önemli bir fark ama deponun varlık nedeni değil elbette. * Contrib depo için bir ACK/NACK süreci işletilmiyor. * Contrib deponun ayrı bir sorumlusu yok. * Contrib/stable'da bakıcısı olan paket sayısı çok az. Şu an 415 paket var görünüyor ama geliştiriciliği bırakmış veya devel deposunda sahipsiz olarak işaretlendiği halde stable'a merge edilmeyen paketler hesaba katılırsa paketçisi olan paket sayısı çok daha az çıkacaktır. Sonuç: 2009/stable'ı 2011/devel olarak kopyalayıp yola devam etmek bence iyi bir fikir değil. Katkı deposu için bir yeniden yapılanmaya ihtiyaç var. Belki deponun adını değiştirmek (extras), sayısını arttırmak (extras, contrib) gibi çözümler üzerinde de konuşabiliriz. Mutlaka bir depo politikası hazırlamalıyız contrib için diyerek buraya kadar okuyanlara teşekkür edeyim. --- Necdet Yücel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] trunk/pisi/pisi/operations - build: Guess WorkDir from archive name
26 Eylül 2010 12:34 tarihinde Fatih Aşıcı yazdı: >> Bu şekilde tahmin etmek yerine ya da son bir seçenek olarak bunlara >> alternatif olarak, ortada hiç dosya yoksa ve bir tek dizin varsa o dizini >> WorkDir bellesek olmaz mı? Bu benim de aklıma geliyor hep. Bir problem çıkarmayacaksa çok fazla pakette WorkDir yazmaktan kurtarır bizi. > Daha önce bu öneriye listeden itiraz gelmişti diye hatırlıyorum. Arşivlere > bakayım biraz. --- Necdet Yücel ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] trunk/pisi/pisi/operations - build: Guess WorkDir from archive name
On Sunday 26 September 2010 08:47:20 Gökçen Eraslan wrote: > 26 Eylül 2010 Pazar günü (saat 00:31:19) Fatih Aşıcı şunları yazmıştı: > > If defined, use WorkDir in actions.py. If it is not defined or the > > Tanımlanan dizin yoksa, hata vererek paketçiyi WorkDir'in değiştirilmesine > zorlaması daha iyi olur bence. Yani, paketçi eğer inisiyatif alıp WorkDir'i > elle giriyorsa, ve o dizin yoksa muhakkak haberdar edilmeli diye > düşünüyorum. Arada bir elle snapshot'ı alınan paketlerde hep WorkDir değiştirdiğimi düşünerek bunun faydalı olacağını düşünmüştüm; ama bu, bazı hataların gözden kaçmasına da neden olabilir. Söylediğin şekilde değiştireceğim. > > directory does not exist, first try "srcname-version" then the > > basename of archive URL after splitting extensions. > > Bu şekilde tahmin etmek yerine ya da son bir seçenek olarak bunlara > alternatif olarak, ortada hiç dosya yoksa ve bir tek dizin varsa o dizini > WorkDir bellesek olmaz mı? Daha önce bu öneriye listeden itiraz gelmişti diye hatırlıyorum. Arşivlere bakayım biraz. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
