Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Fatih Aşıcı 
On Tuesday 04 January 2011 17:01:34 Gökçen Eraslan wrote:
> Selamlar,

Selamlar,
 
> 0- Skype paketi sadece 32 bit dağıtıldığı için (Ubuntu için hazırlanmış 64
> bit de aslında 32bit), 64bit depoya, Skype'ın bağımlılığı olan 32bit
> paketleri(alsa-lib vs) de almamız gerekiyor ve bunların 64bit olanlarıyla
> çakışmadan, mutlu mesut yaşayabiliyor olmaları lazım. Wine için de benzer
> bir durum var, 64bit Pardus'ta, 32bit Windows uygulamalarını wine'da
> çalıştırabilmek için yine, wine ve bağımlılıklarının da 64bit depoya
> alınması gerekiyor. İstersek şu anda *sadece 32bit depoya* wine ve skype'ı
> alabiliriz ExcludeArch sağolsun, fakat bu çözüm olmaz. Workaround bile
> olmaz.

32 bit farmda derlenmiş paketleri dönüştürmek bence sağlıklı bir şey değil. 
Zaten bu yöntemde bilinen sorunlar da var. Örneğin gtk'nın config dosyalarında 
modüllerin tam yolları geçiyor. Bunları nasıl lib32'ye çevireceğiz? Bu tür 
sorunlar yüzünden Arch Linux'un bu yöntemi bırakıp farklı bir depo açtığını 
biliyorum.

Bence 32bit paketleri ayrı source paketlerden çıksın. Gerekmedikçe bazı 
özellikler bu paketlerde etkisiz hale getirebilir. Böylece gereksiz 
bağımlılıkların bağımlılıklarını paketlememiş oluruz. Bu paketlerin ayrı bir 
depoda yer alıp almamasını tartışmamız lazım.

Bu arada skype için Fatih Arslan ile beraber bugün/yarın bir şeyler 
deneyeceğiz.
 
> 1- Pisi delta desteğini açmamız gerekiyor, hem delta'yı test etmeye devam
> ederiz, yeni pisi ile ilgili bir sorun olmadığından emin oluruz hem de
> bonus olarak insanlara daha küçük boyutlu güncellemeler gider. Bunun için
> Fatih'in sanırım pisi'de yapacağı şeyler var.

Aslında üzerimdeki tüm işleri bırakıp pisi'ye yönelmem lazım. delta ile ilgili 
eski farmda bazı kısımlar vardı. Bunların yerinin farm olmadığını düşünerek 
attık. Bazı şeyleri (build sonrası otomatik delta oluşturma gibi) pisi kendisi 
yapabiliyor; fakat bazı şeyler eksik. Bunlar:

  * Bazı paketlerin deltasının üretilmesini engellemek
  * Sürüm günü depoda bulunan paketler için her zaman delta üretilmesini
sağlamak.

Pisi'nin bu bilgileri alacağı dosyaların formatına ve yerine karar vermem 
gerekiyor.
 
> 3- OpenOffice/LibreOffice extension'larıyla (zemberek ve OO paketinden
> gelenler) ciddi bir sorunumuz var. OpenOffice-LibreOffice geçişinde, önce
> OO silinip LO geliyor, ardından da aynı işlem eklentiler için yapılmaya
> çalışılıyor fakat bu işlem için gereken unopkg programı artık yeni LO'dan
> geldiği için eklentiler kaldırılamıyor/kurulamıyor. Benim daha önce
> eklenti betiklerine sorunların gözden kaçmaması için eklediğim strict
> kontroller yüzünden direk exception alınıyor. Bunun en kötü tarafı ise, ne
> kadar güncelleme gelirse gelsin kullanıcıların makinesindeki preremove'lar
> çalıştığı için, bunun şu anda pratik bir çözümünün olmaması. Bunu da
> acilen çözmemiz gerek. Aynı sorun, Kurumsal2'de de mevcut bu arada.

Pisi'nin neden bir preInstall metodunun olmadığını anlamakta zorlanıyorum. 
Bazı şeyleri hep ihtiyaç duyunca gerçeklemişiz. Oysa en basitinden rpm'e 
bakılsa bu tür şeylere zamanı gelince ihtiyaç duyulduğu anlaşılabilirdi. 
Burada da pisi tarafında yapılması gereken önemli işler var.

Bir diğer çözüm yeni pisi'de preRemove vs hatalarını ignore etmek olabilir. 
2011'e geçilirken önce yeni pisi'ye geçileceği için yukarıdaki senaryoyu 
kurtarabiliriz belki.
 
> 5- Pae kernel hazırlayacak mıyız? Her ne kadar 64 bit sürümümüz olsa da,
> 64bit desteği olmayan ama >= 4G ram kullanan kullanıcıların daha mutlu
> olması için güzel olur.

Aslında sadece tek bir template kullanıp aynı source paketlerden otomatik 
olarak default ve pae kernel'e ait paket dosyalarının üretilmesini 
sağlayabiliriz belki. Uğraşmak/düşünmek lazım.
 
> 6- zorg komutunun akıbeti ve konsoldan sürücü değiştirmeyi tartışmamız
> gerekiyor. Fatih sanırım zorg komutunu kaldırmayı planlıyor, bana
> sorarsanız da daha önceden kullanıcılara sunduğumuz nimetler olarak
> bakarsak, vazgeçmek için sıkı nedenlerimiz olmalı. Fatih?

Statik yapılandırmadan kurtulmak istiyorum. Kullanıcılar bunu yanlış şekilde 
kullanıp başlarına daha fazla iş açıyorlar.

Yeni altyapıda "sürücü seçimi" yerine "sürücü tercihi" hakim. Yani "Şu 
sürücüyü kullan" demek yerine "Şu durumda şu sürücüyü tercih et" diyoruz. Bu 
donanım değişikliklerinde yeni donanımın düzgün bir şekilde kullanılabilmesini 
sağlıyor. Üstelik eski donanıma ait tercihler silinmiyor. Böylece birden fazla 
ekran kartı olan bir sistemde yapılandırma değişmiyor.

Yeni altyapıda xorg.conf da yazılmıyor (nvidia-settings ve catalyst 
kullanıyor). xorg.conf'un olmaması X sunucusundaki otomatik algılama kodunun 
çalışmasını sağlıyor. Bu yüzden bu dosyanın olmaması daha iyi.

