[ovirt-users] Re: Migrate machines in unknown state?
Hi, On Fri, Sep 30, 2016 at 9:27 PM, Yaniv Kaul wrote: > > > btw, b > > oth of the environments were RHEV-H based RHEV 3.5 clusters, and both > we were busy systems, so restarting vdsm service took quite a long time. > I'm guessing this might be a factor. > > That indeed might be the factor - but vdsm should not take long to > restart. If it happens on a more recent version, I'd be happy to know about > it, as we've done work on ensuring that it restarts and answers quickly to > the engine (as far as I remember, even before it fully completed the > restart). > Y. > Since the last message we've updated the environments to an up-to-date 3.6.x actually, but I'm not sure if restarting vdsmd is stiil taking a long time. I'll check back and let you know. Thanks & Regards, -- *Ekin Meroğlu** Red Hat Certified Architect* linuxera Özgür Yazılım Çözüm ve Hizmetleri *T* +90 (850) 22 LINUX | *GSM* +90 (532) 137 77 04 www.linuxera.com | bi...@linuxera.com -- IMPORTANT! This message has been scanned for viruses and phishing links. However, it is your responsibility to evaluate the links and attachments you choose to click. If you are uncertain, we always try to help. Greetings helpd...@actnet.se -- IMPORTANT! This message has been scanned for viruses and phishing links. However, it is your responsibility to evaluate the links and attachments you choose to click. If you are uncertain, we always try to help. Greetings helpd...@actnet.se ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/IHC72XEZODF6L6K5WVXAB3MSMFRKQVZ7/
Re: [ovirt-users] I wrote an oVirt thing
Hi, On Tue, Nov 29, 2016 at 1:01 AM, Oved Ourfali <oourf...@redhat.com> wrote: > BTW, the ovirt-shell is something we deprecated. It is working on top of > the v3 api, which we plan to remove in 4.2. > So better not use it. > Is there a plan to replace the shell with something similar? I see it frequently used by our users for both scripting and one-off tasks. Regards, -- *Ekin Meroğlu** Red Hat Certified Architect* linuxera Open Source Solutions and Services *T* +90 (850) 22 LINUX | *GSM* +90 (532) 137 77 04 www.linuxera.com | bi...@linuxera.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Migrate machines in unknown state?
Hi, On Fri, Sep 30, 2016 at 9:27 PM, Yaniv Kaul <yk...@redhat.com> wrote: > > > btw, b > > oth of the environments were RHEV-H based RHEV 3.5 clusters, and both > we were busy systems, so restarting vdsm service took quite a long time. > I'm guessing this might be a factor. > > That indeed might be the factor - but vdsm should not take long to > restart. If it happens on a more recent version, I'd be happy to know about > it, as we've done work on ensuring that it restarts and answers quickly to > the engine (as far as I remember, even before it fully completed the > restart). > Y. > Since the last message we've updated the environments to an up-to-date 3.6.x actually, but I'm not sure if restarting vdsmd is stiil taking a long time. I'll check back and let you know. Thanks & Regards, -- *Ekin Meroğlu** Red Hat Certified Architect* linuxera Özgür Yazılım Çözüm ve Hizmetleri *T* +90 (850) 22 LINUX | *GSM* +90 (532) 137 77 04 www.linuxera.com | bi...@linuxera.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Migrate machines in unknown state?
Hi Yaniv, Just a reminder, can you give us a pointer? Red Hat Support just asked us to disable PM before restarting vdsm again. Thanks & Best regards, On Mon, Aug 22, 2016 at 10:57 PM, Ekin Meroğlu <ekin.mero...@linuxera.com> wrote: > Hi Yaniv, > > On Sun, Aug 7, 2016 at 9:37 PM, Ekin Meroğlu <ekin.mero...@linuxera.com> >> wrote: >> >>> Hi, >>> >>> Just a reminder, if you have power management configured, first turn >>> that off for the host - when you restart vdsmd with the power management >>> configured, engine finds it not responding and tries to fence (e.g. reboot) >>> the host. >>> >> >> That's not true - if it's a graceful restart, it should not happen. >> > > Can you explain this a little more? Is there a mechanism to prevent > fencing on this scenario? > > In two of our customers' production systems we've experienced this exact > behavior (i.e. engine fencing the host while restarting vdsm service > manually) for a number of times, and we were specifically advised by Red > Hat Support to turn off PM before restarting service. I'd like to to know > if we have a better / easier way to restart vdsm. > > btw, b > oth of the environments were RHEV-H based RHEV 3.5 clusters, and both we > were busy systems, so restarting vdsm service took quite a long time. I'm > guessing this might be a factor. > > Regards, > > >> >> > >> >>> >>> Other than that, restarting vdsmd has been safe in my experience... >>> >>> Regards, >>> >>> On Thu, Aug 4, 2016 at 6:10 PM, Nicolás <nico...@devels.es> wrote: >>> >>>> >>>> >>>> El 04/08/16 a las 15:25, Arik Hadas escribió: >>>> >>>>> >>>>> - Original Message - >>>>> >>>>>> El 2016-08-04 08:24, Arik Hadas escribió: >>>>>> >>>>>>> - Original Message - >>>>>>> >>>>>>>> >>>>>>>> El 04/08/16 a las 07:18, Arik Hadas escribió: >>>>>>>> >>>>>>>>> - Original Message - >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> We're running oVirt 4.0.1 and today I found out that one of our >>>>>>>>>> hosts >>>>>>>>>> has all its VMs in an unknown state. I actually don't know how >>>>>>>>>> (and >>>>>>>>>> when) did this happen, but I'd like to restore service possibly >>>>>>>>>> without >>>>>>>>>> turning off these machines. The host is up, the VMs are up, 'qemu' >>>>>>>>>> process exists, no errors, it's just the VMs running on it that >>>>>>>>>> have a >>>>>>>>>> '?' where status is defined. >>>>>>>>>> >>>>>>>>>> Is it safe in this case to simply modify database and set those >>>>>>>>>> VM's >>>>>>>>>> status to 'up'? I remember having to do this a time ago when we >>>>>>>>>> faced >>>>>>>>>> storage issues, it didn't break anything back then. If not, is >>>>>>>>>> there a >>>>>>>>>> "safe" way to migrate those VMs to a different host and restart >>>>>>>>>> the >>>>>>>>>> host >>>>>>>>>> that marked them as unknown? >>>>>>>>>> >>>>>>>>> Hi Nicolás, >>>>>>>>> >>>>>>>>> I assume that the host these VMs are running on is empty in the >>>>>>>>> webadmin, >>>>>>>>> right? if that is the case then you've probably hit [1]. Changing >>>>>>>>> their >>>>>>>>> status to up is not the way to go since these VMs will not be >>>>>>>>> monitored. >>>>>>>>> >>>>>>>> Hi Arik, >>>>>>>> >>>>>>>> By "empty" you mean the webadmin reports the host being running 0 >>>>>>>> VMs? >>>>>>>> If so, that's not the case, actually the VM count seems to be
Re: [ovirt-users] Migrate machines in unknown state?
Hi Yaniv, On Sun, Aug 7, 2016 at 9:37 PM, Ekin Meroğlu <ekin.mero...@linuxera.com> > wrote: > >> Hi, >> >> Just a reminder, if you have power management configured, first turn that >> off for the host - when you restart vdsmd with the power management >> configured, engine finds it not responding and tries to fence (e.g. reboot) >> the host. >> > > That's not true - if it's a graceful restart, it should not happen. > Can you explain this a little more? Is there a mechanism to prevent fencing on this scenario? In two of our customers' production systems we've experienced this exact behavior (i.e. engine fencing the host while restarting vdsm service manually) for a number of times, and we were specifically advised by Red Hat Support to turn off PM before restarting service. I'd like to to know if we have a better / easier way to restart vdsm. btw, b oth of the environments were RHEV-H based RHEV 3.5 clusters, and both we were busy systems, so restarting vdsm service took quite a long time. I'm guessing this might be a factor. Regards, > > > >> >> Other than that, restarting vdsmd has been safe in my experience... >> >> Regards, >> >> On Thu, Aug 4, 2016 at 6:10 PM, Nicolás <nico...@devels.es> wrote: >> >>> >>> >>> El 04/08/16 a las 15:25, Arik Hadas escribió: >>> >>>> >>>> - Original Message - >>>> >>>>> El 2016-08-04 08:24, Arik Hadas escribió: >>>>> >>>>>> - Original Message - >>>>>> >>>>>>> >>>>>>> El 04/08/16 a las 07:18, Arik Hadas escribió: >>>>>>> >>>>>>>> - Original Message - >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> We're running oVirt 4.0.1 and today I found out that one of our >>>>>>>>> hosts >>>>>>>>> has all its VMs in an unknown state. I actually don't know how (and >>>>>>>>> when) did this happen, but I'd like to restore service possibly >>>>>>>>> without >>>>>>>>> turning off these machines. The host is up, the VMs are up, 'qemu' >>>>>>>>> process exists, no errors, it's just the VMs running on it that >>>>>>>>> have a >>>>>>>>> '?' where status is defined. >>>>>>>>> >>>>>>>>> Is it safe in this case to simply modify database and set those >>>>>>>>> VM's >>>>>>>>> status to 'up'? I remember having to do this a time ago when we >>>>>>>>> faced >>>>>>>>> storage issues, it didn't break anything back then. If not, is >>>>>>>>> there a >>>>>>>>> "safe" way to migrate those VMs to a different host and restart the >>>>>>>>> host >>>>>>>>> that marked them as unknown? >>>>>>>>> >>>>>>>> Hi Nicolás, >>>>>>>> >>>>>>>> I assume that the host these VMs are running on is empty in the >>>>>>>> webadmin, >>>>>>>> right? if that is the case then you've probably hit [1]. Changing >>>>>>>> their >>>>>>>> status to up is not the way to go since these VMs will not be >>>>>>>> monitored. >>>>>>>> >>>>>>> Hi Arik, >>>>>>> >>>>>>> By "empty" you mean the webadmin reports the host being running 0 >>>>>>> VMs? >>>>>>> If so, that's not the case, actually the VM count seems to be correct >>>>>>> in >>>>>>> relation to "qemu-*" processes (about 32 VMs), I can even see the >>>>>>> machines in the "Virtual machines" tab of the host, it's just they >>>>>>> are >>>>>>> all marked with the '?' mark. >>>>>>> >>>>>> No, I meant the 'Host' column in the Virtual Machines tab but if you >>>>>> see >>>>>> the VMs in the "Virtual machines" sub-tab of the host then run_on_vds >>>>>> points to the right host.. >>>>>> >>>>>> The host is up in the w
Re: [ovirt-users] cloud-init and sealing of template
Hi, You can always use REST-API to attach a cloud-init payload to the the machines you create - see the API example in: http://www.ovirt.org/Features/Cloud-Init_Integration But the feature was somewhat broken in 3.5.5, recently fixed in 3.5.6: https://bugzilla.redhat.com/show_bug.cgi?id=1269534 Please see that you should use the new true tag for 3.5.6 I have no experience with it in previous versions tough... For the template sealing, I only set hostname to localhost, remove the infamous /etc/udev/rules.d/70-* files, delete HW lines form ifcfg-* files, unregister the machine from satellite etc. and poweroff. I do not use sys-unconfig (as it suggests), and did not need to run virt-sysprep - plain old sealing with deleting the necessary info seemed enough for me... Regards, -- Ekin. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Team a NIC and add to ovirtmgmt vNIC
Hi, If I understood correctly, this operation does not incur a long downtime. To setup the bond, first y ou'll need to select the relevant host, select *Network Interfaces* and click *Setup Host Networks*. At this step, you should be presented with *NIC0* (eth0?) connected to *ovirtmgmt*, and a standalone (and possibly down) *NIC1* (eth1 ? ). Just drag and drop *NIC1* unto *NIC0*, choose bond type and press *OK*. After the bond is displayed, make sure you've selected both *Verify connectivity between Host and Engine* and *Save network configuration* options, and again press *OK* . If all goes well, after the configuration you'll have a working bond with ovirtmgmt on top of it. You'll have to repeat this for all hosts you'll be configuring the new bond... All network downtime will be the total time of bringing down eth0, creating bond0 and bringing up bond0 - no more than a fraction of a minute normally. And this will only effect the guests on that particular Host, not the whole cluster. A little side note on migrating from a single nic to a bond: if you plan to add more VLAN tagged virtual networks to your new bond, keep in mind that ovirtmgmt should also be VLAN tagged - you can not mix tagged and untagged networks on a single bond. Regards, On Mon, May 18, 2015 at 5:58 PM, Christophe TREFOIS christophe.tref...@uni.lu wrote: Dear all, How I would go about in an existing setup with 1 NIC and 1 vNIC ovirtmgmt, to add a second NIC, team them up (bonding) and then assign that one to ovirtmgmt without too much downtime? Does anybody have some experience on that? Thank you for your help, — Christophe Dr Christophe Trefois, Dipl.-Ing. Technical Specialist / Post-Doc UNIVERSITÉ DU LUXEMBOURG LUXEMBOURG CENTRE FOR SYSTEMS BIOMEIDINCE Campus Belval | House of Biomedicine 7, avenue des Hauts-Fourneaux L-4362 Esch-sur-Alzette T: +352 46 66 44 6124 F: +352 46 66 44 6949 http://www.uni.lu/lcsb [image: Facebook] https://www.facebook.com/trefex [image: Twitter] https://twitter.com/Trefex [image: Google Plus] https://plus.google.com/+ChristopheTrefois/ [image: Linkedin] https://www.linkedin.com/in/trefoischristophe [image: skype] http://skype:Trefex?call This message is confidential and may contain privileged information. It is intended for the named recipient only. If you receive it in error please notify me and permanently delete the original message and any copies. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users -- *Ekin Meroğlu** Red Hat Certified Architect* linuxera Özgür Yazılım Çözüm ve Hizmetleri *T* +90 (850) 22 LINUX | *GSM* +90 (532) 137 77 04 www.linuxera.com | bi...@linuxera.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] IPA-auth: user password expired
Hi Tibor, On Wed, Nov 19, 2014 at 6:46 PM, Demeter Tibor tdeme...@itsmart.hu wrote: Hi, I have an IPA server 3.0 on centos 6.6. I successfully attached to my ovirt cluster. I can see the users on ovirt user tab, but after auth I always get this error: Cannot Login. User Password has expired. Use the following URL to change the password: (nothing) I have try out with different long passwords and different users, but it's same. Did you try accessing a regular linux client with the same account? In IPA, new user passwords are always set as expired by design - please see [1]. To test this, you can try to login a client. If it is really expired, system will ask you to provide a new password. After this, you'll be able to login RHEVM with the new password you've just set. [1] http://www.freeipa.org/page/New_Passwords_Expired Regards, -- Ekin ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] IPA-auth: user password expired
Hi, An ldappasswd command would change it without setting as expired. It will prompt twice for the account password you'll set, and the password for the directory manager once: $ ldappasswd -ZZ -D 'cn=directory manager' -W -S uid=USERNAME,cn=users,cn=accounts,dc=example,dc=org -H ldap:// ipaserver.example.org You'll need to set the username (USERNAME) domain (example.org) and server FQDN accordingly. Hope this helps, On Wed, Nov 19, 2014 at 8:38 PM, Demeter Tibor tdeme...@itsmart.hu wrote: Hi, I don't have linux client. Can I change password without this? Thanks, Tibor -- Hi Tibor, On Wed, Nov 19, 2014 at 6:46 PM, Demeter Tibor tdeme...@itsmart.hu wrote: Hi, I have an IPA server 3.0 on centos 6.6. I successfully attached to my ovirt cluster. I can see the users on ovirt user tab, but after auth I always get this error: Cannot Login. User Password has expired. Use the following URL to change the password: (nothing) I have try out with different long passwords and different users, but it's same. Did you try accessing a regular linux client with the same account? In IPA, new user passwords are always set as expired by design - please see [1]. To test this, you can try to login a client. If it is really expired, system will ask you to provide a new password. After this, you'll be able to login RHEVM with the new password you've just set. [1] http://www.freeipa.org/page/New_Passwords_Expired Regards, -- Ekin -- Ekin Meroğlu *Red Hat Certified Datacenter Specialist* *linuxera* Özgür Yazılım Çözüm ve Hizmetleri *T* +90 (850) 22 LINUX *GSM* +90 (532) 137 77 04 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Non-Operational state because management interfaces down
Hi Lior, If I'm not mistaken, on Luf's topology, there is no switch on the management bond (bond0) - just a cross or regular eth cable connecting physical interfaces on both nodes. So when one node is powered down, there is no link detected on the other node. Regards, On Mon, Nov 17, 2014 at 12:02 PM, Lior Vernia lver...@redhat.com wrote: Hi Luf, Apologies, I probably don't understand the details of your L2 toplogy; how come when you turn off one host it affects the link state of of the other one's interfaces?... Yours, Lior. On 14/11/14 11:43, Finstrle, Ludek wrote: Hi, I have 2-node ovirt cluster. Both machines has 4 interfaces. 2 interfaces in bond1 for data 2 interfaces in bond0 for management (short connected directly between servers) switch0 -\ /-\ /- switch0 node1 node2 switch1 -/ \-/ \- switch1 I setup everything as I want/expect but I hit one problem and I don't know how to fix it. The problem is when I switch off one of the machines for maintenance (node01.ovirt in this case). I get in ovirt engine this message: Host node02.ovirt moved to Non-Operational state because interfaces which are down are needed by required networks in the current cluster: 'bond0 (ovirtmgmt)'. Do you have any idea how to avoid it? I can't change physical architecture as I don't have 10Gb switch. BTW it's the same as if I want to start with only 1 node and separated data and mgmt networks: switch - host --(not connected iface for mgmt as I don't need it) Thanks, Luf NOTICE: This email and any attachments may contain confidential and proprietary information of NetSuite Inc. and is for the sole use of the intended recipient for the stated purpose. Any improper use or distribution is prohibited. If you are not the intended recipient, please notify the sender; do not review, copy or distribute; and promptly delete or destroy all transmitted information. Please note that all communications and information transmitted through this email system may be monitored and retained by NetSuite or its agents and that all incoming email is automatically scanned by a third party spam and filtering service which may result in deletion of a legitimate e-mail before it is read by the intended recipient. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users -- Ekin Meroğlu *Red Hat Certified Datacenter Specialist* *linuxera* Özgür Yazılım Çözüm ve Hizmetleri *T* +90 (850) 22 LINUX *GSM* +90 (532) 137 77 04 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Mail in spam folder ...
Hi, On Fri, Nov 14, 2014 at 4:47 PM, Gianluca Cecchi gianluca.cec...@gmail.com wrote: Hello, it happened some months ago yet. It is some days that I'm receiving many list mails automatically put by gmail filter into spam folder... I always use gmail filters for lists, so checking Never send it to spam option while creating relevant filter does the trick.. Regards, -- Ekin Meroğlu *ekin.mero...@linuxera.com ekin.mero...@linuxera.com* ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] vmware disks
Hi Matt, On Wed, Oct 23, 2013 at 5:51 PM, Matthew Booth mbo...@redhat.com wrote: The latest virt-v2v can convert a VMware OVA export. Matt That's great news, thanks for letting us know... -- Ekin Meroğlu ekin.mero...@linuxera.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] vmware disks
Hi, On Thu, Oct 17, 2013 at 2:33 PM, Richard W.M. Jones rjo...@redhat.comwrote: On Thu, Oct 17, 2013 at 10:14:11AM +0100, supo...@logicworks.pt wrote: Hi, it's possible to import a vmware disk into ovirt? It depends. If you're using an ESX server, then yes, pretty easily with virt-v2v. If you only have the images of the virtual machine but not the ESX server itself, it is possible use a dirty scenario: - first convert the virtual machine to a local libvirt / virtmanager based KVM environment. [1] includes a brief how-to.. - then use virt-v2v to import this new guest to an ovirt import domain. The most complete documentation on v2v I could find is here [2] If it's just a disk image, that's more difficult. I think the latest virt-v2v can do it. (Matt?) It can not AFAIK, but this would be a very welcome addition... [1] http://www.dna.org/2011/02/converting-from-vmware-to-linux-kvm/ [2] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/V2V_Guide/index.html -- Ekin Meroğlu ekin.mero...@linuxera.com *linuxera* OpenSource Services and Solutions www.linuxera.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Gelistirici] Pardus ve Özgürlük ?çin sunucular?nda ya?anan servis kesintisi
Merhaba, Bugün Pardus sunucularının bulunduğu sistem odasında meydana gelen bir güç kesintisi ve bu kesintiden kaynaklanan donanım arızaları nedeniyle web, svn, birincil DNS ve mail sunucularımız devre dışı kaldı. Saat 15:45 sırasında ortaya çıkan probleme Ankara'da bulunan ekibimiz müdahale etti ve 18:15'de DNS, web ve svn servisleri, 19:30'da ise mail ve liste servisleri tekrar hizmete alındı. Bu servisler dışındaki Pardus ve Özgürlük İçin sunucularında ise sadece kısa süreli bir kesinti yaşandı, güç kesintisinin giderilmesi sonrasında bu servisler sorunsuz olarak çalışmaya devam etti. Elimizde olmayan nedenlerle oluşan bu kesinti nedeniyle geliştirici ve kullanıcılarımızdan özür diler, soruna hızla müdahale eden Mete ve Akın ile destek veren Erdem, Bahadır ve Kaan'a teşekkür ederiz. -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr Pardus Kurumsal Projeler Koordinatörü - http://www.pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] Pardus ve Özgürlük Icin sunucularinda yasanan servis kesintisi
Merhaba, Bugün Pardus sunucularının bulunduğu sistem odasında meydana gelen bir güç kesintisi ve bu kesintiden kaynaklanan donanım arızaları nedeniyle web, svn, birincil DNS ve mail sunucularımız devre dışı kaldı. Saat 15:45 sırasında ortaya çıkan probleme Ankara'da bulunan ekibimiz müdahale etti ve 18:15'de DNS, web ve svn servisleri, 19:30'da ise mail ve liste servisleri tekrar hizmete alındı. Bu servisler dışındaki Pardus ve Özgürlük İçin sunucularında ise sadece kısa süreli bir kesinti yaşandı, güç kesintisinin giderilmesi sonrasında bu servisler sorunsuz olarak çalışmaya devam etti. Elimizde olmayan nedenlerle oluşan bu kesinti nedeniyle geliştirici ve kullanıcılarımızdan özür diler, soruna hızla müdahale eden Mete ve Akın ile destek veren Erdem, Bahadır ve Kaan'a teşekkür ederiz. -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr Pardus Kurumsal Projeler Koordinatörü - http://www.pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] [Duyuru] 2011.1 için bir düzeltme
Merhaba, On Wed, 2011-07-13 at 21:58 +0300, Necdet Yücel wrote: Sorun yok da isoyu yeniliyoruz panpislerim denseydi iyiydi sanki Projenin *resmi* *duyuru* listesinde, sürümün en yetkili kişisi; - varolan isoların dağıtım politikası açısından sorunlu olduğu, - 13 küsür saat sonra değiştirileceği, - iso'yu indirmiş ve kurmuş olan kullanıcıların hayatlarına mutlu mesut devam edebileceği bilgilerini içeren bir duyuru yayınlıyor. Eğer bu isoyu yeniliyoruz diye önceden haber vermek değilse, başka ne yapılabileceğini gerçekten bilemiyorum kendi adıma. -- Görüşürüz, Ekin Meroğlu e...@pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Servisler için ulimit tan?mlamak...
Merhaba, On Thu, 2011-06-16 at 09:49 +0300, Ozan Çağlayan wrote: startService'e parametre yazabiliriz ancak hangi resource limitlerini modifiye etmek istiyoruz ona göre parametreler mi yazalım yoksa .. resource=resource.RLIMIT_CORE, limits=(-1,-1), .. gibi doğrudan hangi kaynağı neye limitleyecegimizi (soft,hard) mi verelim? Bizim için şimdiye kadar file descriptor sayısı gerekti (ulimit -n) Örnek servis var mı elimizde? dovecot ve jboss... -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr Pardus Kurumsal Projeler Koordinatörü http://www.pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Servisler için ulimit tan?mlamak...
Merhaba, On Thu, 2011-06-16 at 12:26 +0300, Onur Küçük wrote: Fikri gelen ? /etc/security/limits.d iş görmüyor mu ? http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_limits.html Hayır, biz de (Erdem ve ben) ilk onu denemiştik. Oradaki değerler set edilebilecek soft ve hard maximumları ayarlıyor yanlış hatırlamıyorsam, ama yeni sunucu başlarken öntanımlı değer (1024) ile başlıyor. Eğer bu limits.d'nin değeri set etmesi gerekiyorsa da bunu yapmıyoruz, belki de bu da bir hata. Ama google araştırması bu soruna denk gelenlerin genelde servis betiği içinde ulimit -n komutu ile çözdüğünü gösteriyor. -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr Pardus Kurumsal Projeler Koordinatörü http://www.pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Servisler için ulimit tan?mlamak...
On Thu, 2011-06-16 at 14:21 +0300, Onur Küçük wrote: Bende güncel Kurumsal 2 bir sistemde çalışıyor görünüyor, siz nasıl denediniz ? # sudo -u kaplan -i ulimit -Hn 1024 Kullanıcıyla login olunca çalışıyor, sorun comar'ın servis betiği ile başlattığı servislerde. -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr Pardus Kurumsal Projeler Koordinatörü http://www.pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] [Bug 18149] New: Gecelik iso'da kurulum utmp bulunmadı hatası ile kesiliyor [20110516]
On Tue, 2011-05-17 at 10:36 +0300, Mete Alpaslan wrote: 17 Mayıs 2011 Salı (saat 00:31:27) tarihinde şunları yazmıştınız: http://bugs.pardus.org.tr/show_bug.cgi?id=18149 20110516 tarihlik gecelik iso ile kurulum yapılmaya çalışıldığında paket kurulumu tamamlanıyor, işlem %50'ye geldiğinde postinstall.py /var/run/utmp'yi bulamıyor, kurulum kesiliyor. Aynı sıkıntı Pardusman'la devel deposundan test isosu hazırlarkende oluyor baselayout paketinde bir titreme var sanki? Sonradan bakınca hatanın /var/run/utmp'yi bulamamasından değil, utmp grubunun oluşmamasından olduğunu farkettik, hatayı güncelledim ama buradan takip eden varsa yazmış olalım... -- Görüşürüz, Ekin Meroğlu e...@pardus.org.tr ... did i listen to pop music because i was miserable, or was i miserable because i listened to pop music ? - rob [nick hornby / hi fi] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] OpenSSH artık system.base dışında
On Wed, 2011-04-20 at 10:04 +0300, H. İbrahim Güngör wrote: Selamlar, Önceden konuştuğumuz gibi OpenSSH paketini system.base bileşeninden server bileşenine taşıdım (krb5, skey ve libedit desteğini de açtım). Eğer paketiniz bir şekilde SSH sunucu veya istemcisini kullanıyorsa, openssh paketine özellikle bağımlılık yazmayı unutmayın. Sevgili sürüm yöneticilerimiz isolara (minimal koleksiyonu da unutmadan) openssh paketini ekleyebilirler mi lütfen, nightly'lerde sshsiz kalmayalım ? -- Görüşürüz, Ekin Meroğlu e...@pardus.org.tr ... did i listen to pop music because i was miserable, or was i miserable because i listened to pop music ? - rob [nick hornby / hi fi] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] NVidia/Ati kullanıcılarından geri bildirim gerekiyor
Merhaba, On Tue, 2011-04-05 at 16:48 +0300, Fatih Arslan wrote: Merhaba, Bunu biraz daha farklılaştırak değiştirdim. Colibri ya da Bluedevil modülündeki gibi uyarı çıkıyor artık. Aşağıdaki resimlerde son halini görebilirsiniz: http://cekirdek.pardus.org.tr/~farslan/misc/ati_randr.png http://cekirdek.pardus.org.tr/~farslan/misc/nvidia_randr.png Eline sağlık, pek güzel olmuş. Ama son kullanıcı açısından RandR settings pek bir şey ifade etmiyor, RandR settings'in içinde bulunduğu modüldeki ayarlar oluğu analaşılmıyor. Biraz daha açıklayıcı bir şey yazmak lazım, al bu da benim denemem : Your graphic card's manufacturer provides (and recommends) a (specific) tool for these settings. You can start this tool by clicking the button on the left. [Start ATI Control Center] Parantez içindeki bölümlerden emin değilim... -- Görüşürüz, Ekin Meroğlu e...@pardus.org.tr ... did i listen to pop music because i was miserable, or was i miserable because i listened to pop music ? - rob [nick hornby / hi fi] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] OpenSSH ve kerberos destegi
Merhaba, On Tue, 22 Mar 2011 08:49:28 +0200, H. İbrahim Güngör ibra...@pardus.org.tr wrote: On Wed, 16 Mar 2011 18:24:47 -0700 Listede dile getirmedim ama konusu açıldıkça söylediğim, OpenSSH'ı server/ bileşenine alalım fikrimi yapalım bu sefer itirazı olan yoksa. Sonra da kerberos desteğini açarım. Kerberos (ve fazlası) desteği için değer, bence de yapalım. Mete, yalı'daki baseonly sisteme kurulacak paketler listesine openssh'i eklemeyi unutmayalım, özellikle sunucu ve özelleştirilmiş istemcilerimizi kurarken minimal kurulum yapıyoruz, ssh'siz kurmak en azından bir kaç ekstra işlem demek. Bir de lafı geçmişken, minimal yerine minimum/sunucu vs koleksiyon desteği işimiz vardı, onu kullansak ne güzel olur :-) -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] OpenSSH ve kerberos destegi
Şu anda Kurumsal ve 2011 pardusman dosyaları collection desteğini kullanıyor. Aslında cmdline üzerinden yali=baseonly desteğini kaldırsak da onun yerine minimal koleksiyonu zorunlu kılsak daha iyi olacak. YALI içersinde hardcoded paket listesi yazmak hiç hoşuma gitmiyor :( Buna +1 ama ben bilmem, sürümün sahibi bilir.. -- Ekin Meroğlu e...@pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] ACK Sayisi Hakkinda
On Mon, 2011-01-31 at 11:56 +0200, Necdet Yücel wrote: 31 Ocak 2011 10:55 tarihinde İşbaran Akçayır isba...@gmail.com yazdı: Şimdi bir review mesajı en fazla bir normal geliştirici ack bir de component ack alabilir mi diyoruz ? Anlaşmayalım bence böyle bir şeyde. Bugzilla'da fazladan ack'ın yasak olmasını aklım almıyor benim. +1 Adam gelmiş review etmiş (engelleyen bir kuralımız yok) hata bulmamış (ne güzel işte, hatasız paket) bence de tamamdır demiş (arihe not düşmüş)- günlerdir düşünüyorum, bunun kime ne zararı olduğunu anlayamadım hala. -- Görüşürüz, Ekin Meroğlu e...@pardus.org.tr ... did i listen to pop music because i was miserable, or was i miserable because i listened to pop music ? - rob [nick hornby / hi fi] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] ACK Sayisi Hakkinda
Merhaba, On Mon, 2011-01-31 at 01:01 +0200, Anıl Özbek wrote: Bu tartışmaya Kullanıcı dizinleri başlıkla tartışmaya devam etmeme nedenlerime benzer sebeplerle devam etmeyeceğim. Anlayışla karşılayacağınızı umarım. Anlayışla karşılayalım karşılamasına da, mail thread'ini tamamen kişisel bir rahatsızlığınızı konu ederek siz başlattınız, anlayabildiğim kadarıyla da konunun kişisel tercihleri de içeren bir çekişme haline gelmesinden rahatsız olarak da sonlandırmayı tercih ediyorsunuz. Gerçekten merak ediyorum, benim ACK verdiğim pakete benden sonra ACK verilmesini bana güvenilmediği şeklinde yorumlarım anafikriyle başlayan bir tartışmanın kişselleşmeyeceğini mi umuyordunuz ? En açık haliyle yazayım, bence alınganlık ediyorsunuz. Bir de işin paketi review bekleyen geliştirici yönü var atladığınız : benim paketime tamamen farklı alanlarda uzman iki kişi ACK verse, mutlu olurum, farklı gözler de incelemiş ve hata bulamamış diye. Bileşen sorumlusu da birden fazla göz incelemiş der, içi daha rahat eder. Bunları engelleyecek bir kural koymak yerine sizi o ikinci ACK'ın size dair bir yorum yapmadığına inandırmak her açıdan daha karlı bence. Bunca yıldır bu listeye üye bir geliştirici olarak şunu söyleyebilirim en azından: hiç bir geliştirici (gerçekten review yapmak istemese) sırf bu adamın review'larına güven olmaz diye liste tutmaya zaman ayırmaz, o adamların ACK verdiği paketleri tekrar tekrar incelemeye uğraşmaz. Mailin sonunda tamamen alakasız bir konuya atıfta bulunuyorsunuz, onun da ne gereği vardı, pek bilemedim. -- Görüşürüz, Ekin Meroğlu e...@pardus.org.tr ... did i listen to pop music because i was miserable, or was i miserable because i listened to pop music ? - rob [nick hornby / hi fi] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Yeni Bileşen İhtiyacı
Merhaba, On Thu, 2011-01-13 at 14:36 +0200, Erdem Bayer wrote: Bu bileşeni açarken fark ettim, ağ izleme yazılımları için network.monitor adında bir bileşen var. Açacağım bileşeni de server.monitoring yerine server.monitor olarak mı açsam, ne dersiniz? Bence tutarlı olmaları açısından server.monitor daha iyi.. -- Ekin Meroğlu e...@pardus.org.tr Pardus ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Kurumsal2 Depo Politikası (was Re: MySQL 5.5)
Merhaba, On Thu, 2011-01-13 at 23:06 +0200, Erdem Bayer wrote: Prş, 2011-01-13 tarihinde 23:00 +0200 saatinde, H. İbrahim Güngör yazdı: Şist, kavga etmeyin bakiim :-P Şaka bir yana, tartışmanın seyrinden asıl önemli konular geride kaldı, ben araya gireyim : * Mysql örneğinde sorun başka yerden çıkmış olsa bile, bu tip bir dağıtım için bu güncelleme en hafifi tabirle bold bir adım oldu. Diyeceksiniz ki zamanında geçmeliydik, evet, geç kalmışız, gerektiği zaman zorla geçtik - bir daha ki bold hamlemizde aklımızda olsun. Test edilmesi için gerekli süreçleri yaratmadan, önlemleri almadan ne kadar evet dersek diyelim bu tip bir güncellemeyi depoya almayalım. * Kurumsal 2 RC seviyesinde ve birçok yerde kullanılıyor - artık çok çok büyük bir getirisi yoksa sürüm güncellemesi yapmamamız gerekiyor. Tüm güncellemelerde çok daha seçici davranmamız, çok daha fazla test yapmamız gerekiyor. * Bence de kararlı ve devel/test depo politikasını bir an önce karara bağlayıp, test ve devel depolarını açmamız lazım artık. Şu ana kadar açmamızın sebepleri belliydi, ama sürüme bu kadar az kalmışken zamanı geldi sanki. -- Ekin Meroğlu e...@pardus.org.tr Pardus ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Kullanıcı dizinleri
Merhaba, On Wed, 2011-01-12 at 10:35 +0200, Koray Löker wrote: 12 Ocak 2011 Çarşamba günü (saat 10:26:27) Fatih Aşıcı şunları yazmıştı: Selamlar, Videolarım, Resimlerim, vs dizinlerinin doğrudan ev dizininde olup olmaması konusunda ne düşünüyorsunuz? Bu konuda açılmış bir hata var[1]. Şu anki hali bana kullanışlı gelmişti. Değiştirilecekse sürümden önce değiştirmemiz gerekiyor. Mantıklı aslında... Eskiden daha belge odaklı olunduğu için ilk alışkanlık buydu ama, ben sidebar'da ayrı ayrı olduklarında çok daha rahat kullanıyorum, dolayısıyla hepsine daha doğrudan erişimin de kullanışlı olacağını tahmin ediyorum. Bence de alışkanlıktan gelen documents altına bir seviye daha inme mantığını çok anlamlı değil - kullanıcı en çok kullandığı iki üç dizine en hızlı şekilde ulaşsın, Documents gerçekten (işle ilgili ?) belgelere kalsın. Ekin. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Kurumsal2'de MySQL hatası
Merhaba, On Tue, 2011-01-11 at 22:32 +0200, Gökmen Görgen wrote: İşin kötü tarafı, hata çıktısını almayı unuttum. Eğer Kurumsal2 yüklü bir sisteminiz varsa, güncel mysql'i kurup revdep-rebuild çıktısını kontrol eder misiniz? Herhangi bir ilgili çıktı alabiliyor musunuz? söz konusu sistemde $ cat /etc/ld.so.conf çıktısı nedir ? /etc/ld.so.conf.d/ geçişi ile ilgili bir sorun var, geçen gün tekrarladık ama sorun tam çözülmedi. Bir de pisi hs ile bakıp sistemin geçmişindeki baselayout güncellemelerini gönderir misin ? Ekin. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] /etc/mime.types
Merhaba, On Mon, 2011-01-10 at 16:22 +0200, Onur Küçük wrote: Bu arada mailcap dosyasında statik dosya isimleri yazıyor, Fedora onun yerine xdg-open kullanmış. Bunu zamanında Fatih de önermişti, Gökçen de bu [1] yanıtı vermişti - benzer bir bug'da [2] sorunun büyük oranda çözüldüğü konuşulmuş, burada [3] da kde4.3 ile çözüldü denmiş ama herkes tamamen güvenli diyemiyor sanki - ilk hata da hala açık. [1] http://lists.pardus.org.tr/gelistirici/2009-May/018666.html ve hatta http://lists.pardus.org.tr/gelistirici/2009-May/018665.html [2] https://bugs.freedesktop.org//show_bug.cgi?id=19377 [3] https://bugzilla.redhat.com/show_bug.cgi?id=479010 ekin. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] corporate2/devel/system/base/baselayout/comar - Update shell and home attributes of user tomcat
Merhaba, On Fri, 2011-01-07 at 16:53 +0200, Gökhan Özbulak wrote: -(132, tomcat, Tomcat, /var/lib/tomcat, /bin/false, , [tomcat], [], []), +(132, tomcat, Tomcat, /opt/tomcat, /bin/sh, , [tomcat], [], []), Shell'inin hakkaten /bin/sh olması gerekiyor mu ? ekin. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer
On Wed, 2011-01-05 at 10:36 +0200, Onur Küçük wrote: On Çarşamba 05 Ocak 2011 09:57:18 Fatih Aşıcı wrote: Yukarıda anlattığım nedenlerden dolayı zorg'un --driver parametresinin artık bir anlamı kalmıyor. Kullanıcıların böyle bir seçeneği kullanmasını istemiyorum. Çünkü bu, birçok soruna yol açabilen bir şey. Zaten kullanıcıların konsol kullanmasını istemiyoruz. Deneyimli olan kullanıcı kendisi xorg.conf yazabilir (örnek bir xorg.conf'u pakete alabilirim). Klavye ayarları da artık /etc/X11/xorg.conf.d/10-keyboard.conf dosyasından yapılabiliyor. Deneyimli bir kullanıcı bunu rahatlıkla düzenleyebilir. Statik bileşenlerden ne kadar uzaklaşırsak o kadar iyi, ama uzman kullanıcı da olsa sonuçta o bir kullanıcı :) Kullanıcıların dosya isimlerini / yerlerini / sentaksını ezbere bilmelerini beklemeyelim, Sık kullanılmayacak ama Zorg bu tarz elle müdahale etmek isteyenlerin kolayca kullanabileceği bir araç olmaya devam etsin, eski davranışı da bozmadan örnek dosyayı kopyalamak ya da bir ayar dosyasında basit bir string değişikliği de olsa yapmaya devam etsin bence. Fazla özellik / yetenek de şart değil, klavye ve ekran kartı ayarları yeterli sanki. +1 -- Görüşürüz, Ekin Meroğlu e...@pardus.org.tr ... did i listen to pop music because i was miserable, or was i miserable because i listened to pop music ? - rob [nick hornby / hi fi] ___ 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 ihtiyac?
Merhaba, Dün akşam thread'in başında cevap verecektim, zamanım olmadı, bu mailde yazdıklarımı tüm thread'e cevap olarak kabul ederseniz sevinirim. On Wed, 2011-01-05 at 18:23 +0200, Anıl Özbek wrote: Desteklenmeyen bir deponun iyi olacağını düşünüyorum. - Bana öyle geliyor. Buna diyecek bir şey yok :-) - Ana depoda üst geliştirici bakımı yapılmayan paketlerimin olmasını doğru bulmuyorum [1]. - Bana kolaylık sağlıyor. Ayrı bir ACK - NACK süreci takip etmek zorunda kalmıyorum. İki inceleme alıp hemen paketimi depoya alabiliyorum. Yaptığım değişiklikleri hemen kullanıcılara yansıtabiliyorum. - Kapalı kaynak olduğu için ana depoya almaya içimin el vermediği paketlerim için böyle bir depoyu kullanabilirim. - Tüm paketlerin ana depoda barınmasını sağlıklı bulmuyorum. Test işlemi için harcanan zaman artacaktır. Belki başka şeyler de olabilir. - İsteyen SVN hesabı olmayan paket sahiplerinin paketlerini [2] veya bakıcısız paketlerin bakımını buradan sürdürebiilir. Necdet'in de dediği gibi bu tip bir deponun camia tarafından açılması ve bakılması en mantıklı olanı. İki ya da daha fazla depoda asıl sorunlar bu iki depo arasında paket taşımaya başlayınca çıkıyor, ki bu bir süre sonra kaçınılmaz. Paket taşıma işlemlerinin en aza inmesi ve sorunsuz olması için ise deponun ve taşıma sürecinin sağlam bir politikası olması gerekiyor. Bir gün böyle bir depo olacaksa, teknik neden/kaynak vs'den çok sürdürülebilir bir depo politikasına gerek var, bu depo politikasının da sağlam koşullar içermesi lazım.. Özetle, bu pakete yer bulamadık, şu paketi hızla depoya almak iyi olacak gibi fiili nedenlerle alelacele bir depo açarsak iki yıl sonra bugünkü durumumuza geri döneceğiz bence. Pratikte işleri zorlaştırdığının farkındayım, ama sağlam bir politika olmadan depo açmak da çözüm değil. Daha fazla detay isteyen mazoşistler bu liste arşivlerinde bu paket hangi depoya gitsin, bu paket niye bu depoda gibi konulardaki sayısız tartışmaları yeniden okuyabilir :) 2 kr. ekin. ___ 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 ihtiyac?
Merhaba, On Wed, 2011-01-05 at 20:24 +0200, Fatih Arslan wrote: Test depousunu da kimseye zorla kullandırtmıyoruz, sonuçta bu depoyu kullanacak olan kişiler yine her türlü sorumluluğu kabul etmiş olacaktır. Camia ve Pardus diye neden ayrıma girildi anlamadım şimdi. Geliştirci olan herkesin buraya paket koyma hakkı olacak. Öyle tabii, sadece depoyu camia yönetecek, bakımını yapacak ve sunacak demek istendi benim anladığım. Yoksa sen de paket koyarsın, ben de... Bu deponun desteklenmeyeceği de önceden belirtilecek. Alan memnun, satan memnun... teoride öyle de, pardus.org.tr'den sunduğumuz bir depodaki pakete destek vermediğimiz zaman -çok haksız da olmayan- itirazlar oluyor. Depoyu proje olarak sunmamız o deponun tüm sorumluluğunu almak anlamına geliyor çoğu durumda. ekin. ___ 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 ihtiyac?
On Tue, 2011-01-04 at 15:01 +0200, Fatih Arslan wrote: Merhaba, 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) Bu çekincelerinde ve isteklerinde son derece haklısın, ama tek bir kıstas ile (burada uygulamanın yerelleştirmesinin eksik olması) farklı depo açmak yerine daha geniş bir gerekler listesini karşılayan, kuralları olan depo(lar) kullanmalıyız. Bu tanıma pardus deposu da giriyor, o deponun yazılmamış kuralları bile yazılı kurallarından fazla :-) Bence şu anda yapabileceğin en iyi şey, paket review'den geçerse depoya alıp, bugzillada (hem de upstreamde belki) yerelleştirmesi eksik diye bir hata açmak olacaktır - belki birisi sahiplenir, turkçeleştirir arada, biz de kaydını tutmuş oluruz. Tabii bir de varsa yazılımı türkçeleştirebilecek farklı kullanıcı gruplarından yardım istemek güzel olur - özgürlükiçin'den mesela. 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. Sorun genişleyebileceğini daha şimdiden biliyor olmamız zaten :-) Sonuna kadar genişletip üzerinde uzlaştığımız bir kural seti haline getirmeden depo açmayalım bence. Geçmişte yaptık, geri döndük, bir daha ki adımımızı sağlam atalım. ekin. ___ 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 ihtiyac?
Merhaba, On Wed, 2011-01-05 at 22:33 +0200, Ekin Meroğlu wrote: Necdet'in de dediği gibi bu tip bir deponun camia tarafından açılması ve bakılması en mantıklı olanı. Bu arada ufak bir açıklama, bu ikinci - üçüncü - eninci depo kim tarafından sunulursa sunulsun, olmazsa olmazı geniş, düzgün ve *yazılı* bir depo politikası / kural seti bence. Bu politika ortaya koyulmadan depoyu açan ve işleten kim olursa olsun aynı itirazı yapacağım, sonunda da aynı sorunları yaşayacağımızı düşünüyorum. Yanlış anlaşılmasın, herkes çıkıp depo burada, as-is veya şu kadar destekle sunuyorum der, açar, işletir - hiç bir şekilde benden (veya başkasından) izin/icazet vs almak durumda değil. Ama bu işin bir camia içinde doğru bir şekilde uzlaşı ile yapılması gerektiğini, bizim de tam olarak buna ihtiyacımız olduğunu düşünüyorum. ekin. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Ciddi sorunlar, sesli düşün celer
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çeneklerin her durumda kalmasından yanayım. ekin. ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Hata 9638 - server/web/nginx hakkında
Merhaba,
On Tue, 2010-12-28 at 14:04 +0200, Fatih Aşıcı wrote:
meta-paket gibi ayrı bir paket türüne ihtiyaç yok. Tek bir dosyadan ibaret
bir
paket yapılabilir. Bu yöntem ile her pakete AnyDependency yazmak arasında
kullanıcı deneyimi açısından bakıldığında bir fark olmaması lazım.
AnyDependency'ler tek bir pakete yazılacağı için tercihim bu yönde olacaktır.
Pisi'nin desteklediği bir özellik de olsa, tek dosyadan oluşan normal
bir paket de olsa, meta-paket'ten kaçınmamıza neden olan şöyle bir
senaryoydu sanırım :
Metapaket kullandığımızda örnek bağımlılık böyle olacak :
mod_php -- webserver (meta) -- {apache|nginx} (anydep)
burada mod_php herhangi bir nedenle apache'nin özel bir sürümüne bağımlı
hale gelirse ne yapacağız ? Yöntem apache'yi sürüm arttırmak, webserver
metapaketine yeni apache sürümüne strict dep yazmak, mod_php'ye de bu
yeni webserver sürümüne strict dep. yazmak gibi görünüyor. Bu yöntemin
pek takip edilebilir bir yanı yok, meta paket kullanmak işleri
karmaşıklaştırıyor hatta.
Sal, 2010-12-28 tarihinde 10:55 +0200 saatinde, H. İbrahim Güngör yazdı:
Yarın başka bir
sunucu daha gelirse, tüm paketlere bir anydependency yazmak yerine
meta-webserver gibi bir pakete anydependency olarak yazalım apache'yi,
nginx'i vs., web-server bağımlılığı olan paketlere de meta-webserver
bağımlılığı yazalım.
Zaten yeni bir sunucu geldiğinde bu sunucu ile çalışabilecek tüm
bağımlı paketlere o sunucu ile birlikte çalışması için gereken config
dosyalarını eklememiz gerekiyor Erdem'in senaryosuna göre. Bu da sürüm
güncelleme, entegrasyon testi vs demek, o süreçte gerekli anydep. de
yazılacaktır pakete.
meta paket yapıp yeni sunucu geldiğinde sadece bu meta pakete anydep
eklersek, teoride o yeni sunucu ile düzgün çalıştığından emin
olmadığımız bir seri paket o yeni sunucuya bağımlı oluyor otomatik olarak.
Bence meta-paket filan boş verelim, tüm olası bağımlılıkları doğrudan
paketlere yazalım anydependency ile. Meta paketleri gerçekten
destekleyeceksek, adam gibi tasarlayıp özellik olarak eklemek lazım
bence.
2 kuruş.
--
Ekin Meroğlu e...@pardus.org.tr
Pardus
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Hata 9638 - server/web/nginx hakkında
Merhaba, On Tue, 28 Dec 2010 10:55:15 +0200, H. İbrahim Güngör ibra...@pardus.org.tr wrote: On Mon, 27 Dec 2010 17:58:38 +0200 Erdem Bayer eba...@pardus.org.tr wrote: * Web sunucusu bağımlılığı olan bütün paketler içinde apache ve nginx için anydependency yazalım. Bunun yerine meta paket tanımlayıp soyutlamaktan yanayım. Yarın başka bir sunucu daha gelirse, tüm paketlere bir anydependency yazmak yerine meta-webserver gibi bir pakete anydependency olarak yazalım apache'yi, nginx'i vs., web-server bağımlılığı olan paketlere de meta-webserver bağımlılığı yazalım. meta-paket bugüne kadar hep kaçındığımız bir çözüm oldu - daha çok bir hack olarak gördük ve kullanmamak için uğraştık. Dolayısıyla eğer kullanma kararı alacaksak, bu threadde değil, daha kapsamlı bir Pardus ve/ya PiSi hangi özellikleri destekler başlığında konuşmalıyız - ve karar almalıyız. Geçmişte sadece bir noktadaki sorunu çözmek için attığımız benzer adımlar genel birer çözümmüş gibi kabul gördü, işin içinden çıkmak giderek zorlaştı. * Apache ve nginx paketlerine birer pakhandler ekleyelim, bir paket kurulurken bu dizinler altına dosya koyuyorsa ve o web sunucunun paketi kurulu ise web sunucunun öntanımlı config dizini içinden bu config dosyasına link oluştursun. Bu over-engineering gibi geliyor bana. Kullanıcının symlink oluşturması daha temiz ve güvenli bir yol değil mi? Olabildiğince kullanıcıya birşey bırakmamalıyız - şimdiye kadar apache ve ilgili paketler kurulduğunda kullanıcı ek bir ayar yapmadan çalıştı herşey, bundan sonra da böyle olmalı. Bu teknik bir sorundan çok bir tasarım kararı - yazılımlar kendi işlerini kendileri yapsınlar :-) -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Pardus Kurumsal 2 Latest depoları
On Fri, 2010-12-24 at 12:59 +0200, Ozan Çağlayan wrote:
Merhaba,
http://packages.pardus.org.tr/pardus/corporate2/{devel,stable}/i686{-debug}/latest
http://packages.pardus.org.tr/pardus/corporate2/{devel,stable}/x86_64{-debug}/latest
altdizin depoları açılmış olup, bir üst dizindeki paketlerin her birinin
sadece *en yeni* sürümünü
içerecek şekilde düzenlenmiştir.
trunk altındaki buildfarm kodu, her çalışma sonrası bu latest altdizinlerini
güncelleyecektir.
ne diyeceğimi nasıl teşekkür edeceğimi bilemiyorum, toblerone ?
--
Görüşürüz,
Ekin Meroğlu e...@pardus.org.tr
... did i listen to pop music because i was miserable, or was i
miserable because i listened to pop music ? - rob [nick hornby / hi fi]
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Pardus Kurumsal 2 Latest depoları
On Fri, 2010-12-24 at 13:49 +0200, Ekin Meroğlu wrote:
On Fri, 2010-12-24 at 12:59 +0200, Ozan Çağlayan wrote:
Merhaba,
http://packages.pardus.org.tr/pardus/corporate2/{devel,stable}/i686{-debug}/latest
http://packages.pardus.org.tr/pardus/corporate2/{devel,stable}/x86_64{-debug}/latest
altdizin depoları açılmış olup, bir üst dizindeki paketlerin her birinin
sadece *en yeni* sürümünü
içerecek şekilde düzenlenmiştir.
trunk altındaki buildfarm kodu, her çalışma sonrası bu latest
altdizinlerini güncelleyecektir.
latest deposunda ilgili paketlere sembolik linkler var, dolayısıyla
rsync ile *sadece* latest dizini çekecek kullanıcıların -L parametresi
ile rsync'in sembolik link takip etmesini sağlamaları gerekecek..
--
Görüşürüz,
Ekin Meroğlu e...@pardus.org.tr
... did i listen to pop music because i was miserable, or was i
miserable because i listened to pop music ? - rob [nick hornby / hi fi]
___
Gelistirici mailing list
Gelistirici@pardus.org.tr
http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] /boot dizini olarak raid device md0
On Sun, 2010-12-19 at 23:58 +0200, Mete Alpaslan wrote: 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. Boot dizini raid üzerinde olamaz desek daha iyi değil mi ? Emre Erenoğlu'nun dediği gibi RAID üzerinde boot tutmanın sorun çıkarabileceği bir sürü yer var : RAID1 (mirror) kullanırsak, diskte fiziksel hata olduğunda da açılabilmesi için grub'i her iki diskin başına yazmak gerekiyor - yoksa grub'ın bulunduğu disk ölürse, diğer diskte tüm bilgiler eksiksiz olduğu halde sistem açılmıyor. Grub'ın bölüm başına kurulduğu durumda bu senaryo geçerli mi onu da bilmiyorum. RAID0 (stripe) kullanırsak grub kernel dosyalarını bulurken sorun yaşıyordu - son durumu kontrol etmek lazım ama ufak bir 'google it' hala aynı sorunu yaşayan kullanıcılar ile /boot'u raid yapmayın diyen geliştiricilerin konuşmalarını getiriyor. Daha ileri RAID konfları ise zaten bir başka alem... Özetle /boot'un raid volume olmasını desteklemeyelim derim ben - sorunlu olacağına hiç olmasın. -- Görüşürüz, Ekin Meroğlu e...@pardus.org.tr ... did i listen to pop music because i was miserable, or was i miserable because i listened to pop music ? - rob [nick hornby / hi fi] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] corporate2/devel/system/base/rsyslog - Enable mysql, pgsql, gssapi and gnutls modules.
Merhaba, Eline sağlık bu hamle çok güzel oldu... +pisitools.insinto(%s/%s % (get.docDIR(), get.srcNAME()), + plugins/ommysql/createDB.sql, + createMySQLDB.pl) + +pisitools.insinto(%s/%s % (get.docDIR(), get.srcNAME()), + plugins/ompgsql/createDB.sql, + createPgSQLDB.pl) Bu dosyalar sadece sql komutlarından oluşuyor, *.sql kalması daha iyi isimlerinin.. -- Görüşürüz, Ekin Meroğlu e...@pardus.org.tr ... did i listen to pop music because i was miserable, or was i miserable because i listened to pop music?... - rob [nick hornby / hi fi] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] Python modüllerinin isimlendirilm esi (v4)
Merhaba, On Fri, 2010-09-03 at 17:02 +0300, Ahmet AYGÜN wrote: Bazı dağıtımlar python-django-* olarak isimlendirmişler ancak bana da çok uzun ve gereksiz bir isimlendirme gibi geliyor zira python paketlerinde olduğu gibi farklı isimlendirmeler mevcut değil sadece django-* kullanılıyor. +1, django-* neyimize yetmiyor :-) -- Görüşürüz, Ekin Meroğlu e...@pardus.org.tr ... did i listen to pop music because i was miserable, or was i miserable because i listened to pop music ? - rob [nick hornby / hi fi] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] 2009/stable/programming/language/php/PEAR-MDB2 - Merge from devel/programming/language/php/PEAR-MDB...
Merhaba, On Sun, 2010-08-29 at 17:49 +0300, Gökmen Görgen wrote: 5 adet görüş var, çoğunluğumuz PEAR paketleriyle tek tek uğraşmanın gereksiz kasıntı olduğunun kanaatinde. İtiraz eden de çıkmadı. Ama siz bir karar almış görünüyorsunuz =) En azından 2011 için konuyu tekrar gündeme getirelim derim. Pear paketleri özelinde sorunun ne olduğunu incelemedim ama dağıtım ve deponun kendi içinde tutarlı olması için genel mantığımız yazılımların kendi güncelleme mekanizmalarına güvenmemek değil mi ? Paketçi yeni sürümün deponun geneli ile uyumlu, sorunsuz ve entegre olduğuna ikna olduğunda ilgili paketi güncelleyerek depoya almalı. Tüm yazılımları depo halinde sunmamızın sebebi bu, yoksa binary Firefox'u kuracak bir script yazar, kendi güncelleme yönetcisi de ne güzel çalışıyor, kullanıcı güncellesin paşa paşa der geçerdik, başımız da daha az ağrırdı sanki.. Kısaca, depodan sunduğumuz bir paket/altyapı/framework vs.nin güncelleme sisteminin bizim kontrolumuz dışında olması bence yanlış. kaldı ki bu yöntem depodaki strict dependency'ler açısından yönetilemez bir durum ortaya çıkarıyor... -- Ekin Meroğlu e...@pardus.org.tr Pardus ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] Pardus 2008 Güncellemeleri Sona E riyor - Pardus 2008 Ya?am Sonu
Pardus 2008 güncellemeleri sona eriyor. Kararlı sürümü 27 Haziran 2008 tarihinde yayınlanan ve 15 Eylül 2008'de 2008.1 Hyaena hyaena, 31 Ocak 2009'da ise 2008.2 Canis aureus ara sürümleri ile kullanıcılarıyla buluşan Pardus 2008, güncellemelerini sona erdiriyor. Yayınlanmasının üzerinden geçen 2 yıllık süre içinde, 2009.1 Anthropoides virgo'nun yayınlanması ile sadece güvenlik güncellemelerini sunmaya başlayan Pardus 2008, Pardus 2009.2 Geronticus eremita sürümünün ardından tüm güncellemeleri durduruyor. Bugünden sonra Pardus 2008 depolarına herhangi bir güncelleme girmeyecek, Pardus 2008 için açılan hatalar çözülmeyecek - sunucularımızda Pardus 2008 / Contrib kararlı depolarının son hallerini sunmaya devam edeceğiz, fakat Pardus 2008 / Contrib derleme çiftliği ve test deposunu kapatarak 2008 kaynak paket deposunu donduracağız. Halen Pardus 2008 kullanmakta olan kullanıcılarımızın ise Pardus sistemlerini güvenli ve kararlı bir şekilde kullanmaya devam etmek için dağıtımlarını güncel Pardus 2009 seviyesine yükseltmelerini öneririz. [**] Pardus 2008 bakım ekibi olarak Pardus 2008 sürecine emeği geçen tüm geliştiricilerimize bir kez daha teşekkür ediyoruz - Pardus 2008 tüm geliştiricilerimizin özverili çabaları sayesinde bu kadar başarılı oldu. Her zamanki gibi, iyi ki varsınız :-) -- [**] : upgrade-manager (Dağıtım güncelleme yöneticisi) ile Pardus 2008 - Pardus 2009 geçiş yapmak için aşağıdaki adımları izlemeniz yeterli olacaktır : 1- Paket Yöneticisi'ndeki tüm güncellemeleri yapın. 2- Güncellemeler bittikten sonra, upgrade-manager (Dağıtım güncelleme yöneticisi) isimli paketi kurun. 3- Paket Yöenticisi'nin kapalı olduğundan ve sistem çekmecesinde dahi çalışmadığından emin olun. 4- KDE menüsünde, Programlar - Sistem - Sürüm Yükseltme Aracı (Pardus 2009 Dağıtım Güncellemesi) yolunu takip ederek dağıtım güncellemesini başlatın. 5- Kullandığınız bilgisayarın internete bağlı olduğundan emin olun ve Yükseltmeye Başla düğmesine tıklayarak güncellemeyi başlatın. Güncelleme esnasında sizden bazı paketlerin kaldırılması gerektiğiyle ilgili onay ya da bazı yetki gerektiren işlemler için parola istenebilir. 6- Güncelleme sırasından başka bir işlem yapmamanız ve güncellemeyi kesinlikle kesmemeniz gerekmektedir. 7- Güncelleme bittikten sonra bilgisayarınızın yeniden başlatılması istenecektir, kesinlikle onay vermeniz önerilir. Aksi takdirde kararsız bir sistemle karşı karşıya kalabilirsiniz. -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] tags/2008-EOL - 2008 is dead baby, stone-cold-dead...
Merhaba, On Tue, 2010-08-10 at 15:57 +0300, Ekin Meroğlu wrote: Author: eki Date: Tue Aug 10 15:57:07 2010 New Revision: 96789 Added: tags/2008-EOL/ - copied from r96784, 2008/stable/ Log: 2008 is dead baby, stone-cold-dead... Ve bir sürüm daha tarih olur - hepimizin eline sağlık, çok eğlenceliydi :-P -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Pardus-kullanicilari] Pardus 2008 Güncellemeler i Sona Eriyor - Pardus 2008 Ya?am Sonu
Pardus 2008 güncellemeleri sona eriyor. Kararlı sürümü 27 Haziran 2008 tarihinde yayınlanan ve 15 Eylül 2008'de 2008.1 Hyaena hyaena, 31 Ocak 2009'da ise 2008.2 Canis aureus ara sürümleri ile kullanıcılarıyla buluşan Pardus 2008, güncellemelerini sona erdiriyor. Yayınlanmasının üzerinden geçen 2 yıllık süre içinde, 2009.1 Anthropoides virgo'nun yayınlanması ile sadece güvenlik güncellemelerini sunmaya başlayan Pardus 2008, Pardus 2009.2 Geronticus eremita sürümünün ardından tüm güncellemeleri durduruyor. Bugünden sonra Pardus 2008 depolarına herhangi bir güncelleme girmeyecek, Pardus 2008 için açılan hatalar çözülmeyecek - sunucularımızda Pardus 2008 / Contrib kararlı depolarının son hallerini sunmaya devam edeceğiz, fakat Pardus 2008 / Contrib derleme çiftliği ve test deposunu kapatarak 2008 kaynak paket deposunu donduracağız. Halen Pardus 2008 kullanmakta olan kullanıcılarımızın ise Pardus sistemlerini güvenli ve kararlı bir şekilde kullanmaya devam etmek için dağıtımlarını güncel Pardus 2009 seviyesine yükseltmelerini öneririz. [**] Pardus 2008 bakım ekibi olarak Pardus 2008 sürecine emeği geçen tüm geliştiricilerimize bir kez daha teşekkür ediyoruz - Pardus 2008 tüm geliştiricilerimizin özverili çabaları sayesinde bu kadar başarılı oldu. Her zamanki gibi, iyi ki varsınız :-) -- [**] : upgrade-manager (Dağıtım güncelleme yöneticisi) ile Pardus 2008 - Pardus 2009 geçiş yapmak için aşağıdaki adımları izlemeniz yeterli olacaktır : 1- Paket Yöneticisi'ndeki tüm güncellemeleri yapın. 2- Güncellemeler bittikten sonra, upgrade-manager (Dağıtım güncelleme yöneticisi) isimli paketi kurun. 3- Paket Yöenticisi'nin kapalı olduğundan ve sistem çekmecesinde dahi çalışmadığından emin olun. 4- KDE menüsünde, Programlar - Sistem - Sürüm Yükseltme Aracı (Pardus 2009 Dağıtım Güncellemesi) yolunu takip ederek dağıtım güncellemesini başlatın. 5- Kullandığınız bilgisayarın internete bağlı olduğundan emin olun ve Yükseltmeye Başla düğmesine tıklayarak güncellemeyi başlatın. Güncelleme esnasında sizden bazı paketlerin kaldırılması gerektiğiyle ilgili onay ya da bazı yetki gerektiren işlemler için parola istenebilir. 6- Güncelleme sırasından başka bir işlem yapmamanız ve güncellemeyi kesinlikle kesmemeniz gerekmektedir. 7- Güncelleme bittikten sonra bilgisayarınızın yeniden başlatılması istenecektir, kesinlikle onay vermeniz önerilir. Aksi takdirde kararsız bir sistemle karşı karşıya kalabilirsiniz. -- İyi Çalışmalar, Ekin Meroğlu e...@pardus.org.tr ___ Pardus-kullanicilari e-posta listesi Listeden çıkmak için http://liste.pardus.org.tr/mailman/listinfo/pardus-kullanicilari adresini kullanın. Listeye iletmek istediğiniz soruları Pardus-kullanicilari@pardus.org.tr e-posta adresine gönderin. Liste mesajlarında arama yapmak için http://liste.pardus.org.tr/arama web sayfasına gidin.
Re: [Gelistirici] toplantı tarih/yer tamamsa, ba şlık önerileri ?
Merhaba, Hatırladığım iki örnek olduğu için Kubilay ve Ali'nin mesajlarını alıntıladım, ama genel olarak hepimize yazıyorum... On Monday 26 July 2010 17:59:56 Kubilay KOCABALKAN wrote: Konuşulacak konular içerisinde Pardus 2011 ve Camia katkıları olmayacağına göre ben toplantıdan affımı istiyorum. Sürüm yöneticileri ile farklı bir tarihte yapılacak toplantı için ayrı bir organizasyonda görüşmek dileğiyle. On Monday 27 July 2010 23:34:40 Kubilay KOCABALKAN wrote: Kaygılarınıza katılıyorum. Bu yüzden, bende toplantıya katılmamam gerektiğini düşündüm. Şahsım adına söylüyorum, her hangi bir kırgınlığım yok. Yapılacak toplantının, projenin bundan sonraki ilerleyişi için çok önemli olduğuna inanıyor ve tüm geliştirici camiasına sevgi ve saygılarımı gönderiyorum. On Tue, 2010-07-27 at 15:41 +0300, Ali Işıngör wrote: o halde ben de fikrimi soyleyeyim. camia ile iliskilerimiz neden sorunlu, disardan katkicilarin sayisini nasil artiririz temali bir toplantida, 2011 ile yapmak istediklerini konusmak isteyen ve oradaki varolus nedeni bu olan kisilere, kusura bakmayin buna vaktimiz yetmeyebilir demek, son derece heves kirici bir yaklasim. gelmeseniz de olur, cok daha onemli meselelerimiz var konusacak demekle esanlamli bu. diger meseleler kime gore ya da neye gore daha onemli? eger elimizdeki camia ile iliskilerimiz ve toplulugun 2011 oncesinde yer almak istedigi projeler konusulmayacaksa, ben de toplantidan affimi rica edecegim. Çok yakın geçmişte bu listede oldukça büyük bir tartışma koptu, bir sürü insan bana müsaade dedi, bir bölümü kişi ismi vererek o/bu adamdan zaten cacık olmaz dedi, bir bölümü ise herkesi suçladı, projenin şimdisinden ve geleceğinden umutsuz olduğunu yazdı.. Sonuçta o oldu bu oldu, insanlar kırıldı, küstü, sinirlendi... O tartışma sonrası da hepimiz her ettiğimiz laftan korkar olduk, en ufak fikir ayrılığında kılıçlar çekilir hale geldi.. Ortada bu kadar görünür bir sorunlar silsilesi varken ve temel olarak bu sorunları konuşalım, herkesin sıkıntısını konuşalım, gelecekte aynı sorunları tekrar yaşamayalım temalı bir toplantı yapmaya çalışırken Ali ve Kubilay'ın bu toplantıda beni ilgilendiren konular yok, gelmeme de gerek yok demesini -kendi adıma- kesinlikle anlayamıyorum. Okuduğum kadarıyla bu toplantıdan sonra ayrı bir toplantıya bırakalım denen konular -teknik ağırlıklı- 2011 sürüm kararları. Acil sorunlarımız nedir, nasıl hatalar yaptık, nasıl aşarız, ilerde nasıl tekrarlamayız konuları 2011 ve diğer yeni ürünlerin nasıl ortaya çıkacağını tabii ki kapsayacaktır, ama atıyorum 2011'de KDE'de uygulama menüsü şu şekilde sadeleşsin konusu bu toplantı için fazla teknik, fazla detay - kaldı ki listede -en azından Fatih'in- konuşulmasın dediği de bu tip konular. Heves kırıcı mı bilmiyorum ama, bence de bu ilk toplantıda buna vaktimiz yok. Listede son derece teknik sorunlar bile bir anda flame çıkarmaya başlamışken bu iletişim ve güven sorunlarımızı çözmeye öncelik vermenin, ağırlıklı olarak birlikte çalışmayı nasıl kolaylaştıracağımızı konuşmamızın acil olduğunu düşünüyorum. Özetle, toplantı fikri ortaya çıktığı andan itibaren bu toplantının kangren haline gelmiş sorunların yüzyüze konuşulmasını sağlayacağını ve başarılı olmasının kendini Pardus geliştiricisi / katkıcısı / kullanıcısı / evangelisti / temsilcisi vs sayan *herkesin* fikrini açıkça ortaya koymasına bağlı olduğunu düşündüm, Sürüm Camia Temsilcisi ve Topluluk Yöneticisinin bu toplantıya katılmamasının da duyduğum en harika fikir olduğunu söyleyemeyeceğim.. -- Ekin Meroğlu ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] [Buildfarm] [x86_64 Buildfarm] info
Merhaba; On Friday 11 June 2010 11:54:39 Ozan Çağlayan wrote: Ben bu erlang'i güncelliyorum. Yıllardır güncelleyince jabber sunucusu düzgün çalışmıyor diye güncellemiyoruz 3 sene önceki sürümdeyiz. Corporate2 üzerinde deploy edilen jabber sunucumuz yok nasılsa, yine sorun çıkarsa yeri ve zamanı geldiğinde o zaman sorunu çözmeye çalışırız. Paket çok fena durumda.. Bence doğru olanı yapıyorsun da c2'de jabber sunucusuna ihtiyaç duyacağımız günler de çok uzak değil :-P -- Ekin Meroğlu ekin_at_pardus.org.tr Pardus Linux - www.pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] [Buildfarm] [x86_64 Buildfarm] info
On Friday 11 June 2010 13:37:52 Ozan Çağlayan wrote: Bence doğru olanı yapıyorsun da c2'de jabber sunucusuna ihtiyaç duyacağımız günler de çok uzak değil :-P Hata çözmek de bu işin bir parçası sonuçta, oturup çözeriz. Bugüne kadar yap(a)mamamız hata zaten - kısacası go go go ! -- Ekin Meroğlu ekin_at_pardus.org.tr Pardus Linux - www.pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] 2011/devel/system/base/pciutils - Version bump, refactor package, update PCI ID data...
Merhaba, Thread'İn geri kalanındaki AUTHORS, THANKS vs önerilerine genelde katılmakla birlikte, History'de tutup, index'e sokmamak da fena bir çözüm gibi durmuyor history'yi kaybetmemek için. Buna bayaa bi +1: tek derdimiz credit vermek değil bence, paketin geçmiş, neyken ne olduğunu hızla göden geçirmek gerekiyor... -- Ekin Meroğlu ekin_at_pardus.org.tr Pardus Linux - www.pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] [Stable] [Security] applications/printing/cups
On Saturday 05 December 2009 11:28:15 Ozan Çağlayan wrote: Use-after-free (crash) due improper reference counting in abstract file descriptors handling interface (CVE-2009-3553) (#11663). QA ? S? -- Ekin Meroğlu ekin_at_pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] 2008/devel/applications/virtualization/kvm - Limit instructions to 15 bytes (CVE-2009-4031) (#1...
On Friday 04 December 2009 15:20:43 Ozan Çağlayan wrote: Author: ozan.caglayan Date: Fri Dec 4 15:20:43 2009 New Revision: 82134 Added: 2008/devel/applications/virtualization/kvm/files/kvm.git-e42d9b8141d1f54ff7 2ad3850bb110c95a5f3b88.patch Modified: 2008/devel/applications/virtualization/kvm/pspec.xml Log: Limit instructions to 15 bytes (CVE-2009-4031) (#11640). BUG:COMMENT:11640 Ozan, bunu da aldım stable'a, eline sağlık.. Yalnız deneyebileceğim makinem yok artık, paketi deneyemedim... Bi de QA ve S alalım... -- Ekin Meroğlu ekin_at_pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] kurumsal 2?
Merhaba, - Alfa da olsa en azindan base kurulum icin bir ISO, rootfs, vs ne zaman cikacak? Depo base kismini geceli cok oldu -- elinizde calisan bir sistem mutlaka vardir. Bayram dönüşü umuyoruz, tamamlayıp iso'ya dahil etmek istediğimiz birkaç özellik bekliyoruz. - Kurulum sonrasi derleme ciftliginin derleyip durdugu ikili paketlere nasil ulasacagiz? (http://paketler.pardus.org.tr/corporate2/ dizini var ama ici bos) http://paketler.pardus.org.tr/corporate2-test/ dene :-) Sık sık sync oluyor... Diğer konular için uzunca bir mail ve duyuru yazacağım, geciktiğinin farkındayım - H1N1 vurdu da buraları biraz :-P -- İyi Çalışmalar; Ekin Meroğlu ekin_at_pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] firefox - profil destegi
On Tuesday 24 November 2009 00:40:02 Doruk Fisek wrote: Mon, 23 Nov 2009 23:27:34 +0100, selim ok seli...@gmail.com : Ben 2008'de firefox -P seklinde calistirdigimda profil yoneticisi gelmiyor, yeni bir profil yaratamiyorum. Kullanimda bir yanlislik var sanirim :) -P profileStart with profile. -ProfileManager Start with ProfileManager. Ben yanlis yazdim, -ProfileManager diye yazdigimda profil yoneticisi gelmiyor; direkt Firefox aciliyor. 2008 sistemimde -ProfileManager ile profil yöneticisi açılıyor bende. Denemişsindir tahminen ama .mozillayı silince ne oluyor ? -- İyi Çalışmalar; Ekin Meroğlu ekin_at_pardus.org.tr ... What if what you do to survive // Kills the things you love - [Bruce Springsteen / Devils Dust] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] comar-api bağımlılıkları
On Tuesday 24 November 2009 15:43:27 Ozan Çağlayan wrote: hm evet akonadi var mesela ordan KDE'ye kadar gider, her şey kaldırılır. comar-api bağımlılıkları zamanında strict dep gereksinimden koyulmuştur temizlenebilir artık büyük ihtimalle. Evet, zamanında comar-api'deki yeni bir özellik için koyulmuştu çoğu.. -- İyi Çalışmalar; Ekin Meroğlu ekin_at_pardus.org.tr ... What if what you do to survive // Kills the things you love - [Bruce Springsteen / Devils Dust] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] Güvenlik Güncellemeleri - Secur ity Fixes (2009-11-25)
Merhaba / Hi, Bu gece kararlı depolara girecek güvenlik güncellemeleri : Tonight's Security Fixes for Pardus stable repos : --- * Pardus 2008 kdelibs-3.5.10-88-15.pisi kdelibs-apidox-3.5.10-88-15.pisi mod_php-5.2.11-73-13.pisi php-cli-5.2.11-73-13.pisi php-common-5.2.11-73-13.pisi -- Ekin Meroğlu ekin_at_pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] firefox - profil destegi
Merhaba, Sorun neyse, ayni sorun 2008'de de var gozukuyor. Evet, herhangi bir cikti vermeden donuyor. Iki ayri 2008 kurulumunda, bir tane de 2009 kurulumunda .mozilla'yi tamamen ucurarak da denedim, sonuc ayni. Kurulu olan başka bir paket yüzünden olabilir mi ? 2008 için benim denediğim makine neredeyse standart kurulum - contrib ekli bile değil mesela.. -- İyi Çalışmalar; Ekin Meroğlu ekin_at_pardus.org.tr ... What if what you do to survive // Kills the things you love - [Bruce Springsteen / Devils Dust] ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[Gelistirici] Güvenlik Güncellemeleri - Secur ity Fixes (2009-11-19)
Merhaba / Hi, Bu gece kararlı depolara girecek güvenlik güncellemeleri : Tonight's Security Fixes for Pardus stable repos : --- * Pardus 2008 gimp-2.6.7-42-14.pisi gimp-devel-2.6.7-42-14.pisi gimp-i18n-2.6.7-42-13.pisi gimp-i18n-am-2.6.7-42-8.pisi gimp-i18n-ar-2.6.7-42-10.pisi gimp-i18n-az-2.6.7-42-8.pisi gimp-i18n-be-2.6.7-42-10.pisi gimp-i18n-bg-2.6.7-42-10.pisi gimp-i18n-ca-2.6.7-42-10.pisi gimp-i18n-ca_valencia-2.6.7-42-10.pisi gimp-i18n-cs-2.6.7-42-10.pisi gimp-i18n-da-2.6.7-42-10.pisi gimp-i18n-de-2.6.7-42-10.pisi gimp-i18n-dz-2.6.7-42-10.pisi gimp-i18n-el-2.6.7-42-10.pisi gimp-i18n-en_CA-2.6.7-42-10.pisi gimp-i18n-en_GB-2.6.7-42-10.pisi gimp-i18n-eo-2.6.7-42-10.pisi gimp-i18n-es-2.6.7-42-10.pisi gimp-i18n-et-2.6.7-42-10.pisi gimp-i18n-eu-2.6.7-42-10.pisi gimp-i18n-fa-2.6.7-42-10.pisi gimp-i18n-fi-2.6.7-42-10.pisi gimp-i18n-fr-2.6.7-42-10.pisi gimp-i18n-ga-2.6.7-42-10.pisi gimp-i18n-gl-2.6.7-42-10.pisi gimp-i18n-gu-2.6.7-42-10.pisi gimp-i18n-he-2.6.7-42-10.pisi gimp-i18n-hi-2.6.7-42-8.pisi gimp-i18n-hr-2.6.7-42-10.pisi gimp-i18n-hu-2.6.7-42-10.pisi gimp-i18n-id-2.6.7-42-10.pisi gimp-i18n-is-2.6.7-42-8.pisi gimp-i18n-it-2.6.7-42-10.pisi gimp-i18n-ja-2.6.7-42-10.pisi gimp-i18n-ka-2.6.7-42-8.pisi gimp-i18n-km-2.6.7-42-10.pisi gimp-i18n-ko-2.6.7-42-10.pisi gimp-i18n-lt-2.6.7-42-10.pisi gimp-i18n-lv-2.6.7-42-8.pisi gimp-i18n-mk-2.6.7-42-10.pisi gimp-i18n-ml-2.6.7-42-8.pisi gimp-i18n-ms-2.6.7-42-10.pisi gimp-i18n-nb-2.6.7-42-10.pisi gimp-i18n-ne-2.6.7-42-10.pisi gimp-i18n-nl-2.6.7-42-10.pisi gimp-i18n-nn-2.6.7-42-10.pisi gimp-i18n-oc-2.6.7-42-10.pisi gimp-i18n-pa-2.6.7-42-10.pisi gimp-i18n-pl-2.6.7-42-10.pisi gimp-i18n-pt-2.6.7-42-10.pisi gimp-i18n-pt_BR-2.6.7-42-10.pisi gimp-i18n-ro-2.6.7-42-10.pisi gimp-i18n-ru-2.6.7-42-10.pisi gimp-i18n-rw-2.6.7-42-10.pisi gimp-i18n-sk-2.6.7-42-10.pisi gimp-i18n-sl-2.6.7-42-10.pisi gimp-i18n-sr-2.6.7-42-10.pisi gimp-i18n-sr_Latn-2.6.7-42-10.pisi gimp-i18n-sv-2.6.7-42-10.pisi gimp-i18n-th-2.6.7-42-8.pisi gimp-i18n-tt-2.6.7-42-10.pisi gimp-i18n-uk-2.6.7-42-10.pisi gimp-i18n-vi-2.6.7-42-10.pisi gimp-i18n-xh-2.6.7-42-10.pisi gimp-i18n-yi-2.6.7-42-10.pisi gimp-i18n-zh_CN-2.6.7-42-10.pisi gimp-i18n-zh_HK-2.6.7-42-8.pisi gimp-i18n-zh_TW-2.6.7-42-10.pisi -- Ekin Meroğlu ekin_at_pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
Re: [Gelistirici] 2009/devel/hardware/powermanagement/acpica - fix wrong building of iasl when LC_CTYPE is tr_TR....
On Sunday 15 November 2009 22:39:53 Onur Küçük wrote: Anlamadığım şey, 2009 farmında bu sorunu niye daha önce görmediğimiz, orada da Türkçe yereli kullanılıyor. Farm derlerken C yereline geçiyor :-P ---8 # (at your option) any later version. # # Please read the COPYING file. import os os.environ[LC_ALL] = C ---8 -- Ekin Meroğlu ekin_at_pardus.org.tr ___ Gelistirici mailing list Gelistirici@pardus.org.tr http://liste.pardus.org.tr/mailman/listinfo/gelistirici
[no subject]
subscribe kvm -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Gelistirici] Test deposunda delta paketer (was: color{svn/cvs/gcc})
Merhaba; Sunday 29 April 2007 tarihinde, S.Çaðlar Onur þunlarý yazmýþtý: Tercihim 2007.2 ile deltaya geçmek ve delta paketleri 2007.2 - güncellemeler þeklinde tutmak. 2007'den beri tüm paketler için olasý tüm deltalar hallice yer tutuyor :) 2007.2 iyi bir baþlangýç da, pek fazla zamanýmýz yok, aaklýmýzda bulunsun : 2007.1'den beri 270 Mb (yaklaþýk) update'e geldik bile :-) -- Ýyi Çalýþmalar; Ekin Meroglu ekin_at_pardus.org.tr ... did i listen to pop music because i was miserable, or was i miserable because i listened to pop music?... - rob [nick hornby / hi fi]
[Gelistirici] IRC Toplantısı #3
Merhaba; Friday 27 April 2007 tarihinde, Ismail Dönmez þunlarý yazmýþtý: On Friday 27 April 2007 17:10:20 S.Çaðlar Onur wrote: Selamlar; Normalde önümüzdeki hafta içi yapmamýz gereken IRC toplantýsýný þenlik nedeniyle 1 hafta ileri atýyorum :), hatta ve hatta þenliðe gelebilecek olanlarýnýz varsa orada toplanmayý öneriyorum? ÇATI'da yemekli bir toplantý yapsak mesela? =) +1 ekin.
[Gelistirici] Depo Politikası
Merhaba; Thursday 19 April 2007 tarihinde, Gürer Özen þunlarý yazmýþtý: Son kýsýmda farklý konudaki maddeler ayný seviyede gruplanmýþ. Ayýrt etmek zor oluyor. Bunu biraz toparladým ama daha düzgün bir gruplama - hiyerarþi gerektiriyor hala. Paketlerin inþa sýrasýnda inþa dizini dýþýnda iþlem yapmamalarý, inþa ve çalýþma baðýmlýlýklarýnýn eksik yada hatalý yazýlmamasý, cyclic baðýmlýlýklarý olmamasý gereði, depoya alýnma kurallarýna eklenebilir. Bunlarý ekledim.. ekin.
[Gelistirici] [merge] kernel/drivers/ov51x-jpeg
Tuesday 03 April 2007 tarihinde, Onur Küçük þunlarý yazmýþtý: Merhaba, Kararlý sürüme geçildi. Kod temizliði ve decompression sistemi toparlandý. merged.
[Gelistirici] [merge] kernel/drivers/gspca
Tuesday 03 April 2007 tarihinde, Onur Küçük þunlarý yazmýþtý: Merhaba, quickcam express ler için görüntü iyileþtirmesi yapýldý merged. ekin.
[Gelistirici] [merge] desktop/kde/firewall-config
Wednesday 04 April 2007 tarihinde, Bahadýr Kandemir þunlarý yazmýþtý: * Kozmetik deðiþiklikler * Port aralýðý denetimindeki bir hata giderildi * Dil desteði (ca, it, fr) merged. ekin.
[Gelistirici] [merge] desktop/kde/service-manager
Wednesday 04 April 2007 tarihinde, Bahadýr Kandemir þunlarý yazmýþtý: * Sadece servisleri listele seçeneðinin hatýrlanmasý * Baþlatýlamadý/Durdurulamadý mesajlarý yerine, servisten gelen hata mesajýnýn gösterilmesi merged. ekin.
[Gelistirici] [paketler-commits] r21933 - in devel/applications/network/mozilla/firefox: . comar files/searchplugins/wikipedia
Merhaba; Saturday 24 March 2007 tarihinde, paketler-uludag at uludag.org.tr þunlarý yazmýþtý: Author: ahmet Date: Sat Mar 24 16:38:52 2007 New Revision: 21933 Added: devel/applications/network/mozilla/firefox/files/searchplugins/wikipedia/wi kipedia_en.src - copied, changed from r21931, [] devel/applications/network/mozilla/firefox/pspec.xml Log: Done :) Ahmet, bu search fasilitesi iyileþtirmeleri için merge istememiþsin, 2007 deposu için uygun deðiller mi - sormadan merge etmeyeyim dedim.. ekin.
[Pardus-kullanicilari] kde başlamıyor...
Merhaba; Thursday 29 March 2007 tarihinde, ahmet hacýkasýmoglu þunlarý yazmýþtý: çalýþan cd ile chroot yaomak ve pam paketini kurmak ne demektir.Benim sorunu çözermi . baþka bir kaynek yada bilgi verebilirmisiniz. teþekkürler Mesajlarý okudum ama test deposunu mu kullanýyorsunuz anlayamadým açýkçasý. Bahsedilen sorun __sadece__ pardus-2007-test deposunu kullanan sistemlerde ortaya çýktý, test deposunu kullanmýyorsanýz sorununuz bu deðildir. ekin.
[Gelistirici] updeytler
Sunday 25 March 2007 tarihinde, Gürer Özen þunlarý yazmýþtý: On Sunday 25 March 2007 04:35:18 S.Çaðlar Onur wrote: * Bunun dýþýnda kalan her paket test deposunda 1 hafta geçirdikten sonra _sadece ve sadece_ o ikili paket ile ilgili yeni bir hata girilmemiþ ise depoya girecek. Bunu eskiden çalýþan bir þeyi bozan yada derecesi normalin üstünde (yada normal ve üstü de olabilir) olan bir hata diye deðiþtirmeyi öneriyorum. Yoksa her iyileþtirme önerisi, vb için bugfixleri yaymayý önlemeyelim. Tabii ki, her açýlan hata bildirimini sorgusuz sualsiz sürüm engelleyici kabul etmeyelim... ekin.
[Gelistirici] nvida.py
Merhaba; Wednesday 21 March 2007 tarihinde, Ismail Dönmez þunlarý yazmýþtý: nvidia kart sahipleri http://cekirdek.pardus.org.tr/~ismail/hacks/nv.tar.bz2 yi çalýþtýrýp python nvidia.py doðru kartý buluyor mu bakabilir mi? nvidia paketlerini tek paket yapýcam... Ýþin doðru sürücüyü bulma kýsmýný bir tarafa býrakýyorum (onu bir þekilde becerirsin güvenim tam :-) nvidia-glx-1.0_9631-17-40.pisi 2.7M nvidia-kernel-1.0_9631-17-52.pisi 1.1M nvidia-tools-1.0_9631-17-36.pisi542K Toplam : ~4.4 M nvidia-glx-new-1.0_9755-2-2.pisi3.0M nvidia-kernel-new-1.0_9755-2-2.pisi 1.4M nvidia-tools-new-1.0_9755-2-2.pisi 544K Toplam : ~5M nvidia-glx-old-1.0_7184-11-32.pisi 2.1M nvidia-kernel-old-1.0_7184-11-47.pisi 819K nvidia-tools-old-1.0_7184-11-30.pisi 354K Toplam : ~3.3M Yani yamulmuyorsam eskiden 5M ila 3.3M paketi olan kullanýcýya artýk her kernel update'inde 12. 5M update göndericez... Umarým yanlýþ anlýyorumdur, yoksa korktum :-P ekin.
[Gelistirici] 23/03/2007 PardusDev IRC Toplantısı
Merhaba ; Saturday 24 March 2007 tarihinde, A. Murat Eren þunlarý yazmýþtý: Merhabalar, Kaçýranlar ve ben ne yapacaktým hatýrlamýyorum diyenler için toplantý tutanaðýný þu adrese attým: http://tr.pardus-wiki.org/23-03-2007_IRC_Toplantýsý Bundan sonra da bunu bir gelenek haline getirip bir formatta toplantý tutanaklarýný arþivleyelim diyorum. Eline saðlýk, özet çok anlamlý olmuþ.. Tüm log'u da koysak arþiv amaçlý olarak ? ekin.
[Gelistirici] [RFC] Breaks tagi
Merhaba; Wednesday 21 March 2007 tarihinde, S.Çaðlar Onur þunlarý yazmýþtý: Pakete deverse dep. de yazmaktan bahsediyorsun onu anladým, ilk anda mantýklý geliyor evet ama bizi dependency hell içinde býrakacakmýþ gibi de bir durum var. Bu noktadaki doðru çözüm Gürer'in distro major sürüm güncellemeleri farklý bir araç ya da komutla yapýlmalý tekniði sanýrým. +1 2007 için olabildiðince basit kalalým, 2007 -- 2008 geçiþini ayrý bir problem olarak ayrý bir araçla (betikle, komutla her ne ise) çözelim.. ekin.
[Gelistirici] Merge:applications/crypto/trousers, tpm-tools, tpmmanager kernel/drivers/tpm-emulator
Monday 19 March 2007 tarihinde, ertugrulerata þunlarý yazmýþtý: bu paketlerin 2007 ye merge edilmesini arz ediyorum. applications/crypto/trousers,tpm-tools,tpmmanager kernel/drivers/tpm-emulator merged.. ekin.
[Gelistirici] Bugzilla ve Geliştirici listesi üzerine..
Sunday 18 March 2007 tarihinde, A. Murat Eren þunlarý yazmýþtý: Merhabalar, Biraz uzun olacak fakat lütfen vakit ayýrýp okuyun ve en azýndan öneriler hakkýnda iki kelime de olsa düþüncelerinizi dile getirin.. Bugzilla: Bugzilla'ya Türkçe yazýp çiziyoruz. Dýþardan gelen birisi için hata girmek iþkence; önceki hatalarda arama yapamadýklarý için hem çözümlere ulaþamýyorlar hem de girecekleri þey daha önce girilmiþ olabilir diyerek çekinceyle yaklaþýyorlar. Bu konuda düzenli olarak yakýnýyor insanlar. Bugzilla'da Türkçe konuþulmasý baþta bir avantaj idi fakat yavaþ yavaþ bir dezavantaja dönüþmeye baþladý. Bugzilla konusunda çift dilli olmanýn dýþýnda bir seçenek göremiyorum. Engellemek için yapýlabilecekler belli: - Bugzilla **sadece** ingilize olsun : Yorum yapmak isteyen ? - Her hata özeti/yorum/açýklama ingilizceye de çevrilsin : Bu kadar zamaný olan bir geliþtiricimiz veya gönüllümüz varsa zamanýný KDE ve uygulama yerelleþtirmelerine harcasýn, on kat daha yararlý bir iþ yapmýþ olur - bence. - Bugzilla'ya herkes kendi dilinde hata girsin, duplicate iþaretleme iþi bize kalsýn, daha önce çözülmüþ bir sorun faklý bir dilde girilirse o sorunun çözümünü diðer dile çevirelim - bu aslýnda þu anki iþleyiþin birazcýk daha ilerisi - teoride olmasý gerekeni. Þu, þu anda Bugzilla'da tespiti ve çözümü çok sýkýcý olabilecek bir çok sorunun çözümü Türkçe olarak yatýyor. Biz baþkalarýnýn hata takip sistemlerinden faydalanýrken baþkalarýnýn bizim çözüðümüz sorunlarý yeniden çözmek zorunda kalýyor olduklarý düþüncesi Pardus'un amaçlarý ile pek örtüþmediði gibi Pardus'un duyulurluðunun ve saygýnlýðýnýn da belirli bir seviyenin üstüne çýkmasýna engel oluyor. Öneri þu: Bugzilla'da mümkün olduðunca, yapabilenlerin Ýngilizce hata girmesini saðlamak. Prensipte böyle bir öneriyi onaylarsak Bugzilla'ya da hatýrlatýcý mesajlar ekleyebiliriz ve Bugzilla'nýn anadilinin Ýngilizce olduðunu nedenlerinin açýklandýðý bir sayfaya referans vererek yazabiliriz. Ne diyorsunuz? Bugzillanýn anadilinin Ýngilizce olmasý, ama Türkçe de hata girilebilmesi bence yanlýþ - projenin bilgi birikimi oluþturmak hedefiyle de pek uyuþmuyor (sonradan gelen edit : aþaðýda sen de yazmýþsýn). Evet dýþarýdan gelen birçok kiþi bu bilgiye ulaþamýyor, evet ideal olaný bu deðil, evet özgür yazýlým perspektifinden bakýnca ürettiðimiz / paylaþtýðýmýz bilginin olabildiðince çok insana ulaþmasý çok ama çok önemli, ama bir seçim yapmak zorundayýz - Pardus eksiksiz bir Türkçe desteði ile bu ülkedeki masaüstü kullanýcýsýnýn iþletim sistemi olacaksa, hatalarýnýzý anadili Ýngilizce olan hata takip sistemimize girersiniz demek en hafif deyimle gülünç olacaktýr. Kaldý ki italyanca/ispanyolca/korece vsvs dillerdeki bugzillalardaki çözümlere de ben ulaþamýyorum böyle bakýnca.. Bu sorunun sebebi Babil kulesi, çözümü de tüm dünyanýn ayný dili konuþmasý (esperanto ?) Hatýrlatýcý mesajda Bugzillanýn anadilinin Türkçe olduðu, diðer dillerde hata girenlerin kendi dillerinde arama yapmalarýný, hatayý bulamazlarsa yeni hata olarak girmelerini söyleyelim, yukarýda dediðim gibi duplicate iþaretleme, varsa çözümün o dilde anlatýlmasý iþi bize kalsýn. Geliþtirici Listesi (paketlerin merge istekleri dýþýnda) projenin gidiþatýnýn belkemiðini oluþturuyor. Proje ile ilgili neler döndüðünün anlaþýlmasý açýsýndan dýþarýdan gelen birisinin takip etmeye en çok ihtiyaç duyacaðý mecralardan birisi bu liste. Bu listenin de tamamen Türkçe olmasýnýn ne gibi sorunlar doðurduðunu uzun uzun yazmayacaðým. Þu ana kadar bize katýlan 10 tane yabancý geliþtiricinin her birinin çeviri iþleri üzerinde çalýþýyor olmasý zaten yeterli bir gösterge. Bu listede bundan sonra Ýngilizce yazalým demek mümkün deðil, burada çok sinir bozucu bir handikap var: Hem geliþtirici listesinin, Ýngilizce'sini yeterli hissetmeyenlerin yazmaktan çekindiði bir yer olmasý kesinlikle olmasýný istemeyeceðimiz bir þey olurdu, hem Türkçe bilgi birikimi, bu ülkedeki insanlarýn da ana dillerinde takip edebilecekleri açýk bir üretim ortamý yaratmak amaçlarýmýzdan birisi, hem bu projenin Türkiye sýnýrlarýný aþmasý yurt dýþýndan katký almasý gerekli, hem de bu projede üretilen çözümlerin özgür yazýlýmýn gereðince yurt dýþýnda çözüm arayanlarýn karþýsýna çýkmasý gerekli. Ýki uçlu deðnek deðil artýk bu, çokgen filan. Bu konuda ne yapalým sizce? Ayný minvalde geveliycem : Anadilin Ýngilizce (veya Fransýzca veya Ýtalyanca veya Klingonca) olmasý anlamlý deðil. Aklýma gelen bir iyileþtirme haftalýk bir developer's digest tadýnda özet çalýþmasýnýn web sitesinde ve devel listesinde yayýnlanmasý. Bunun dýþýnda ise genel fikir sorma, teknik tartýþma gibi konularýn olabildiðince geniþ katýlýmla yapýlabilmesi için maillerin ingilizcelerinin - en azýndan özetinin - devel listesine de gönderilmesi aklýma gelen tek adým - çok uygulanabilir olmasa da. Drþsöþst (sezar þifrelemesi). Diycek biþey yok ... ekin.
[Gelistirici] Güncellemeler
Merhaba; Bugün duyurduðumuz güncellemeler ile : Vanilla 2007 kurulumunun hemen arkasýndan 'pisi up' toplam 363 Mb, Vanila 2007.1 kurulumunun hemen arkasýndan 'pisi up' ise 110 Mb güncelleme getiriyor.. ekin.
[Pardus-kullanicilari] pardus 2007.1
Friday 16 March 2007 tarihinde, Selim Ýmre þunlarý yazmýþtý: Anlayamadým, yükseltmek yeterli derken Pisi aracýlýðý ile çekirdek güncellemesini mi kast ediyorsunuz? Yoksa ayrý bir dosya çekip, onu ayrýca kurmayý mý?? Teþekkürler... Program ekle, güncelle veya kaldýr aracýmýz ile tüm güncellemeleri yapmanýz 2007.1 sürümüne (hatta daha güncel bir Pardus'a) sahip olmanýz için yeterli. 2007.1 Felis chaus, Pardus 2007'den beri kararlý depomuza giren güvenlik güncellemeleri, hata düzeltmeleri ve iyileþtirmeleri içeren bir sürüm. Süregelen Pardus 2007 güncellemelerinde olmayan -tabiri caizse ekstra- bir þeyler içermiyor. Ýyi Çalýþmalar, Ekin Meroðlu.
[Gelistirici] [paketler-commits] r21301 - playground/cartman/perly
Thursday 15 March 2007 tarihinde, paketler-uludag at uludag.org.tr þunlarý yazmýþtý: Author: cartman Date: Thu Mar 15 00:04:56 2007 New Revision: 21301 Removed: playground/cartman/perly/ Log: Fatih Akýn'a selam olsun Ýsmail dur yazacaktým ama geç kalmýþým, bir daha ki sefere artýk.. :-P Eline saðlýk.. ekin.
[Gelistirici] Operation Snow Flake : Complete
Merhaba; Saturday 10 March 2007 tarihinde, Ismail Dönmez þunlarý yazmýþtý: On Friday 09 March 2007 22:52:12 Ismail Dönmez wrote: Selamlar, playground/cartman/flac-migration altýnda tüm paketleri FLAC 1.1.4'e geçirdim. Devel'e merge etmeyi düþünüyorum. Ýtirazlar varsa alayým. libsndfile'a flac depi yazýlmadýðý için biraz fazla paket etkilendi. Liste þöyle: akode audacity [...] vorbis-tools xine-lib Listeye vlc'yi de ekleyin. Amcalar ... Encoding and decoding speedups for all modes. Encoding at -8 is twice as fast. ... Completely rewritten bitbuffer which uses native machine word size instead of bytes for dramatic speed improvements. diyorlar, hadi bakalým.. Sadece devel'e merge ediyorsan neden olmasýn diyorum - derleyen sensin hayat bana güzel durumu :-) ekin.
[Gelistirici] [merge] applications/games/boswars
Friday 09 March 2007 tarihinde, Onur Küçük þunlarý yazmýþtý: Merhaba, Farm da configure sýrasýnda patlýyordu, çözülmüþ olmasý lazým. merged. ekin.
[Gelistirici] Son çağrı 2007.1...
Sunday 04 March 2007 tarihinde, S.Çaðlar Onur þunlarý yazmýþtý: Selamlar; 2007.1 için çözülmesi gereken, þu da olsa/böyle olsa/þöyle olsa olur dediðiniz v.s birþeyler kaldýysa bu son çaðrýdýr. Pazartesi saat 12:00'den sonra yazdýklarýnýza 2007.2 için inþallah diyeceðim :P, benim elimdeki liste þöyle; * ISO'lar CD'ye sýðmýyor, * disk-manager/update-fstab sorunlu, * kde-i18n-tr 3.5.6 ile sync olmalý, * Ne olduðunu net olarak anlamadýðým dhcpcd sorunlarý çözülmeli, Yalý için bende þöyle bir not var : * Grub yazýlamadýðý durumlarda kullanýcýlar da eklenemiyor, Barýþ nispeten kolay, sýrayý deðiþtiririz demiþti. * Sistem ikinci (veya üçüncü) diske kurulduðunda Yalý GRUB'i da o diskin MBR'sine yazmayý öneriyor - listede o seçenek highlited oluyor. Bu çoðu insanýn kafasýný karýþtýrdý, Genel kullanýcý senaryosunda çift disk de olsa bios ilk diskten boot etmeye ayarlý oluyor. Biz de ilk diskin MBR'sine kurmayý önersek daha iyi olacak sanki. * Yukarýdaki durumda bir de þöyle bir sorunumuz var : GRUB ikinci diskin MBR'sine kurulsa da açýlacaðý diski (hd1,X) gibi yazýyor, ama gerçekten o diskten açýldýðý anda kendisi artýk 1. disk olduðu için boot edemiyor - (hd0,X) olmalý.. Bu konu biraz muallak, akþama kadar tekrarlanabilir bir senaryo geliyor. * Birden fazla diskin olduðu durumlarda diskler listelenirken ters sýrada listeleniyor. (hdc, hdb, hda gibi) RC-test'i portekizce kurdum bu arada, Openoffice ve Firefox Ýngilizce. Pek sayýn paket sorumlularý, beklediðimiz bir durum mu ? Çevirileri yok mu ? ekin.
[Gelistirici] Son çağrı 2007.1...
Merhaba; Monday 05 March 2007 tarihinde, Barýþ Metin þunlarý yazmýþtý: * Grub yazýlamadýðý durumlarda kullanýcýlar da eklenemiyor, Barýþ nispeten kolay, sýrayý deðiþtiririz demiþti. Þu anda Grub kurulumu ekranýndan geri dönüp tekrar kullanýcýlar üzerinde iþlem yapabiliyoruz. Bunu yaparsak, kirli çözüm için geri dönebilme yeteneðini kaldýrmam gerekecek. Daha sonra yapalým, daha düzgün yapalým? Bence geri dönemesin daha az zararlý : zaten o adýmý geçtiyse en azýndan bir kullanýcýsý vardýr, ekleme vs iþini o kullanýcýyla sistemi açýp yapar. Ama öbür durumda adamý grafik sisteme login olamayacak bir durumda býrakýyoruz. Ey geliþtirici listesi, ne diyorsunuz ? Yazdýktan sonra hatýrladým, asýl canýmýzý sýkan CD'yi eject edemediðimiz durumda kullanýcýlarýn oluþturulamamasý / grub yazýlamamasý idi ve bu sorun da o sorun deðil mi ? * Sistem ikinci (veya üçüncü) diske kurulduðunda Yalý GRUB'i da o diskin MBR'sine yazmayý öneriyor - listede o seçenek highlited oluyor. Bu çoðu insanýn kafasýný karýþtýrdý, Genel kullanýcý senaryosunda çift disk de olsa bios ilk diskten boot etmeye ayarlý oluyor. Biz de ilk diskin MBR'sine kurmayý önersek daha iyi olacak sanki. Listelenen ilk disk öneriliyor artýk, fakat bunun için daha iyi (kesin?) bir çözüm bulabilirsek sevinirim :). Grub'dan açýlýþ diskinin hangisi olduðunu öðrenebilseydik tadýndan yenmezdi aslýnda :). * Birden fazla diskin olduðu durumlarda diskler listelenirken ters sýrada listeleniyor. (hdc, hdb, hda gibi) Düzeltildi. Ýkisine birden yazýyorum : evet listelenen ilk diskin seçilmesi daha mantýklý, ama daha genel bir kural veya yöntem de aklýma gelmiyor. Þu anda hem sdX hem hdX olan makinelerde önce sd... sonra hd.. lerin sýralanmasý biraz garip, ama o konuda yapacaðýmýz birþey yok, kernel 2.6.20 ile birlikte hdX tarih olacaðýndan (inþallah :-)) sorun kendiliðinden çözülecek... Yine daha farklý bir senaryo ve/ya çözüm önerisi olan yoksa böyle kalsýn derim ben. Eline saðlýk..
[Gelistirici] Son çağrı 2007.1...
Monday 05 March 2007 tarihinde, S.Çaðlar Onur þunlarý yazmýþtý: 05 Mar 2007 Pts tarihinde, Ismail Dönmez þunlarý yazmýþtý: On Monday 05 March 2007 14:00:32 S.Çaðlar Onur wrote: 05 Mar 2007 Pts tarihinde, Ekin Meroðlu þunlarý yazmýþtý: RC-test'i portekizce kurdum bu arada, Openoffice ve Firefox Ýngilizce. Pek sayýn paket sorumlularý, beklediðimiz bir durum mu ? Çevirileri yok mu ? firefox için yerel eklendi... OpenOffice için eklerim ama 100mb güncelleme istiyor muyuz? bence istemiyoruz Bir sonraki güncelleme için deftere yazalým o zaman... ekin.
[Gelistirici] [merge] desktop/freedesktop/zorg
Friday 02 March 2007 tarihinde, Onur Küçük þunlarý yazmýþtý: Merhaba, inf2mondb betiðinde her manufacturer için tek id ayarlanmasý, bazý diller için keymap tanýma düzeltmeleri vs. içeriyor. Ayrýca Gökmen'in ekran kartý deðiþikliðini tanýma özelliði de eklendi. merged.. ekin.
[Gelistirici] [merge] kqemu / virtualbox
pnp ok midir, wheel mi yapalim? Bence wheel, yapacaðý iþ az biþey diil, bildiðin yeni makine kuruyor adam - admin olmayan yapamazýn derim... -- Ekin Meroðlu ekin at pardus.org.tr
[Gelistirici] [Uludag-commits] r12558 - trunk/tasma/package-manager
Tuesday 27 February 2007 tarihinde, Faik Uygur þunlarý yazmýþtý: 27 Þub 2007 Sal 16:19 tarihinde, Barýþ Metin þunlarý yazmýþtý: History ve Index içerisinden alamayacaðýmýz hangi bilgiler ayrý bir dosya yaratmamýza neden oluyor? Kýsaca Ekin'in duyuru listesinde yaptýðý iþi paket yöneticisinde görünür hale getirmeye çalýþýyorum. Tekrarlanan bilgiler olduðu doðru ancak... History'de bulunan bilgiler _geliþtiricilere yönelik_ ama genelde de _çöp_ bilgiler oluyor. Geliþtiricilere bunlarý daha farklý yazmalarýný diretmenin de pratikte pek bir iþe yarayacaðýný düþünmüyorum. Duyuru listesinde bu iþ için özel zaman ayrýlarak hazýrlanmýþ, güncelleme bilgilerinin kullanýcýlara yönelik zengin halleri bulunuyor. Çeviri gruplarý aracýlýðý ile güncellemeler öncesi bu dosyalarýn farklý dillerde hazýrlanmasý da mümkün. Öncelikli olarak þu anki yapý da, bahsettiðim sebep dýþýnda bu bilgileri Türkçe göstermemiz de mümkün olmuyor. History'e dil desteði eklemek de hem tutulan bilgiler, paketlerin takip ve çeviri iþini zorluðu, hem de pspec'in misliyle büyümesine yol açacaðýndan pek anlamlý gelmiyor. Ben yazana kadar Faik yazmýþ, kullanýcýya yönelik içerik ( != commit loglarý, != history taglari) ve i18n önemli noktalar. Bir de bu xml'den belirli formatlarda / birden fazla dilde duyuru ve wiki dokumaný oluþturacak scriptler yazmayý düþünüyorum, þu anda sýrf duyuru ve wiki editlemek bile sýký zaman kaybý oluyor, otomatize edebilirsem çok iyi olacak. ekin.
[Gelistirici] [merge] Disk Manager
Monday 19 February 2007 tarihinde, Gökmen GÖKSEL þunlarý yazmýþtý: 19 Þub 2007 Pts tarihinde, Gökmen GÖKSEL þunlarý yazmýþtý: 19 Þub 2007 Pts tarihinde, Gökmen GÖKSEL þunlarý yazmýþtý: * Hatalý fstab dosyasý yüzünden çakýlma problemi giderildi, * Disk grubunda olmayan kullanýcýlar için yetki sýnýrlandýrýlmasý düzeltildi, * pt-BR dili eklendi :-) Biþi daha ekleyeceðimdir please wait :) Merge please :) Merged... ekin.
[Gelistirici] kpowersave desktop
Monday 19 February 2007 tarihinde, S.Çaðlar Onur þunlarý yazmýþtý: Selamlar; [1]'de göreceðiniz gibi kpowersave'in desktop sistemlerde öntanýmlý açýlmamasý ile ilgili bir hatamýz mevcut, / eski yama kpowersave refactor'ü sebebi ile artýk uygulanmýyor /, upstream böyle bir hamlenin son derece gereksiz olduðunu, adýnýn kpowersave olmasýnýn güç tasarufu yapan bir uygulama olarak deðil, hal'ýn ilgili bacaðýný manage eden bir uygulama olarak görülmesini öneriyor Bu programcý açýsýndan doðru bakýþ açýsý ama kullanýcý açýsýndan pek öyle deðil gibi, ne bilsin hal'ý, powersave bacaðýný :-) Bi de ikonu sakat meretin, desktop makinede fiþ/priz simgesi gören soluðu bugzilla da alýyor :-) ve desktoplar suspend/hibernate etmiyor mu diyor? Evet, üstüne ekran dpms/powersave özelliklerini de ayarlýyor ama taþýnabilir makinelerin aksine bu ayarlar system trayde durup her dakika göze sokulacak önemde deðil diye düþünüyorum desktop sistemlerde. Ekran güc koruma/vs ayarlarýnýn yeri tasma, hibernate/suspend iþi de zaten logout/shutdown menusunun iþi bence.. Yok ben desktop makinede de þemadan þemaya koþarým diyenler de bi kere çalýþtýrsýnlar, yerleþsin tray'e. Ayný þekilde bu istek bana da manasýz geliyor, laptoplarda çok daha iþe yaradýðý aþikar fakat desktop makinamda da kullanýyorum ben örneðin. Her neyse gelelim sonuca :), halen böyle birþeyin gerekli olduðunu düþünen var mý? Bunu eski yama gibi kpowersave desktop görürse açýlmasýn þeklinde yapmak yerine kaptan'a soru olarak eklemeyi düþünüyorum, itirazý olan var mý? Kaptan ÖSS oluyor :-) Bir de kullanýcýnýn ilk anda bu konuyla ilgili fikri olacakmýþ gibi gelmiyor bana... Ya da benden baþka býrak elleme isteyen zaten kapatýr diyen mevcut mu? Kapatalým, isteyen açsýn.. Ya da þöyle söyliyim, kapatmak iþi çok büyük takla gerektirmiyorsa desktop makinlerde kapalý gelmesini tercih ederim. ekin.
[Gelistirici] NM Kablosuz ağ tarayıcı
Merhaba; Tuesday 13 February 2007 tarihinde, Furkan Duman þunlarý yazmýþtý: network-manager'ýn kablosuz að tarayýcýsýný Wifi Radar'dan (http://wifi-radar.systemimager.org/) esinlenerek biraz geliþtirdim. Eline saðlýk, ne zamandýr aklýmýzda olup hep ertelediðimiz bir iyileþtirmeydi... ekin.
[Gelistirici] NM Kablosuz ağ tarayıcı
Merhaba; Tuesday 13 February 2007 tarihinde, Erkan Tekman þunlarý yazmýþtý: Görsel iki öneri: Baðlantý kalitesi algýlamasý zor olan mevcut þekil yrine çok daha hýzlý anlaþýlabilecek bir çubuk grafik olsa. Ayrýca þifrelemeyi gösteren ikon daha az belirgin olsa da olabilir, çünkü varlýðý ve yokluðu zaten çok gerekli bilgiyi içeriyor. Mevcut görüntü ile þifre ikonu kalite grafiðine çok baskýn. Bir evet, þifreleme ikonu daha az baskýn olsa daha iyi olacak sanki. Bir hayýr, sýkýldým bar ikonlarýndan, pywireless ikonlarýný çok seviyorum :-) Bir öneri daha: Mode ve MAC ilk baþta görünmese ve bir bilgi (i) simgesine basýldýðýnda çýkan bir özette (iwlist scan ile elde edilebilecek bilgilerin tümü mesela) görünseler. Hedef kitlemiz için bu bilgi yalnýzca kafa karýþtýrýcý... MAC lazým Gürer'in de dediði gibi, bu kadar temel bir ekranda da yeni pencereler falan fazla karýþýk bence. Ama Mode konusunda haklýsýn, zaten Ad-Hoc baðlantý desteklemediðimiz için sadece Masterlar anlamlý - baðlanýlabilir, dolayýsýyla bu ekranda listelemenin bir anlamý yok. Ýlerde Ad-Hoc desteklersek atýyorum bir ikon ile ayýrýrýz Bu Master bir AP, bu Ad-Hoc bir Node diye.. Bir de son talep: Hazýr bu kadar el deðmiþken WPA iþini de çözüp NM'yi 2007.1'e hazýr hale getirsek deiyorum... Bu pasý Furkan alýr ve gol yapar diyorum ben, WPA ile de bu kadar uðraþmýþken hazýr :-) ekin.
[Gelistirici] NM Kablosuz ağ tarayıcı
Merhaba; Tuesday 13 February 2007 tarihinde, Gürer Özen þunlarý yazmýþtý: Yalnýz þöyle bir nokta var, seçim sýrasýnda bulunan her bir essid için bir tane macsýz, en az bir tane de her bir ap için macli olmak üzere birden fazla entry olmalý. Yani ben aliveli essid'ini ayný essidli herhangi bir yere baðlanma modunda, yada yalnýzca þu mac'i olan ap'ye baðlan modunda seçebilmeliyim. Link betiði henüz bakmýyor bu bilgiye, ama bakacak. Bunun kullaným senaryolarýnda çok gerekli olduðunu düþünüyorum ama ortalýðý çok karýþtýracak diye de korkuyorum, þöyle bir fikrim var : Bir ESSID ile birden fazla AP olduðunda, sadece ESSID görünsün, ama bu ESSID tüm AP'lerin tree view'in baþlýðý olsun - öntanýmlý da tree kapalý olsun. Bu adam ne dedi burada derseniz, þöyle birþey : Ýlk scan anýnda aliveli ESSID'li 3 AP, bi de hedehodo ile vedevodo bulunmuþ olsun : ... hedehodo (00:13:46:63:F2:CD) + aliveli ... vedevodo (00:23:46:63:F2:AD) Sadece aliveli seçilirse essid=aliveli, en yüksek quality'e baðlan demiþ oluruz. Yok ben belli bir aliveli'ye baðlanacaðým diyenler aliveli'nin +'sýna týklar: ... hedehodo (00:13:46:63:F2:CD) + aliveli |- aliveli (00:13:46:63:F5:01) |- aliveli (00:13:46:63:F5:02) |- aliveli (00:13:46:63:F5:03) ... vedevodo (00:23:46:63:F2:AD) açýlan listeden istediði AP'yi seçer... Ne dersiniz ? ekin.
[Pardus-kullanicilari] Devlet Eliyle Guvenli Internet
Friday 09 February 2007 tarihinde, yoksul þunlarý yazmýþtý: 09 Þub 2007 Cum 09:21 tarihinde, Serbulent UNSAL þunlarý yazmýþtý: Konqueror u kaldýrýp firefoc için aþaðýdaki eklentileri deneyebilirsiniz. merhaba.. Konqueror neden kaldýrýlýyor ?.. ve nasýl kaldýrýlýyor ?.. ve de, kaldýrýnca ne oluyor ? Serbülent bey baþka birþey anlatmaya çalýþtý sanýrým, Özelde Pardus'da genelde KDE'de konqueror kaldýrýlamaz (eðer çok uðraþmazsanýz :-P) Konqueror, temel kde bileþeni kdebase paketinin bir parçasý : Name: kdebase, version: 3.5.5, release: 104, build 78 Summary: KDE base packages: the desktop, panel, window manager, konqueror... Kdebase paketini kaldýrmanýz da yaklaþýk olarak tüm masaüstü sisteminizi silmeniz anlamýna geliyor tahmin ettiðiniz gibi.. ekin.
[Gelistirici] paketler-commits
Merhaba Eren; Öncelikle bu mail sana cevap, ama çoðu fikrim genel - o yüzden kiþisel alma. Bu feedbacklerin amacýnýn contrib deposuna eklenen paketlerin istatistiðini tutmak ve kullanýcýlarý bilgilendirmek olduðunu zannediyordum ancak dün irc'de Ýsmail ile konuþtuðuma göre depo sorumlusu olmamdaki tek amaç sizleri bilgilendirmek imiþ. Açýkcasý bunu duyduðumda þok oldum. Ýsmail adýna konuþmayayým ama burada bir gariplik var, ya o anlatamadý ya sen anlamadýn ama toplantýda bundan çok daha fazlasýnýn senin sorumluluðunda olacaðý konuþuldu zaten. Bunu söylediðinize göre contrib-commits listesi takip edilmiyor, bunun küçük bir kanýtý olarak dün devel deposuna alýnýp sonra merge edilen bir kaç tane perl paketi verebilirim. O perl paketleri aylardýr contrib'de duruyordu, anlaþýlan yapýlýrken contrib'e bakma tenezzülünde bile bulunulmamýþ. Öncelikle Tenezzül lafýnýn biraz amacýný aþtýðýný düþünüyorum. Özetlemek gerekirse, Contrib deposuna bir sorumlu gerekmesinin sebebi hem zaman hem iþgücü anlamýnda contrib deposuna bu seviyede ilgi gösterecek kaynaðýmýz olmamasý.. Herkesin - hem çekirdek ekip üyelerinin hem gönüllü geliþtiricilerin - daha ilgili olduklarý alanlar olduðu gibi hakkýnda hiç fikirleri olmayan alanlar var. Depo sorumlusu tanýmý gereði depoyu iyi tanýyacak, diðer geliþtiricileri bilgilendirecek. Üstüne üstlük, contrib deposuna özel bir durum da deðil ayný paketlerin bir kaç kez yapýlmasý - tam zamanlý geliþtiriciler bile kaç kez depoda olan paketi tekrar tekrar yaptý sayýsýný unuttum. Böyle daðýtýk bir geliþtirme sürecinde normal bu tip olaylar, kiþisel almaya gerek yok.. Öyleyse contrib'in onemi nedir? Hatta þöyle söyleyeyim, önemi var mýdýr? Contrib'in önemini sormak için gerçekten biraz geç deðil mi? Tek kelime : Önemi büyük. Toplantýnýn da iyi geçtiðini söyleyemem, düzgün konusulan bir konu olmadý. Bu büyüklükteki bir geliþtirici toplantýsýna ilk kez katýldýðým için ne ile karþýlaþtýrarak bu sonuca vardýðýný bilmiyorum, ama bence kaçýrdýðýn nokta þu : Hepimiz bu þekilde bir geliþtirme sürecini öðrenme evresindeyiz : sonuçta senin ilk toplantýn olduðu gibi bizim de ilk toplantýmýzdý. Toplantýya yön verme sorumluluðu hepimizdeydi, statik bir gündemle toplantýyý zapt-u rapta almak tercih etmediðimiz bir yöntemdi. Ama bu toplantýdan düzgün konuþulan bir konu olmadý sonucunu çýkarmana kendi adýma çok üzüldüm, eðer bu düþüncedeysen neden konuþmak istediðin konularý daha çok gündeme getirmedin, gündeme getirdin de insanlar konuþmadý mý diye merak ettim. Konusmaya çalýþýlýrken birileri oyun oynadý, kulaklýðýný takýp müzik dinledi, diðeri odadan çýkýp sigara içti vs. Dediðim gibi toplantýnýn gündemi statik deðildi ve maalesef gönüllü geliþtiriciler de gündemi yönlendirme konusunda nispeten pasif kaldýlar. Ben insanlarýn özelde paketleriyle, genelde geliþtirme süreciyle ilgili sorunlarýný daha çok dile getireceklerini umuyordum : öyle olmadý, toplantý da daha serbest bir hale dönüþtü. En az üç kere eee koca contribin tek derdi gnome mu yani diye konuþuldu en basitinden, ama tartýþma baþka yere gidemedi. Gelip elimizi sýkan, derdini anlatan, sohbet eden biri olmadý. Adýný bilmediðim, yüzünü görüp tanýþmadýðým bir sürü insan vardý orada.. Benimse bir sürü küçük grupta konuþup tanýþtýðým hatta geyik yaptýðým bir sürü insan var : birþeyler konuþmak isteyen herkes konuþtu bence - ben son derece samimi göründüðümüzü düþünüyorum, kimsenin birþeyleri gündeme getirmekten çekinmesine sebep olduðumuz düþünmüyorum. Bu tavýrlarýn neyi ifade ettiðini anlamýþ deðilim. Neyi anlatmak istediðinizi açýkca söylerseniz kimsenin darýlýp güceneceðini zannetmiyorum.. Tavýr konusunu anlatmaya çalýþtým yukarýda : Birþey anlatmaya çalýþmadýk, anlatmak istediklerimizi açýk açýk söyledik zaten. - Contrib deposunu devel deposu kadar yakýndan takip edecek zamanýmýz ve iþgücümüz yok, bu konudaki sorumluðumuz daðýtmak istiyoruz : Depo sorumlusu ve component sahipleri bu iþin ilk adýmý.. - Kendinizi contrib ile sýnýrlamayýn, her türlü bug elinizden öper - projeleri anlamak için en iyi yer basit hatalarý çözmeye çalýþmaktýr. - Contrib deposunun derlenmeye baþlanmasý için bizim teknik sorunlarýmýz var, ama deponun da belli bir seviyeye gelmesi lazým. Durum contrib'in ve bir þeyler yapmak isteyenlerin önemsiz olduðunu gösteriyor. Böyle birþey yok.. Sevgili Çaðlar'ýn þakayla karýþýk da olsa contrib'i silme fikri hiç de mantýksýz gelmemeye baþladý. Durum böyle olunca diðer katkýcýlarýmýzýn yapacaklarýna devam edeceklerini zannetmiyorum.. Belki ukalaca bulacaksýn ama, bu tip projeleri izlemeye baþladýðým günden beri öðrendiðim belki de en basit kuralý yineleyeceðim : Bir özgür yazýlým projesinde hiç kimseye sýrf geldiði için ne iyi yaptýn da geldin, gittiði için de ne olur gitme denmez. Bu dilekleri insanýn yaptýðý iþ ile kazanmasý gerekir, o da bu tip projeler de maalesef uzun zaman boyunca tutarlý çalýþmalarla elde edilebiliyor - ne
[Pardus-kullanicilari] Modem driverı derleme
Merhaba; 04 Þub 2007 Paz 22:03 tarihinde, can comert þunlarý yazmýþtý: Merhabalar, inteiln 536EP seri numaralý dial up modeminin driverýný derlemeye çalýþýyordum ve /lib/modules/. version.h adýnda bir dosya olmadýðý için derleme gerçekleþmedi kernel source paketinin kurulu olduðundan ve tüm kernel güncellemelerinin yapýlmýþ olduðundan emin olun. ekin.
[Pardus-kullanicilari] Güzel bir haber
31 Oca 2007 Çar 19:09 tarihinde, Yýlmaz Bilgili þunlarý yazmýþtý: Hemen sýcaðý sýcaðýna bir þey sormak istiyorum. Geçen de sormuþtum ama kimsenin gözüne çarpmadý herhalde. Çalýþan CD de açýldýðý haliyle NTFS bölümleri okunamýyor. Bu sorunun giderildiði bir güncellenmiþ Çalýþan CD olacak mý acaba? Pardus 2007 Çalýþan CD için böyle bir hata bildirilmedi bildiðim kadarýyla, biz de testlerimizde böyle bir hata ile karþýlaþmadýk - þu anda desktop makinemde Çalýþan CD açýk ve ntfs bölüme dosya yazýp okuyorum.. NTFS bölümü windows ile kullanýyorsanýz windows'u düzgün kapatarak (hibernate deðil !) çýktýðýnýzdan emin olun. ekin.
[Gelistirici] [merge] multitail
30 Oca 2007 Sal 13:54 tarihinde, Doruk Fisek þunlarý yazmýþtý: Merhaba, Bi suru yeni ozellik eklenmis durumda, bi suru de hata duzeltmesi var. Geriye donuk bir uyumsuzluk yok. Ters bagimlilik problemi de yok. Diyorum ki 2007'ye merge :) Merged
[Gelistirici] [merge] nano 2.0.3
29 Oca 2007 Pts 16:12 tarihinde, Doruk Fisek þunlarý yazmýþtý: Merhaba, Yeni surum, hata duzeltmeleri var. Nano genelde saglam bir paket, bisileri bozdugu gorulmedi, zaten ters bagimliligi da yok. Yani diyorum ki merge :) merged.. ekin.
