Bug#281050: [i810] Memory leak
Package: xserver-common Version: 4.3.0.dfsg.1-8 Followup-For: Bug #281050 Hello, I'm experiencing heavy XFree86 memory leaking as well. I killed the process before finding out about this bug report, so I can't provide any useful info right now. Over around 100 hours of active usage the resident part grew to more than 200MB (right now after restarting X it is a mere 16MB), and the system became really sluggish. The bug should not be related to a particular desktop environment or application: I have switched to GNOME a couple of days ago, because I thought KDE was slow -- but apparently this leak had been the problem all the time! It somehow never struck me to check the memory usage of the X server, until now. Please fix this bug, it is *extremely* annoying and disappointing to think that I will have to restart every couple days to have a usable system. Thanks for your time, -- Gintautas Miliauskas -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-custom Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) Versions of packages xserver-common depends on: ii debconf [debconf-2.0] 1.4.40 Debian configuration management sy ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an ii xfree86-common4.3.0.dfsg.1-8 X Window System (XFree86) infrastr -- debconf information: xserver-common/xwrapper/nice_value/error: * xserver-common/xwrapper/nice_value: -10 * xserver-common/xwrapper/allowed_users: Console Users Only xserver-common/xwrapper/actual_allowed_users: console
Bug#281050: xserver-common: [i810] Memory leak
Hello, > 1) Have you read the Debian X FAQ entry on this issue? > >.../xsf/XFree86/trunk/debian/local/FAQ.xhtml#xservmemory I have read the entry, but I don't think I have learned anything I don't know already. > 2) Do you think you are experiencing the same problem as seen in bug >#279940? > >http://bugs.debian.org/279940 Possibly; the symptoms are similar. However, I'm sure it's not the flash plugin that is causing problems. My friend also has this problem, and he found a way to reproduce it with gpdf (Gnome's PDF viewer). Just use gpdf to open a largish PDF file (the IBM DB2 reference at ftp://ftp.software.ibm.com/ps/products/db2/info/vr82/pdf/en_US/db2s1e81.pdf having 900 pages worked well for me), and watch X memory usage soar. Closing gpdf afterwards does not help, however, opening the same file with gpdf again does not eat yet another 200MB of memory. It could mean that some buffer is allocated by X and then enlarged as needed, but not shrunk later when it's not in use any more. It's interesting to notice that memory is sucked further even when I'm browsing the already opened PDF file; I just held for a few moments (the page counter went up to 297), waited for gpdf to stop CPU activity (I think it was rendering every page) and then I saw that X ate another 30MB. xrestop also showed a several thousand increase in the 'Extra' column. By the way, I'm not sure, but I think my friend said that he had an ATI video card. I tried to reproduce this problem on several other machines (I don't know their hardware configurations, but I'm pretty sure the software is up to date, i.e., testing or unstable), but the problem did not manifest itself on those machines -- gpdf happily opened the files without any significant side effects. I have little idea why the problem exists on my machine and on my friend's machine, but not on the others that I have tested. > 3) Can you please use the "xrestop" program and provide (text) > screenshots of its operation, so we can see if there are any > culpable clients? I am attaching snapshots of top, pmap and xrestop before starting gpdf (suffix ".before"), after opening the DB2 reference with gpdf (suffix ".after", and after closing gpdf (suffix ".closed"). My XF86Config-4 and output of xdpyinfo are included as well. Note that I wasn't using gpdf previously (nor was I opening large PDFs), so I don't think you should put all the blame on it as you did for the flash plugin. I am experiencing a gradual increase of memory usage rather than sudden jumps. There might be a bug in gpdf, but I am concerned with the fact that the memory is not released even after I quit gpdf. I now tried opening several large apps (OpenOffice.org, GIMP, Eclipse, etc.) and some of the hogged-up memory was swapped out (resident block of X fell from 230MB to 107MB). At least that stuff swaps out, but it still makes my system rather slow (perhaps because it starves the filesystem cache). Another very thing I have experienced a few times is an almost-complete freeze of my machine when exiting a heavy app (I remember experiencing it with Eclipse and some other programs too). Even the mouse cursor stops moving, and for about one minute there is very intensive hard disk activity. Then the system starts responding again as if nothing had happened. I could not find anything interesting in the logs or output of `top`. This might not be related to this bug, but I'm including it in case other people have experienced such a thing too. My machine is a Toshiba laptop with a 2.2GHz P4 and 512MB of RAM, Intel 855GM video chipset, I'm using Debian unstable. I hope I provided some useful information (I will be happy to provide more if you need anything else). It's a pity that I don't really have time right now (well, to be honest, not quite enough experience either...) to fire up a debugger and chase the culprit myself. -- Gintautas Miliauskas <[EMAIL PROTECTED]> x-leak-info.tar.gz Description: application/compressed-tar signature.asc Description: Ši laiško dalis yra pasirašyta skaitmeniniu būdu
Bug#281050: xserver-common: [i810] Memory leak
Hello, > Anyway, one way to test at least parts of my hypothesis would be simply to > turn off the XAA pixmap cache. To do this, add the following line to the > "Device" section of your XF86Config-4 file: > >Option "XaaNoPixmapCache" > > It might be worth trying the following as well: > >Option "XaaNoOffscreenPixmaps" > > Both of the above are documented in XF86Config-4(5x), by the way. I added both of these to the "Device" section, didn't change anything. I also tried to add them to the "Screen" section (as the manual says), without any difference either. Taking this a step further, I completely disabled XAA (Option "Accel" "off"). It did wonders to slowing my system to a crawl, yet gpdf would still hoard memory, which means that the problem has not gone away. I presume that these results do not go well with your hypothesis? Is there anything else I can do to at least help find out which part of X is the culprit? This bug is really a PITA for me (I even made a tiny cron script that mails me if X takes up more than 80MB (resident); it takes about two days to reach that threshold). Thanks for your help, -- Gintautas Miliauskas <[EMAIL PROTECTED]> signature.asc Description: Ši laiško dalis yra pasirašyta skaitmeniniu būdu
Bug#198745: xprt: init script delay
Package: xprt Version: 4.2.1-8 Severity: minor Xprint init script tries to solve a race condition by 'sleeping' for 2 seconds. I suggest using lockfiles as a cleaner solution. Besides, that would get rid of the delay. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#200699: xdm: log rotating
Package: xdm Version: 4.2.1-8 Severity: wishlist Hello Maybe it would be a good idea to add a logrotate item for /var/log/xdm.log, just to be consistent. It does accumulate size slowly. -- Gintautas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#198745: xprt: init script delay
Package: xprt Version: 4.2.1-8 Severity: minor Xprint init script tries to solve a race condition by 'sleeping' for 2 seconds. I suggest using lockfiles as a cleaner solution. Besides, that would get rid of the delay.
Bug#200699: xdm: log rotating
Package: xdm Version: 4.2.1-8 Severity: wishlist Hello Maybe it would be a good idea to add a logrotate item for /var/log/xdm.log, just to be consistent. It does accumulate size slowly. -- Gintautas
Bug#281050: xserver-common: [i810] Memory leak
Hello, I'm CCing my friend, Modestas Vainius, who told me about gpdf's uncanny ability to make X eat lots of memory. Perhaps he could provide some useful information. > I'm sorry it has taken a little while to get back to you. Oh, don't worry. I am very happy that you are helping me. > Well, you could try using a different X display driver. There are two > possibilities: > > 1) vesa > 2) fbdev I have just booted on VESA. I was surprised that it was completely painless -- 1024x768 with 32-bit colours worked out of the box. Anyway, I can still make X hoard memory by opening a large file with gpdf. I have also tried to boot kernel 2.4.25 (instead of 2.6.8, which I'm running now), just in case, but the result was absolutely the same. I did not try fbdev, because I had trouble with the framebuffer on this laptop and framebuffer support is disabled in the kernel. Anyway, as far as I understand it the idea here is to make sure that the bug is not in the i810 driver. > If you can reproduce your resource leak problems with either or both of > these drivers, then I strongly suspect a problem in the hardware-neutral > parts of the XFree86 DDX implementation (which I think is mostly stubs), or > the DIX portion. But then the big question is, why don't other people notice this? If it's in a generic layer, the problem should be visible everywhere. > Thanks for your indulgence with my proposed experiments, and I'm sorry they > did not mitigate or rectify the issue. Well, it's the least I can do as I *really* want this problem fixed. By now I have developed a strong feeling that I'm on something that is either expected behaviour or a result of a personal tweak. Maybe the resources should be cleaned up some time after the program using it is gone? The problem did not solve itself for me though. Actually in other systems I have seen X use lots of virtual RAM after extended periods of uptime, but the resident portion was never that large. It also does not seem to get swapped out easily. I am also very uncomfortable that the only quick and reliable way to reproduce this is with gpdf. It could be a bug in gpdf, or maybe in both X and gpdf that causes the problem. I think that it might be a good idea to try X.Org and see if the problem persists. I will try booting the Ubuntu (hoary) live CD tomorrow which runs X.Org and see if the problem manifests itself there as well. -- Gintautas Miliauskas <[EMAIL PROTECTED]> signature.asc Description: =?iso-8859-2?Q?=A9i?= =?iso-8859-2?Q?_lai=B9ko?= dalis yra =?iso-8859-2?Q?pasira=B9yta?= skaitmeniniu =?iso-8859-4?Q?b=FEdu?=
Bug#281050: xserver-common: [i810] Memory leak
Hello, I just tried gpdf on a large file with X.Org on Ubuntu Hoary (booted from a live CD). It appears that the problem is still there, but to a lesser extent. The PDF file that made XFree86 suck 200+ MB only expanded the X.Org server to 60-70MB. After a few minutes usage dropped to 45MB. While it is still noticeable, the effect is significantly smaller. Since gpdf is just a very vague and imprecise indicator of the actual problem of X sucking up large amounts of memory over extended periods of time, it would probably be more useful to try to run X.Org in real-life situations. I am contemplating migration to Hoary, but I am not sure that I can find time to do that. I will probably do the migration during the next few months, but I would not bet on it. P.S. Should I continue to send copies of mails to you directly, or will you pick them out from the Debian bug tracker system (I am not sure if it is sending copies to you automatically)? -- Gintautas Miliauskas <[EMAIL PROTECTED]> signature.asc Description: =?iso-8859-2?Q?=A9i?= =?iso-8859-2?Q?_lai=B9ko?= dalis yra =?iso-8859-2?Q?pasira=B9yta?= skaitmeniniu =?iso-8859-4?Q?b=FEdu?=
Bug#281050: xserver-common: [i810] Memory leak
Hello, > > > I just tried gpdf on a large file with X.Org on Ubuntu Hoary (booted > > > from a live CD). It appears that the problem is still there, but to a > > > lesser extent. The PDF file that made XFree86 suck 200+ MB only > > > expanded the X.Org server to 60-70MB. After a few minutes usage dropped > > > to 45MB. While it is still noticeable, the effect is significantly > > > smaller. > > > > > > Since gpdf is just a very vague and imprecise indicator of the actual > > > problem of X sucking up large amounts of memory over extended periods of > > > time, it would probably be more useful to try to run X.Org in real-life > > > situations. I am contemplating migration to Hoary, but I am not sure > > > that I can find time to do that. > > > > You don't have to do a wholesale upgrade to hoary to run X.org from it. > > Indeed, if you need a Hoary/X.org environment to help with > testing/reproducing a bug, one option is to try the (rough, but functional) > Hoary live CD: > > http://cdimage.ubuntu.com/daily-live/current/ Thanks for the pointer, but I did use the Hoary live CD, as noted in the first of the two paragraphs you cited. I intended to say by the second paragraph that it would might be more useful to use X.Org for everyday work. I am not sure if Ubuntu's X.Org can be installed without problems on a standard Debian unstable system, and I am not aware of any unofficial X.Org packages. Even then, X is a critical piece of software so I would think twice before jumping onto some untested package. I mentioned Hoary because if I upgraded to it, the X upgrade problem would be solved and I would be using standard, tested packages. Thanks for your assistance, everyone, -- Gintautas Miliauskas http://gintasm.blogspot.com signature.asc Description: =?iso-8859-2?Q?=A9i?= =?iso-8859-2?Q?_lai=B9ko?= dalis yra =?iso-8859-2?Q?pasira=B9yta?= skaitmeniniu =?iso-8859-4?Q?b=FEdu?=
Bug#281050: xserver-common: [i810] Memory leak
Hello, > X footprint keeps growing because of repeatable memory allocations for the > cursor > and gdk_cursor_unref() failures to free that memory. However, this doesn't > happen > with all types of cursors. Only *animated* ones are affected (I base > this hypothesis on my tests). Indeed, I switched to an unanimated cursor theme as a workaround, and the problem seems to have gone away. I owe you one! -- Gintautas Miliauskas signature.asc Description: =?iso-8859-2?Q?=A9i?= =?iso-8859-2?Q?_lai=B9ko?= dalis yra =?iso-8859-2?Q?pasira=B9yta?= skaitmeniniu =?iso-8859-4?Q?b=FEdu?=
Bug#374974: [l10n] debconf-updatepo in debian/rules clean
Package: xorg Severity: wishlist Tags: l10n -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, This page here http://www.debian.org/international/l10n/po-debconf/errors-by-pkg#Pxorg warns about outdated .pot and .po files and says that to fix this you need to invoke debconf-updatepo in debian/rules clean. Sorry if this is bogus, just wanted to point this out in case you simply had not noticed. - -- Gintautas Miliauskas http://gintasm.blogspot.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEmoRHZEjTEI4o1DsRApMaAJwLDLftD1NXsi2I7XlxP3WfjDYoNACgh7zg FWSG273DRtqcf6MO4Cm6TAk= =4AoE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497314: [INTL:lt] Updated Lithuanian translation of xorg debconf templates
Package: xorg Version: 1:7.3+10ubuntu10.2 Severity: wishlist Tags: patch l10n Hello, an updated debconf Lithuanian translation is attached. Best regards, -- Gintautas Miliauskas # translation of lt.po to Lithuanian # #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to #this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' #Some information specific to po-debconf are available at #/usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans# #Developers do not need to manually edit POT or PO files. # # Gintautas Miliauskas <[EMAIL PROTECTED]>, 2006, 2007. msgid "" msgstr "" "Project-Id-Version: lt\n" "Report-Msgid-Bugs-To: [EMAIL PROTECTED]" "POT-Creation-Date: 2008-06-08 22:20+0200\n" "PO-Revision-Date: 2008-08-31 23:09+0300\n" "Last-Translator: Gintautas Miliauskas <[EMAIL PROTECTED]>\n" "Language-Team: Lithuanian <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: KBabel 1.11.4\n" "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && (n%" "100<10 || n%100>=20) ? 1 : 2);\n" #. Type: select #. Description #: ../xserver-xorg.templates:2001 msgid "X server driver:" msgstr "X serverio tvarkyklė:" #. Type: select #. Description #: ../xserver-xorg.templates:2001 msgid "" "For the X Window System graphical user interface to operate correctly, it is " "necessary to select a video card driver for the X server." msgstr "" "Kad X Window System grafinė sąsaja veiktų, būtina pasirinkti video kortos " "tvarkyklę." #. Type: select #. Description #: ../xserver-xorg.templates:2001 msgid "" "Drivers are typically named for the video card or chipset manufacturer, or " "for a specific model or family of chipsets." msgstr "" "Tvarkyklės paprastai pavadinamos pagal video kortos arba lusto gamintoją " "arba pagal tam tikrą modelį ar lustų šeimą." #. Type: boolean #. Description #: ../xserver-xorg.templates:3001 msgid "Use kernel framebuffer device interface?" msgstr "Naudoti branduolio kadrų buferį (framebuffer)?" #. Type: boolean #. Description #: ../xserver-xorg.templates:3001 msgid "" "Rather than communicating directly with the video hardware, the X server may " "be configured to perform some operations, such as video mode switching, via " "the kernel's framebuffer driver." msgstr "" "Užuot bendravęs tiesiai su video technine įranga, X serveris gali vykdyti " "kai kurias operacijas, pavyzdžiui raiškos keitimą, per branduolio " "„framebuffer“ tvarkyklę." #. Type: boolean #. Description #: ../xserver-xorg.templates:3001 msgid "" "In theory, either approach should work, but in practice, sometimes one does " "and the other does not. Enabling this option is the safe bet, but feel free " "to turn it off if it appears to cause problems." msgstr "" "Teoriškai turėtų veikti abu būdai, tačiau pasitaiko, kad vienas veikia, o " "kitas ne. Paprastai ši galimybė turėtų būti pasirinkta, tačiau galite ją " "drasiai išjungti, jei ji kelia problemų." #. Type: string #. Description #: ../xserver-xorg.templates:4001 msgid "Video card's bus identifier:" msgstr "Video kortos magistralės vardas:" #. Type: string #. Description #: ../xserver-xorg.templates:4001 msgid "" "Users of PowerPC machines, and users of any computer with multiple video " "devices, should specify the BusID of the video card in an accepted bus-" "specific format." msgstr "" "PowerPC ir bet kokio kompiuterio su keliais video įrenginiais naudotojai čia " "turėtų nurodyti video kortos magistralės identifikatorių (BusID). " "Identifikatoriaus pavidalas priklauso nuo magistralės." #. Type: string #. Description #: ../xserver-xorg.templates:4001 msgid "Examples:" msgstr "Pavyzdžiai:" #. Type: string #. Description #: ../xserver-xorg.templates:4001 msgid "" "For users of multi-head setups, this option will configure only one of the " "heads. Further configuration will have to be done manually in the X server " "configuration file, /etc/X11/xorg.conf." msgstr "" "Naudotojams, turintiems kelis video įrenginius, šis pasirinkimas " "sukonfigū
Bug#418042: [INTL:lt] Lithuanian translation update
Package: xorg Version: 1:7.1.1ubuntu6.2 Severity: wishlist Tags: patch l10n -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 An updated debconf Lithuanian translation is attached. - -- Gintautas Miliauskas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGFkV1ZEjTEI4o1DsRAnV2AJ91cZs4v0tSewWlRSr4Zlwnbk5B4wCg7NjL eZg5D+r3DHQ5yiyxKrguD9E= =+hcr -END PGP SIGNATURE- # translation of lt.po to Lithuanian # #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to #this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' #Some information specific to po-debconf are available at #/usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans# #Developers do not need to manually edit POT or PO files. # # Gintautas Miliauskas <[EMAIL PROTECTED]>, 2006, 2007. msgid "" msgstr "" "Project-Id-Version: lt\n" "Report-Msgid-Bugs-To: [EMAIL PROTECTED]" "POT-Creation-Date: 2007-04-06 09:15+0200\n" "PO-Revision-Date: 2007-04-06 15:54+0300\n" "Last-Translator: Gintautas Miliauskas <[EMAIL PROTECTED]>\n" "Language-Team: Lithuanian <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: KBabel 1.11.4\n" "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && (n%100<10 || n%100>=20) ? 1 : 2);\n" #. Type: multiselect #. Description #: ../xserver-xorg.templates:2001 msgid "Video modes to be used by the X server:" msgstr "X serverio naudojamos skiriamosios gebos" #. Type: multiselect #. Description #: ../xserver-xorg.templates:2001 msgid "" "Please keep only the resolutions you would like the X server to use. " "Removing all of them is the same as removing none, since in both cases the X " "server will attempt to use the highest possible resolution." msgstr "" "Palikite pažymetas tik tas gebas, kurias turėtų naudoti X serveris. " "Nepažymėjus nieko arba pažymėjus viską X serveris pabandys parinkti " "didžiausią galimą gebą." #. Type: boolean #. Description #: ../xserver-xorg.templates:3001 msgid "Attempt to autodetect video hardware?" msgstr "Bandyti automatiškai detektuoti video techninę įrangą (vaizdo plokštę)?" #. Type: boolean #. Description #: ../xserver-xorg.templates:3001 msgid "" "You should choose this option if you would like to attempt to autodetect the " "recommended X server and driver module for your video card. If the " "autodetection fails, you will be asked to specify the desired X server and/" "or driver module. If it succeeds, further configuration questions about " "your video hardware will be pre-answered." msgstr "" "Pasirinkite šią galimybę, jei norite pabandyti automatiškai parinkti " "rekomenduojamą X serverį ir tvarkyklę Jūsų video kortai. Jei pavyks, tolesni " "klausimai apie video įrangą bus atsakyti automatiškai. Jei automatinis " "detektavimas nepasiseks, Jūsų paprašys nurodyti X serverį ir tvarkyklės " "modulį rankiniu būdu." #. Type: boolean #. Description #: ../xserver-xorg.templates:3001 msgid "" "If you would rather select the X server and driver module yourself, do not " "choose this option. You will not be asked to select the X server if there " "is only one available." msgstr "" "Jei norite pasirinkti X serverį ir tvarkyklę rankiniu būdu, nepasirinkite " "šios galimybės. Jei įdiegtas tik vienas X serveris, iš serverių pasirinkti " "nebus prašoma." #. Type: note #. Description #: ../xserver-xorg.templates:4001 msgid "No X server known for your video hardware" msgstr "Jūsų video įrangai tinkamų X serverių nerasta." #. Type: note #. Description #: ../xserver-xorg.templates:4001 msgid "" "There is either no video hardware installed on this machine (e.g. serial " "console only), or the \"discover\" program was unable to determine which X " "server is appropriate for the video hardware. This could be due to " "incomplete information in discover's hardware database, or because your " "video hardware is not supported by the available X servers." msgstr "" "Šiame kompiuteryje nėra įdiegta video įranga (pvz., yra tik nuosekli " "konsolė), arba programa „discover“ nesugebėjo nustatyti, kuris X serveris " "tinka jūsų
Bug#400396: [intl:lt] Lithuanian debconf templates' translation
Package: xserver-xorg Version: 7.0.0-0ubuntu45 Severity: wishlist Tags: l10n -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, a Lithuanian translation of the xorg debconf templates is attached. Best regards, - -- Gintautas Miliauskas http://gintasm.blogspot.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFFaMQjZEjTEI4o1DsRAmHSAJ9LO9uNl26CGbYI03pQ9rNK/m9eYQCg7/ue LquoTx5rkoIAphFSr5CKI7E= =/W8k -END PGP SIGNATURE- # translation of xorg-lt.po to Lithuanian # #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to #this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' #Some information specific to po-debconf are available at #/usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans# #Developers do not need to manually edit POT or PO files. # # Gintautas Miliauskas <[EMAIL PROTECTED]>, 2006. msgid "" msgstr "" "Project-Id-Version: xorg-lt\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2006-10-21 11:30+0200\n" "PO-Revision-Date: 2006-11-25 23:48+0200\n" "Last-Translator: Gintautas Miliauskas <[EMAIL PROTECTED]>\n" "Language-Team: Lithuanian <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: KBabel 1.11.2\n" "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && (n%100<10 || n%100>=20) ? 1 : 2);\n" #. Type: multiselect #. Description #: ../xserver-xorg.templates:1001 msgid "Video modes to be used by the X server:" msgstr "X serverio naudojamos skiriamosios gebos" #. Type: multiselect #. Description #: ../xserver-xorg.templates:1001 msgid "" "Please keep only the resolutions you would like the X server to use. " "Removing all of them is the same as removing none, since in both cases the X " "server will attempt to use the highest possible resolution." msgstr "Palikite pažymetas tik tas gebas, kurias turėtų naudoti X serveris. Nepažymėjus nieko arba pažymėjus viską X serveris pabandys parinkti didžiausią galimą gebą." #. Type: boolean #. Description #: ../xserver-xorg.templates:2001 msgid "Attempt to autodetect video hardware?" msgstr "Bandyti automatiškai detektuoti video techninę įrangą (vaizdo plokštę)?" #. Type: boolean #. Description #: ../xserver-xorg.templates:2001 msgid "" "You should choose this option if you would like to attempt to autodetect the " "recommended X server and driver module for your video card. If the " "autodetection fails, you will be asked to specify the desired X server and/" "or driver module. If it succeeds, further configuration questions about " "your video hardware will be pre-answered." msgstr "Pasirinkite šią galimybę, jei norite pabandyti automatiškai parinkti rekomenduojamą X serverį ir tvarkyklę Jūsų video kortai. Jei pavyks, tolesni klausimai apie video įrangą bus atsakyti automatiškai. Jei automatinis detektavimas nepasiseks, Jūsų paprašys nurodyti X serverį ir tvarkyklės modulį rankiniu būdu." #. Type: boolean #. Description #: ../xserver-xorg.templates:2001 msgid "" "If you would rather select the X server and driver module yourself, do not " "choose this option. You will not be asked to select the X server if there " "is only one available." msgstr "Jei norite pasirinkti X serverį ir tvarkyklę rankiniu būdu, nepasirinkite šios galimybės. Jei įdiegtas tik vienas X serveris, iš serverių pasirinkti nebus prašoma." #. Type: note #. Description #: ../xserver-xorg.templates:3001 msgid "No X server known for your video hardware" msgstr "Jūsų video įrangai tinkamų X serverių nerasta." #. Type: note #. Description #: ../xserver-xorg.templates:3001 msgid "" "There is either no video hardware installed on this machine (e.g. serial " "console only), or the \"discover\" program was unable to determine which X " "server is appropriate for the video hardware. This could be due to " "incomplete information in discover's hardware database, or because your " "video hardware is not supported by the available X servers." msgstr "Šiame kompiuteryje nėra įdiegta video įranga (pvz., yra tik nuosekli konsolė), arba programa „discover“ nesugebėjo nustatyti, kuris X serveris tinka jūsų video įrangai. Taip galėjo atsitikti dėl neišsamios informacijos „discover“ techninės įrangos duomenų bazėje arba dėl to, k