Artık KMS sürücülerimiz var. Bazı seçimlerin initramfs aşamasında yapılması 
gerekiyor. KMS sürücüsü bir defa yüklendiği zaman nvidia ve fglrx sürücüleri 
çalışmıyor. Diğer taraftan KMS'nin durumu kernel parametrelerine göre de 
değişebiliyor. Dolayısıyla statik bir yapılandırma belirli kernel 
parametreleri veril

Re: [Gelistirici] Ciddi sorunlar, sesli düşünc eler

2011-01-04 Başlik Renan Çakırerk 

Fethican Coşkuner wrote On 04-01-2011 18:22:

Maalesef buradaki rakamlara bakarak pae kullanıcı sayıları üzerine
varsayım yapamayız. Çünkü;

- O sayfadaki veriler son 90 gün içinde gönderim yapmış olanların
istatistiğini yansıtıyor.

Daha fazla olabilse iyi olurdu ama son 3 ay taslak bir profil çizebilecek kadar 
yeterli.


- Tahminimce kullanıcıların hepsi firstboot sırasında kaptan ile
smolt profili gönderimi yapıyorlar. Pae çekirdek ise kurulumdan sonra
yükleniyor yani pae kurulumu yaptıktan sonra smolt profili
gönderenlerin istatistiği o.
Çok haklısın bunu düşünmemiştim. PAE istatistiğini çöpe atalım, fakat 2 
GB ve altında RAM'i olan kullanıcı oranının %70 olduğunu gösteren 
istatistik hala geçerli.


Ne var ki geri kalan %30'luk kesimden ne kadarının 4 GB ve üstünde 
olduğunu bilmiyoruz. Ayrıca bu bilmediğimiz kesmin ne kadarının 32 bit 
işlemci kullandığını da bilmiyoruz. Tahminimce oldukça az bir rakam 
çıkacaktır. Tahminle olmaz bu işler derseniz; Smolt'u kurcalayarak 
bunları öğrenmek mümkün mü Fethican?



   Oradaki rakamların her zaman güvenilebilir olmasının yolu smolt'un
ayda bir kere gönderim yapmak üzere cronlanması ki biz bu işlemi
yapmıyoruz.

Smolt'un işe yararlılığını ve etkin kullanmak için ne yapmamız 
gerektiğini tartışabileceğimiz bir mail atabilirsen listeye harika olur 
öyleyse. Eğer bu gibi durumlarda verilerimize güvenemiyorsak bir 
yerlerde bir sorun var demektir çünkü.



Bence her zaman 32bit +<3,5gb ram kullanmak için
kullanıcıların çeşitli sebepleri olacaktır. Yapabiliyorsak yapalım
derim ben.



Ali Işıngör wrote On 04-01-2011 21:27:
Topluluk forumundan aldığım geri dönüşler ve katıldığımız seminerler 
ve etkinliklerde kullanıcılarımızla yaptığımız konuşmalara bakarak 
şunu söyleyebilirim: PAE kullanıcılarının sayısı hızla düşüyor, önemli 
bir kısmı şimdiden 64 bit Pardus 2011'e geçti bile.


Masrafı nedir bilmiyorum ama 20 Ocak sonrasına bırakılabilecek önemde, 
tâli bir iş gibi geliyor bana PAE çekirdek.


Ekin Meroğlu wrote On 04-01-2011 23:49:

2011 için bu test edilecek bir yeni konf. demek, çok acil/gerekli değil
bence.


İşte yapabiliyorsak lafı tehlikeli. Yapmasına yapılır, fakat böyle bir 
tabloda PAE'ye ayrılacak iş gücünün diğer kritik paketlerin 
iyileştirilmesine harcanması daha mı doğru olur? Bence evet.


--
Renan Cakirerk
TUBITAK / UEKAE - Pardus Core Developer
http://www.pardus.org.tr

___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] 2009/stable/tex/tool/hevea - Merge from devel/tex/tool/hevea/

2011-01-04 Başlik Fatih Arslan 
On Tue, 4 Jan 2011 23:21:33 +0200, Onur Küçük  
wrote:



 Derletiyor muyuz şimdi paketi ?


İbrahim son anda gelip söyledi, paket benimmiş :) Sadece paket alımı 
yaptım o kadar.
Derlemezsek ne olur ? Bu gibi durumlarda prosedür nasıl işlenir 
bilmediğim için soruyorum


Fatih Arslan

___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Ekin Meroğlu 
Merhaba,

On Tue, 2011-01-04 at 15:01 +, Gökçen Eraslan wrote:
> 0- Skype paketi sadece 32 bit dağıtıldığı için (Ubuntu için hazırlanmış 64 
> bit 
> de aslında 32bit), 64bit depoya, Skype'ın bağımlılığı olan 32bit 
> paketleri(alsa-lib vs) de almamız gerekiyor ve bunların 64bit olanlarıyla 
> çakışmadan, mutlu mesut yaşayabiliyor olmaları lazım. Wine için de benzer bir 
> durum var, 64bit Pardus'ta, 32bit Windows uygulamalarını wine'da 
> çalıştırabilmek için yine, wine ve bağımlılıklarının da 64bit depoya alınması 
> gerekiyor. İstersek şu anda *sadece 32bit depoya* wine ve skype'ı alabiliriz 
> ExcludeArch sağolsun, fakat bu çözüm olmaz. Workaround bile olmaz.

Bu sorun hem 2011 hem de K2 için en acil dertlerimizden birisi aslında -
skype ve wine dışında, üreticisi tarafından binary dağıtılan bir seri
yazılım da aynı dertten muzdarip. 32 bit depoda derlenen paketlerden
gerekli libleri toplayıp 64 bit depo için bir paket haline getirmekten
bahsediyordu Onur, hızlıca onu hayata geçirebilir miyiz - diğer
dağıtımlar öyle yapıyordu sanki. 
Bu tip bir 32-bit-libs paketinin çözemeyeceği bir eksikliğimiz var mı ?
  
> 1- Pisi delta desteğini açmamız gerekiyor, hem delta'yı test etmeye devam 
> ederiz, yeni pisi ile ilgili bir sorun olmadığından emin oluruz hem de bonus 
> olarak insanlara daha küçük boyutlu güncellemeler gider. Bunun için Fatih'in 
> sanırım pisi'de yapacağı şeyler var.

ne kadar erken o kadar iyi..

> 3- OpenOffice/LibreOffice extension'larıyla (zemberek ve OO paketinden 
> gelenler) ciddi bir sorunumuz var. OpenOffice-LibreOffice geçişinde, önce OO 
> silinip LO geliyor, ardından da aynı işlem eklentiler için yapılmaya 
> çalışılıyor fakat bu işlem için gereken unopkg programı artık yeni LO'dan 
> geldiği için eklentiler kaldırılamıyor/kurulamıyor. Benim daha önce eklenti 
> betiklerine sorunların gözden kaçmaması için eklediğim strict kontroller 
> yüzünden direk exception alınıyor. Bunun en kötü tarafı ise, ne kadar 
> güncelleme gelirse gelsin kullanıcıların makinesindeki preremove'lar 
> çalıştığı 
> için, bunun şu anda pratik bir çözümünün olmaması. Bunu da acilen çözmemiz 
> gerek. Aynı sorun, Kurumsal2'de de mevcut bu arada.

LO'nun içine eski OO'dan gelen unopkg'yı da koyalım, yeni eklentileri
yamalayalım, akıllı olsunlar yeni unopkg'yı kullansınlar - son derece
kirli ama..  

K2'de zemberek ile türkçe imla denetimi patlak, bu sorunla aynı mı ? 

> 5- Pae kernel hazırlayacak mıyız? Her ne kadar 64 bit sürümümüz olsa da, 
> 64bit 
> desteği olmayan ama >= 4G ram kullanan kullanıcıların daha mutlu olması için 
> güzel olur.

2011 için bu test edilecek bir yeni konf. demek, çok acil/gerekli değil
bence.

> 6- zorg komutunun akıbeti ve konsoldan sürücü değiştirmeyi tartışmamız 
> gerekiyor. Fatih sanırım zorg komutunu kaldırmayı planlıyor, bana sorarsanız 
> da daha önceden kullanıcılara sunduğumuz nimetler olarak bakarsak, vazgeçmek 
> için sıkı nedenlerimiz olmalı. Fatih?

Ben bu tip hayat kurtarıcı "son seçenek"lerin her durumda kalmasından
yanayım. 

ekin.

___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] 2009/stable/tex/tool/hevea - Merge from devel/tex/tool/hevea/

2011-01-04 Başlik Onur Küçük 

On Tue,  4 Jan 2011 16:32:11 +0200 (EET)
Fatih Arslan  wrote:

> Author: fatih.arslan
> Date: Tue Jan  4 16:32:11 2011
> New Revision: 109422
> 
> Modified:
>2009/stable/tex/tool/hevea/   (props changed)
>2009/stable/tex/tool/hevea/pspec.xml
> Log:
> Merge from devel/tex/tool/hevea/:
> 
> rev. 109406, by fatih.arslan on 2011-01-04
> Takeover of package
> 
> ---
>  pspec.xml |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Modified: 2009/stable/tex/tool/hevea/pspec.xml
> =
> --- 2009/stable/tex/tool/hevea/pspec.xml  (original)
> +++ 2009/stable/tex/tool/hevea/pspec.xml  Tue Jan  4 16:32:11
> 2011 @@ -5,8 +5,8 @@
>  hevea
>  http://pauillac.inria.fr/~maranget/hevea
>  
> -H. İbrahim Güngör
> -ibra...@pardus.org.tr
> +Fatih Arslan
> +fars...@pardus.org.tr
>  
>  OPL
>  app:console

 Derletiyor muyuz şimdi paketi ?


-- 
 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] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Ali Işıngör 
2011/1/4 Gökçen Eraslan 

> Selamlar,
>
> 2011 sürümü için ciddi sorunlarımızı tartışalım, çözümler bulalım.
>
> 0- Skype paketi sadece 32 bit dağıtıldığı için (Ubuntu için hazırlanmış 64
> bit
> de aslında 32bit), 64bit depoya, Skype'ın bağımlılığı olan 32bit
> paketleri(alsa-lib vs) de almamız gerekiyor ve bunların 64bit olanlarıyla
> çakışmadan, mutlu mesut yaşayabiliyor olmaları lazım. Wine için de benzer
> bir
> durum var, 64bit Pardus'ta, 32bit Windows uygulamalarını wine'da
> çalıştırabilmek için yine, wine ve bağımlılıklarının da 64bit depoya
> alınması
> gerekiyor.
>


Bu tartışmaya teknik olmayan bir katkıda bulunacağım.

Skype, Wine ve dolayısıyla PlayOnLinux, kullanıcı tarafında yokluğu sıkıntı
yaratacak yazılımlar. Belki bunu söylemek çok acı ama 2011'de hangi
teknolojileri geliştirdiğimizle çoğu zaman ilgilenmiyor kullanıcı, günlük
yaşamda kullandığı araç ve yazılımların elinin altında olmasını çok daha
fazla önemsiyor.

21 Ocak günü mevcut kullanıcı tabanımızda gerçeklenecek senaryoyu
söyleyeyim:  Kullanıcılarımızın azımsanmayacak bir kısmı, "Yeni sürüm
çıkmışsa daha iyidir" diye düşünecek ve Pardus 2009'unu kullandığı alana
Pardus 2011'i kuracak. Bir gün önce Pardus 2009'da kullanabildiği bu
araçları depoda bulamaması durumunda; bir kısım kullanıcımızın 2009'a geri
dönmeyip, Vista ya da Windows 7 kuracaklarının bilincinde olduğumuzu
düşünüyorum.
Bu yazılımlar hayati önemde.



>
> 2- 2009'da olan paketlerin, 2011 depolarına alınması gerekiyor acilen. Hem
> 2009-2011 geçişi için hem de kullanıcıların 2009'da kullandıkları
> programları
> 2011'de de sağlamamız gerektiği için aciliyet söz konusu.
>


Gökçen'i destekleyecek bazı rakamları vereyim hemen:

2009 stable deposundaki kaynak paket sayısı: *2.655*
2009 contrib deposundaki kaynak paket sayısı: *407*
2011 devel deposundaki kaynak paket sayısıysa: *2.156
*
Arada *900 kadar* bir fark var. Hadi bunların bir kısmı yazıtipiydi, bir
kısmı Contrib'deki ölü yazılımlardı ama yine de önemli bir fark mevcut.




>
> 5- Pae kernel hazırlayacak mıyız? Her ne kadar 64 bit sürümümüz olsa da,
> 64bit
> desteği olmayan ama >= 4G ram kullanan kullanıcıların daha mutlu olması
> için
> güzel olur.
>


Topluluk forumundan aldığım geri dönüşler ve katıldığımız seminerler ve
etkinliklerde kullanıcılarımızla yaptığımız konuşmalara bakarak şunu
söyleyebilirim: PAE kullanıcılarının sayısı hızla düşüyor, önemli bir kısmı
şimdiden 64 bit Pardus 2011'e geçti bile.

Masrafı nedir bilmiyorum ama 20 Ocak sonrasına bırakılabilecek önemde, tâli
bir iş gibi geliyor bana PAE çekirdek.



7- Öntanımlı uygulamalara karar verelim. Bunun için ayrı thread açacağım, bu
> thread zaten yeterince dallanacak diye tahmin ediyorum.
>


Topluluk tarafındaki genel eğilimleri öğrenmek için forumda anketler
açabiliriz bunun için. Elimizde böyle bir olanak var, bilginize.



>
> 10- Sürüm notlarını, Farslan'ın depoya aldığı publican ile ürettirmek
> istiyorum. docbook formatında yazdığımızda hem çevrilmesi kolay olacak hem
> de
> publican sayesinde süslü HTML'ler ürettirebileceğiz.
>


Bunun için lütfen Transifex'i kullanalım :).
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Fethican Coşkuner 
On Tue, 04 Jan 2011 16:48:59 +0200
Renan Çakırerk  wrote:

> [1] adresindeki istatistiklerde şimdiye kadar sistem bilgilerini 
> göndermiş kullanıcıların
> 
> - yalnızca %0.5'inin pae-kernel kullandığını
> - %70'inin 2 veya daha fazla çekirdekli işlemciye sahip olduğunu
> - yine %70'inin 2 GB ve daha altında RAM'e sahip olduğunu
> 
> görebiliyoruz.
> 
> Rakamlar çok sağlıklı bir profil çizmese de pae-kernel hazırlamanın 
> gereksiz olduğunu gösteriyor fikrimce.
> 
> [1] http://smolt.pardus.org.tr:8090/static/stats/stats.html

Maalesef buradaki rakamlara bakarak pae kullanıcı sayıları üzerine
varsayım yapamayız. Çünkü;

- O sayfadaki veriler son 90 gün içinde gönderim yapmış olanların
istatistiğini yansıtıyor.
- Tahminimce kullanıcıların hepsi firstboot sırasında kaptan ile
smolt profili gönderimi yapıyorlar. Pae çekirdek ise kurulumdan sonra
yükleniyor yani pae kurulumu yaptıktan sonra smolt profili
gönderenlerin istatistiği o.

  Oradaki rakamların her zaman güvenilebilir olmasının yolu smolt'un
ayda bir kere gönderim yapmak üzere cronlanması ki biz bu işlemi
yapmıyoruz.

   Bence her zaman 32bit + <3,5gb ram kullanmak için
kullanıcıların çeşitli sebepleri olacaktır. Yapabiliyorsak yapalım
derim ben. 


---
Fethican
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Renan Çakırerk 

Gökçen Eraslan wrote On 04-01-2011 17:01:

5- Pae kernel hazırlayacak mıyız? Her ne kadar 64 bit sürümümüz olsa da, 64bit
desteği olmayan ama>= 4G ram kullanan kullanıcıların daha mutlu olması için
güzel olur.


[1] adresindeki istatistiklerde şimdiye kadar sistem bilgilerini 
göndermiş kullanıcıların


- yalnızca %0.5'inin pae-kernel kullandığını
- %70'inin 2 veya daha fazla çekirdekli işlemciye sahip olduğunu
- yine %70'inin 2 GB ve daha altında RAM'e sahip olduğunu

görebiliyoruz.

Rakamlar çok sağlıklı bir profil çizmese de pae-kernel hazırlamanın 
gereksiz olduğunu gösteriyor fikrimce.


[1] http://smolt.pardus.org.tr:8090/static/stats/stats.html

--
Renan Cakirerk
TUBITAK / UEKAE - Pardus Core Developer
http://www.pardus.org.tr

___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Gökmen Göksel 
Salı 04 Ocak 2011 günü (saat 17:01:34) Gökçen Eraslan şunları yazmıştı:
> Selamlar,
Selamlar,

> 8- 2009-2011 geçişi için testler yapmalı, upgrade-manager uygulaması
> yazmalı(Gökmen bunun için gönüllü) ve geçişi tamamlamalıyız. Bu sanırım her
> sürümde olduğu gibi yine 2011'in çıkışına yetişmeyecek ama sonrasında hızla
> yapabiliriz diye ümit ediyorum. Bununla ilgili Metin de playground'unda
> bizim NM'den Gnome Nm'ye profillerin dönüştürülmesi için bir betik
> yazıyor, bu sayede 2009'da geçiş sonrası network profilleri de korunmuş
> olacak.
Bu konuda bazı fikirler gelmişti aklıma, buraya da yazalım unutulmasın;

Uygulamanın muhtemel işleyişinin yemek tarifi tadındaki hikayesi..
 
 - 2009 kullanıcısı Paket Yöneticisi'nden Upgrade-Manager'ı yükler,
 - Uygulamayı yetkili kullanıcı ile çalıştırır,
 - 2011 deposundan öncelikle Pisi güncellenir,
 - Yeni pisi ile güncellemeler belirlenir, indirelecek dosya boyutu ve 
   diskteki boş alan belirlenir,
 - Herşey uygun gözükürse öncelikle paketleri indirir,
   (Bu sırada kullanıcı bilgisayarını kullanmaya devam edebilir)
 - İndirme tamamlandıktan sonra upgrade-manager kendisini öntanımlı grafik 
uygulama olarak ayarlar (Yalı gibi) ve kullanıcının onayı ile 
bilgisayar 
   yeniden başlatılır,
 - 2009 kullanıcısının bilgisayarı yeniden başlatıldığında bu sefer karşısına
   kdm/xdm yerine Upgrade-Manager'ın kendisi gelir (ki bu uygulama yetkili 
   kullanıcı hakları ile çalışmaktadır)
 - upgrade-manager hali hazırda indirilmiş ve kurulmaya hazır paketleri 
   sisteme yükler ve gerekli betikleri çalıştırır,
 - Kurulum/güncelleme sonunda yine kullanıcının onayı ile bilgisayar yeniden 
   başlatılır..

 - Ta taa 2011 \o/

-- 
Gökmen Göksel
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Renan Çakırerk 

İşbaran Akçayır wrote On 04-01-2011 15:52:
2009 -> 2011 geçişindeki review i diyorum, normalde de yok mu review 
zorunluluğu ?


2009 -> 2011 geçişinde yalnızca contib deposundan 2011'e geçecek 
paketler için review zorunluğu var.


--
Renan Cakirerk
TUBITAK / UEKAE - Pardus Core Developer
http://www.pardus.org.tr

___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Mehmet Emre Atasever 
On Tue, 4 Jan 2011 15:01:34 +
Gökçen Eraslan  wrote:

> Selamlar,
> 
> 2011 sürümü için ciddi sorunlarımızı tartışalım, çözümler bulalım.
> 
> 0- Skype paketi sadece 32 bit dağıtıldığı için (Ubuntu için hazırlanmış 64 
> bit 
> de aslında 32bit), 64bit depoya, Skype'ın bağımlılığı olan 32bit 
> paketleri(alsa-lib vs) de almamız gerekiyor ve bunların 64bit olanlarıyla 
> çakışmadan, mutlu mesut yaşayabiliyor olmaları lazım. Wine için de benzer bir 
> durum var, 64bit Pardus'ta, 32bit Windows uygulamalarını wine'da 
> çalıştırabilmek için yine, wine ve bağımlılıklarının da 64bit depoya alınması 
> gerekiyor. İstersek şu anda *sadece 32bit depoya* wine ve skype'ı alabiliriz 
> ExcludeArch sağolsun, fakat bu çözüm olmaz. Workaround bile olmaz.
> 

Bunun için 64bit depolara 32bit depo eklenebilmesini ve kontrollü bir şekilde 
kurulmalarını sağlayabiliriz.

32bit bir uygulamayı 64bit bir sisteme kurduğumuzda, eğer kurulmak istenen 
32bit paket sistemde yoksa paketin tamamını (80386 ELF section una sahip 
binaryler, man lar, config ler vs. de dahil olmak üzere). Kurarken, /lib altına 
gidecek kitaplıklar /lib32 dizinine, /usr/lib dizinine gidecek kitaplıklar da 
/usr/lib32 dizinine kopyalanır.

Eğer bir paketin 64bit versiyonu sistemde kurulu ve bir uygulama bu paketin 
32bit paketine ihtiyaç duyuyorsa (örneğin skype'ın kullandığı alsa-lib 
kitaplığı), 32 bit paketin *sadece 32bit kitaplıklarını* /lib32-/usr/lib32 
altına kurarız.

Örneğin skype paketi için, 64 bit depomuzda skype paketimiz olmadığından 32bit 
skype paketinin bütün içeriği 64bit sisteme kurulur, runtime bağımlılıklarının 
da sadece kitaplıklarını /lib32-/usr/lib32 altına kurarız;

$ pisi info alsa-lib -F | grep lib
/usr/lib/alsa-lib/smixer/smixer-ac97.so -> /usr/lib32
/usr/lib/alsa-lib/smixer/smixer-hda.so -> /usr/lib32
/usr/lib/alsa-lib/smixer/smixer-python.so -> /usr/lib32
/usr/lib/alsa-lib/smixer/smixer-sbase.so -> /usr/lib32
/usr/lib/libasound.so -> /usr/lib32
/usr/lib/libasound.so.2 -> /usr/lib32
/usr/lib/libasound.so.2.0.0 -> /usr/lib32
...

Bu yaklaşımdaki sorun, 32bit sistemin bütün system.base'ini 64bit sisteme 
kurmamız gerekecek veya depodaki bütün paketlere system.devel ve system.base 
componentindeki bağımlılıkları da yazarız.

-- 
@memre.
__EOM
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşünc eler

2011-01-04 Başlik Mete Alpaslan 
On Tuesday, January 04, 2011 03:56:06 pm Çağlar Kilimci wrote:
> > 2009 -> 2011 geçişindeki review i diyorum, normalde de yok mu review
> > zorunluluğu ?
> 
> Benim bildiğim kadarıyla 2009 da olan paketi 2011 için hazırlayınca review 
> olmuyor.

2009 contib deposundan paket 2011 deposuna alinacaksa review oluyor. 
-- 
Mete ALPASLAN

Pardus Core Developer

___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

[Gelistirici] Geliştirici adaylarına atanacak hatalar hakkında

2011-01-04 Başlik Renan Çakırerk 

Merhaba,

Bildiğiniz gibi geliştirici alım sürecinde adaylar sınavı geçtikten 
sonra [1] adresinde bulunan ve geliştiriciler tarafından "JUNIORJOBS" 
ile anahtarlanmış hatalardan birini çözmek üzere seçiyor. Hata 
kendilerine atandıktan sonra hata ile ilgilenen geliştiricilerden biri 
adaya danışmanlık yapıyor.


JUNIORJOBS olarak anahtarlanmış projelerimiz şu anda oldukça yetersiz.

Adayların daha sağlıklı bir seçim yapmaları açısından hataların 
çeşitliliği ve uygunluğu kilit nokta olduğu için sizlerden ricam;


hata.pardus.org.tr altında, tecrübelerinize dayanarak "bir geliştirici 
adayının çözebileceğini ve çözerken tecrübe kazanacağını" düşündüğünüz 
hataları en kısa zamanda JUNIORJOBS anahtarıyla işaretlemeniz.


Geliştirici alım süreci detaylarını [2] adresinde bulabilirsiniz .

Teşekkürler ve iyi çalışmalar,

[1] http://bugs.pardus.org.tr/buglist.cgi?keywords=JUNIORJOBS
[2] 
http://developer.pardus.org.tr/guides/newcontributor/how-to-be-contributor.html 



--
Renan Çakırerk
TUBITAK / UEKAE - Pardus Core Developer
http://www.pardus.org.tr

___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Çağlar Kilimci 
On Tuesday, January 04, 2011 03:52:01 pm İşbaran Akçayır wrote:

> 2009 -> 2011 geçişindeki review i diyorum, normalde de yok mu review
> zorunluluğu ?

Benim bildiğim kadarıyla 2009 da olan paketi 2011 için hazırlayınca review 
olmuyor.

-- 
Çağlar Kilimci
TÜBİTAK - UEKAE / Pardus
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik İşbaran Akçayır 
2011/1/4 Semen Cirit 

> On Tue, 4 Jan 2011 15:05:24 +0200, İşbaran Akçayır 
> wrote:
>
>> 2011/1/4 Gökçen Eraslan 
>>
>>  Selamlar,
>>>
>>>  Merhaba,
>>
>>  2011 sürümü için ciddi sorunlarımızı tartışalım, çözümler bulalım.
>>>
>>> 2- 2009'da olan paketlerin, 2011 depolarına alınması gerekiyor acilen.
>>> Hem
>>> 2009-2011 geçişi için hem de kullanıcıların 2009'da kullandıkları
>>> programları
>>> 2011'de de sağlamamız gerektiği için aciliyet söz konusu.
>>>
>>>
>>>  2009->2011 geçişinde review zorunluluğunu kaldırsak fena olmaz. En
>> azından
>> benim bir miktar geçireceğim paket var bu yüzden geçirmiyorum
>>
>>  Contrib'de bulunan paketlerin için demek istiyorsun sanırım.
>

2009 -> 2011 geçişindeki review i diyorum, normalde de yok mu review
zorunluluğu ?
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Semen Cirit 
On Tue, 4 Jan 2011 15:05:24 +0200, İşbaran Akçayır  
wrote:

2011/1/4 Gökçen Eraslan 


Selamlar,


Merhaba,



2011 sürümü için ciddi sorunlarımızı tartışalım, çözümler bulalım.

2- 2009'da olan paketlerin, 2011 depolarına alınması gerekiyor 
acilen. Hem

2009-2011 geçişi için hem de kullanıcıların 2009'da kullandıkları
programları
2011'de de sağlamamız gerektiği için aciliyet söz konusu.


2009->2011 geçişinde review zorunluluğunu kaldırsak fena olmaz. En 
azından

benim bir miktar geçireceğim paket var bu yüzden geçirmiyorum


Contrib'de bulunan paketlerin için demek istiyorsun sanırım.

___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] 2011 için ayrı bir depo açm a ihtiyacı

2011-01-04 Başlik Fatih Aşıcı 
On Tuesday 04 January 2011 15:24:36 Koray Löker wrote:
> Fakat depoların birleştirilmesinin tek nedeni, aralarında fark kalmaması 
> değil, farkların, iki depo bakımı yapmaya değmemesi olduğunu sanıyorum, 

Evet. Artık 3 farklı sürümümüz var. Bunlardan iki tanesi iki ayrı mimari için 
derleniyor. Ayrı bir kaynak depo açmak ikili depo sayısının (ve de farm 
sayısının) iki katına çıkması demek.


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] 2011 için ayrı bir depo açm a ihtiyacı

2011-01-04 Başlik Koray Löker 

İşbaran Akçayır wrote On 04-01-2011 15:06:
2011/1/4 Fatih Arslan >


Acaba bir "unsupported" tarzında bir depo açsak mı ? Sadece bu
uygulama değil,
bunun gibi onlarca paket vardır muhtemelen. Hem böylelikle ana
depo sağlıklı bir


Kısaca contrib demiyor muyduk buna ? :)



Tam buna demiyorduk ama bu ihtiyacı karşılayacak şey contrib'in asıl 
olması gereken şey sanırım.


Katkıcı deposu mantığı 1.0 dönemlerinde paketlerde olan standartları 
karşılayamayan, karşılayamayacak olan ama kullanıcıların tercih 
edebileceği paketler için düşünülmüştü.


O sırada her depo bileşeni/paketi Türkçe sorunları çözülmüş, görsel 
uyumluluğu olan, çakışma yaratmayan gibi kriterlerle ana depoya kabul 
ediliyordu. Zaman içinde hâl ve gidiş nedeniyle depoda birbiriyle uyumlu 
olabilme, çalışabilme neredeyse tek zorunluluk oldu... Maaşlı 
geliştirici, gönüllü geliştirici ayrımı bir dönem sanki konuşuldu ama 
hiç olmadı diye hatırlıyorum falan filan...


Neticede hâlâ bence ihtiyaç, belirli bir kalite ve kriterde olmayan 
paketleri de sunmamız, ama onları diğerleri kadar 
sahiplenmeyebileceğimizi açık açık göstermemiz denebilir. Onun adı da 
contrib değil unsupported gibi olabilir belki...


Fakat depoların birleştirilmesinin tek nedeni, aralarında fark kalmaması 
değil, farkların, iki depo bakımı yapmaya değmemesi olduğunu sanıyorum, 
yanılıyorsam düzeltin. Dolayısıyla iki depo bakımı yapma kararı almak bu 
sürecin ilk adımı olmalı sanki...


--
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] 2011 için ayrı bir depo açma i htiyacı

2011-01-04 Başlik Fatih Aşıcı 
On Tuesday 04 January 2011 15:01:51 Fatih Arslan wrote:
> Merhaba,
> 
> Şu an review sürecinde olan Xchat uygulamasının Türkçe çevirisi mevcut
> değil. Önceden Contrib'de olduğu için pek bir şey söylenmiyordu. Fakat
> 2011 deposuna gireceği için nasıl davranmamız gerektiğini belirlememiz
> gerekiyor.
> 
> 1232 küsür metin çevirilmemiş bu paketin, yarın bir gün bununla ilgili bir
> hata kaydı açıldığında, hepsini çeviremeyeceğim şimdiden belli. Paketten
> mahrum kalmalarını istemiyorum, ama diğer yandan elimizden geldiğince
> Türkçe olması yönünde bir hedefimiz var (ben de onların İngilizce bir
> XChat ile
> karşılaşmalarını istemiyoru şahsen)
> 
> Acaba bir "unsupported" tarzında bir depo açsak mı ? Sadece bu uygulama
> değil, bunun gibi onlarca paket vardır muhtemelen. Hem böylelikle ana depo
> sağlıklı bir şekilde işler. Ayrıca bu depoya Dropbox gibi uygulamalar da
> koyabiliriz (lisansın el verdiği sürede), ya da mesela Chromium-dev gibi
> Chromium'un devel kanalını kullanan bir paket olabilir. Bunlar sadec birer
> örnek,
> genişletilebilinir de.
> 
> Bu konudaki fikri olan ?

Ayrı bir depo açmak kolay bir iş değil. Bu yüzden açmayalım derim.

Uygulamanın Türkçe çevirisinin olmaması bir hatadır. Hata açılması da 
normaldir; ancak bu hata sana atanmak zorunda değil. Sen çevirmek zorunda da 
değilsin.

Çeviri eksikliğini bir hata olarak kabul ederek devam ediyorum. Bir paketi 
depoya almak için uygulamanın hiçbir hatasının olmamasını şart koşsaydık 
herhalde depodaki paketlerin tamamına yakınını atardık :) Dolayısıyla xchat'in 
depoya alınmasında bence bir sorun yok.


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] 2011 için ayrı bir depo açm a ihtiyacı

2011-01-04 Başlik İşbaran Akçayır 
2011/1/4 Fatih Arslan 

> Merhaba,
>
> Şu an review sürecinde olan Xchat uygulamasının Türkçe çevirisi mevcut
> değil.
> Önceden Contrib'de olduğu için pek bir şey söylenmiyordu. Fakat 2011
> deposuna
> gireceği için nasıl davranmamız gerektiğini belirlememiz gerekiyor.
>
> 1232 küsür metin çevirilmemiş bu paketin, yarın bir gün bununla ilgili bir
> hata
> kaydı açıldığında, hepsini çeviremeyeceğim şimdiden belli. Paketten mahrum
> kalmalarını istemiyorum, ama diğer yandan elimizden geldiğince Türkçe
> olması
> yönünde bir hedefimiz var (ben de onların İngilizce bir XChat ile
> karşılaşmalarını istemiyoru şahsen)
>
> Acaba bir "unsupported" tarzında bir depo açsak mı ? Sadece bu uygulama
> değil,
> bunun gibi onlarca paket vardır muhtemelen. Hem böylelikle ana depo
> sağlıklı bir
> şekilde işler. Ayrıca bu depoya Dropbox gibi uygulamalar da koyabiliriz
> (lisansın el verdiği sürede), ya da mesela Chromium-dev gibi Chromium'un
> devel
> kanalını kullanan bir paket olabilir. Bunlar sadec birer örnek,
> genişletilebilinir de.
>
> Bu konudaki fikri olan ?
>

Kısaca contrib demiyor muyduk buna ? :)
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik İşbaran Akçayır 
2011/1/4 Gökçen Eraslan 

> Selamlar,
>
Merhaba,


> 2011 sürümü için ciddi sorunlarımızı tartışalım, çözümler bulalım.
>
> 2- 2009'da olan paketlerin, 2011 depolarına alınması gerekiyor acilen. Hem
> 2009-2011 geçişi için hem de kullanıcıların 2009'da kullandıkları
> programları
> 2011'de de sağlamamız gerektiği için aciliyet söz konusu.
>
>
2009->2011 geçişinde review zorunluluğunu kaldırsak fena olmaz. En azından
benim bir miktar geçireceğim paket var bu yüzden geçirmiyorum

İyi günler
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

[Gelistirici] 2011 için ayrı bir depo açm a ihtiyacı

2011-01-04 Başlik Fatih Arslan 
Merhaba,

Şu an review sürecinde olan Xchat uygulamasının Türkçe çevirisi mevcut değil.
Önceden Contrib'de olduğu için pek bir şey söylenmiyordu. Fakat 2011 deposuna
gireceği için nasıl davranmamız gerektiğini belirlememiz gerekiyor.

1232 küsür metin çevirilmemiş bu paketin, yarın bir gün bununla ilgili bir hata
kaydı açıldığında, hepsini çeviremeyeceğim şimdiden belli. Paketten mahrum
kalmalarını istemiyorum, ama diğer yandan elimizden geldiğince Türkçe olması
yönünde bir hedefimiz var (ben de onların İngilizce bir XChat ile
karşılaşmalarını istemiyoru şahsen)

Acaba bir "unsupported" tarzında bir depo açsak mı ? Sadece bu uygulama değil,
bunun gibi onlarca paket vardır muhtemelen. Hem böylelikle ana depo sağlıklı bir
şekilde işler. Ayrıca bu depoya Dropbox gibi uygulamalar da koyabiliriz
(lisansın el verdiği sürede), ya da mesela Chromium-dev gibi Chromium'un devel
kanalını kullanan bir paket olabilir. Bunlar sadec birer örnek,
genişletilebilinir de.

Bu konudaki fikri olan ?

-- 
Fatih Arslan
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

[Gelistirici] Ciddi sorunlar, sesli düşün celer

2011-01-04 Başlik Gökçen Eraslan 
Selamlar,

2011 sürümü için ciddi sorunlarımızı tartışalım, çözümler bulalım.

0- Skype paketi sadece 32 bit dağıtıldığı için (Ubuntu için hazırlanmış 64 bit 
de aslında 32bit), 64bit depoya, Skype'ın bağımlılığı olan 32bit 
paketleri(alsa-lib vs) de almamız gerekiyor ve bunların 64bit olanlarıyla 
çakışmadan, mutlu mesut yaşayabiliyor olmaları lazım. Wine için de benzer bir 
durum var, 64bit Pardus'ta, 32bit Windows uygulamalarını wine'da 
çalıştırabilmek için yine, wine ve bağımlılıklarının da 64bit depoya alınması 
gerekiyor. İstersek şu anda *sadece 32bit depoya* wine ve skype'ı alabiliriz 
ExcludeArch sağolsun, fakat bu çözüm olmaz. Workaround bile olmaz.

1- Pisi delta desteğini açmamız gerekiyor, hem delta'yı test etmeye devam 
ederiz, yeni pisi ile ilgili bir sorun olmadığından emin oluruz hem de bonus 
olarak insanlara daha küçük boyutlu güncellemeler gider. Bunun için Fatih'in 
sanırım pisi'de yapacağı şeyler var.

2- 2009'da olan paketlerin, 2011 depolarına alınması gerekiyor acilen. Hem 
2009-2011 geçişi için hem de kullanıcıların 2009'da kullandıkları programları 
2011'de de sağlamamız gerektiği için aciliyet söz konusu.

3- OpenOffice/LibreOffice extension'larıyla (zemberek ve OO paketinden 
gelenler) ciddi bir sorunumuz var. OpenOffice-LibreOffice geçişinde, önce OO 
silinip LO geliyor, ardından da aynı işlem eklentiler için yapılmaya 
çalışılıyor fakat bu işlem için gereken unopkg programı artık yeni LO'dan 
geldiği için eklentiler kaldırılamıyor/kurulamıyor. Benim daha önce eklenti 
betiklerine sorunların gözden kaçmaması için eklediğim strict kontroller 
yüzünden direk exception alınıyor. Bunun en kötü tarafı ise, ne kadar 
güncelleme gelirse gelsin kullanıcıların makinesindeki preremove'lar çalıştığı 
için, bunun şu anda pratik bir çözümünün olmaması. Bunu da acilen çözmemiz 
gerek. Aynı sorun, Kurumsal2'de de mevcut bu arada.

4- Paket sahipliklerini 2009/2011 (ve Kurumsal2) için senkronlamamız 
gerekiyor, şu an 2009 en güncel, 2011/Kurumsal2 eski durumdalar genel olarak. 
(Serdar sen bir betik yazacaktın sanırım bununla ilgili, hemen bitirirsen, 
güzel olur.)

5- Pae kernel hazırlayacak mıyız? Her ne kadar 64 bit sürümümüz olsa da, 64bit 
desteği olmayan ama >= 4G ram kullanan kullanıcıların daha mutlu olması için 
güzel olur.

6- zorg komutunun akıbeti ve konsoldan sürücü değiştirmeyi tartışmamız 
gerekiyor. Fatih sanırım zorg komutunu kaldırmayı planlıyor, bana sorarsanız 
da daha önceden kullanıcılara sunduğumuz nimetler olarak bakarsak, vazgeçmek 
için sıkı nedenlerimiz olmalı. Fatih?

7- Öntanımlı uygulamalara karar verelim. Bunun için ayrı thread açacağım, bu 
thread zaten yeterince dallanacak diye tahmin ediyorum. 

8- 2009-2011 geçişi için testler yapmalı, upgrade-manager uygulaması 
yazmalı(Gökmen bunun için gönüllü) ve geçişi tamamlamalıyız. Bu sanırım her 
sürümde olduğu gibi yine 2011'in çıkışına yetişmeyecek ama sonrasında hızla 
yapabiliriz diye ümit ediyorum. Bununla ilgili Metin de playground'unda bizim 
NM'den Gnome Nm'ye profillerin dönüştürülmesi için bir betik yazıyor, bu 
sayede 2009'da geçiş sonrası network profilleri de korunmuş olacak.

9- KDE-NetworkManager: Şu anda bazı sıkıntılar var KNM ile ilgili, en büyüğü, 
ssistem geneli profil eklemiyor/düzenleyemiyor olmamız. Bunun üzerinde 
uğraşıyorum, umarım yakın zamanda yetiştireceğim.

10- Sürüm notlarını, Farslan'ın depoya aldığı publican ile ürettirmek 
istiyorum. docbook formatında yazdığımızda hem çevrilmesi kolay olacak hem de 
publican sayesinde süslü HTML'ler ürettirebileceğiz.


Şimdilik bu kadar. Fikirleriniz?


-- 
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

Re: [Gelistirici] mono-zeroconf

2011-01-04 Başlik Ozan Çağlayan 
Salı 04 Ocak 2011 günü (saat 11:38:16) Mete Bilgin şunları yazmıştı:
> Merhaba,
> 
> ${SUBJECT} paketinde System.DllNotFoundException: libnss_mdns-0.2.so hatası 
> alıyorum. depolarımızda mDNSResponder paketi olmadığı için şimdilik o 
> özelliğini kapatsak mümkün müdür? Birde avahi-mono binding girdikten sonra 
> yeniden derlemeye gerek olur mu acep?

pisi info nss-mdns  -F
/etc/mdns.allow
/usr/lib/libnss_mdns.so.2
/usr/lib/libnss_mdns4.so.2
/usr/lib/libnss_mdns4_minimal.so.2
/usr/lib/libnss_mdns6.so.2
/usr/lib/libnss_mdns6_minimal.so.2
/usr/lib/libnss_mdns_minimal.so.2
/usr/share/doc/nss-mdns/README


---
Ozan Çağlayan
TUBITAK/UEKAE - Pardus Linux
http://www.pardus.org.tr/eng
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici

Re: [Gelistirici] MySQL 5.5

2011-01-04 Başlik H. İbrahim Güngör 
On Mon, 3 Jan 2011 12:30:20 +0200
"H. İbrahim Güngör"  wrote:

> Selamlar,
> 
> MySQL yeni major sürüm çıkardı (5.5.8), changelog'a göre okuma/yazma
> işlemlerinde %360, sadece okuma işlemlerinde ise %200 performans artışı
> varmış[0]. İnşa sistemi olarak CMake kullanmaya başlamışlar.
> 
> Pakette önemli bir değişiklik yaptım; thread-safe olan libmysqlclient_r.so.*
> kitaplığını kaldırdım çünkü upstream bu kitaplığı sembolik bağlarla çözmeye
> çalışıyor ve libmysqlclient.so artık thread-safe. 
> 
> libmysqlclient_r.so -> libmysqlclient.so olacak şekilde değiştirdim. dlopen
> () çağrısı yapan uygulamalarda sorun olmamalı, linklenenleri ise
> yeniden derleteceğim.
> 
> Herşey yolunda giderse bu değişikliği Kurumsal2'de yapacağım. 2011'e de
> merge edeyim mi?
> 
> [0] http://www.oracle.com/us/corporate/press/195726

Bu değişiklik kritik olduğundan 2011 için yapmıyorum. Kurumsal'a birazdan
değişiklikleri yansıtacağım. mysql-lib paketini de yeniden adlandırıp
mysql-libs yapıyorum.

-- 
H. İbrahim Güngör 
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici