Bug in Radeon in kernel 2.6.8?
I have just finished compiling both the 2.6.6 and 2.6.8 kernels and there appears to be a bug in the radeon_state piece of code in the 2.6.8 kernel that is absent in the 2.6.6 kernel. I receive the following compilation errors (2.6.8) CC drivers/char/drm/radeon_state.o drivers/char/drm/radeon_state.c: In function `radeon_cp_cmdbuf': drivers/char/drm/radeon_state.c:2316: warning: implicit declaration of function `drm_alloc' drivers/char/drm/radeon_state.c:2316: warning: assignment makes pointer from integer without a cast drivers/char/drm/radeon_state.c:2416: warning: implicit declaration of function `drm_free' That are absent from the compilation of 2.6.6. This leads to drivers/built-in.o(.text+0x51d71): In function `radeon_cp_cmdbuf': : undefined reference to `drm_free' drivers/built-in.o(.text+0x51daf): In function `radeon_cp_cmdbuf': : undefined reference to `drm_free' drivers/built-in.o(.text+0x524a7): In function `radeon_cp_cmdbuf': : undefined reference to `drm_alloc' make: *** [.tmp_vmlinux1] Error 1 I can remove these errors by not using the CONFIG_DRM_RADEON option. In the make menuconfig proceedure, this amounts to just saying no to ATI Radeon in the Character devices menu that is under the Device Drivers option of the main menu. Art Edwards -- Art Edwards Senior Research Physicist Air Force Research Laboratory Electronics Foundations Branch KAFB, New Mexico (505) 853-6042 (v) (505) 846-2290 (f) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug in Radeon in kernel 2.6.8?
I'm posting this to the group to notify that the package /kernel-source-2.6.8-16.deb still has the radeon bug. I'm clipping the last part of the compilation drivers/built-in.o(.text+0x51d71): In function `radeon_cp_cmdbuf': : undefined reference to `drm_free' drivers/built-in.o(.text+0x51daf): In function `radeon_cp_cmdbuf': : undefined reference to `drm_free' drivers/built-in.o(.text+0x524a7): In function `radeon_cp_cmdbuf': : undefined reference to `drm_alloc' make: *** [.tmp_vmlinux1] Error 1 So Bug#301488 should still be open. Art Edwards On Wed, Jun 01, 2005 at 05:25:24PM -0400, Marty wrote: > Art, > > I owe you an apology. I found out that my kernel sources were > old. When I updated them, I ran into the bug. A web search > indicates that this bug was filed as Bug#301488. Here is the > link I found referencing the bug: > > http://lists.debian.org/debian-kernel/2005/05/msg00377.html > > The bug was supposedly fixed, but I haven't seen the replacement > package yet. > > Marty > > > > Marty wrote: > >Art Edwards wrote: > >>Marty: > >> > >>I attach the config file and the snip of interaction with make bzImage > > > >Still works here (see new attachment). I'm stumped, and I would propose > >that you > >take it back to the list again, to see if anyone else has any ideas. Good > >luck! > > > >Marty > > > > > >> > >>Art > >> > >>chalcogenide:/usr/src/kernel-source-2.6.8# make menuconfig > >>scripts/kconfig/mconf arch/i386/Kconfig > >># > >># using defaults found in .config > >># > >> > >> > >>*** End of Linux kernel configuration. > >>*** Execute 'make' to build the kernel or try 'make help'. > >> > >>chalcogenide:/usr/src/kernel-source-2.6.8# make bzImage > >> SPLIT include/linux/autoconf.h -> include/config/* > >> make[1]: `arch/i386/kernel/asm-offsets.s' is up to date. > >>CHK include/linux/compile.h > >>LD drivers/char/drm/built-in.o > >>LD drivers/char/built-in.o > >>LD drivers/built-in.o > >>GEN .version > >>CHK include/linux/compile.h > >>UPD include/linux/compile.h > >>CC init/version.o > >>LD init/built-in.o > >>LD .tmp_vmlinux1 > >>drivers/built-in.o(.text+0x51d71): In function `radeon_cp_cmdbuf': > >>: undefined reference to `drm_free' > >>drivers/built-in.o(.text+0x51daf): In function `radeon_cp_cmdbuf': > >>: undefined reference to `drm_free' > >>drivers/built-in.o(.text+0x524a7): In function `radeon_cp_cmdbuf': > >>: undefined reference to `drm_alloc' > >>make: *** [.tmp_vmlinux1] Error 1 > >> > > > -- Art Edwards Senior Research Physicist Air Force Research Laboratory Electronics Foundations Branch KAFB, New Mexico (505) 853-6042 (v) (505) 846-2290 (f) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unsubscribe
-- Art Edwards Senior Research Physicist Air Force Research Laboratory Electronics Foundations Branch KAFB, New Mexico (505) 853-6042 (v) (505) 846-2290 (f) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unsubscribe
-- Art Edwards Senior Research Physicist Air Force Research Laboratory Electronics Foundations Branch KAFB, New Mexico (505) 853-6042 (v) (505) 846-2290 (f) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xmgrace ddd again
Neither xmgrace nor ddd will allow text input for AMD-64 architecture. This is a severe problem. I'm writing to the developers list because their common problem probably means there is, perhaps, a library issue. I shouild point out that I have built from sources and have exactly the same problem. For what it's worth, I have exactly the same problem in fedora core 5, but not on Fedora Corre 4. Art Edwards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Broken applications: Could we be honest?
I have been writing to the list about two applications that are so broken on the AMD64 distribution that they render the box pretty useless. I'm sure one could say that two measly applications are no big deal. However, if you do scientific computation for a living, and two of the primary tools are broken, you now have a rather clumsy paperweight where a computer should be. You could argue that we should simply learn new tools, and we could, but we should really be doing science instead. This brought up the question, who uses 64 bit Linux anyway? Surely gamers do not drive the 64-bit linux community. It can't be the desktop community, seeing that the standard office tool doesn't really work for 64-bit. I would think that scientific and engineering users would drive this community. Besides the instruction set, which can probably give some speed, but wouldn't justify the cost, the address space in 64-bit OS's mean that we can solve much larger problems. Unles you're not doing some heavy-duty, memory-intensive computation, 64-bits seems to be simply a status symbol. For compute servers the amd64 distribution is fine. All you really need are languages (compilers), libraries and decent MPICH. We run our small, 32 bit Beowulf on debian with abandon, and from my experience, I look forward to converting it to amd64 ... with a 32-bit node where things actually work. Unless such core pieces as the debugging tool (ddd) and the data display tool (xmgrace) are working, it is dishonest to pretend that the 64-bit version is ready for testing. It would be very nice if you, and other distro's, were to put appropriate caveats on the websites, saying that 64-bit is really not ready for the prime-time desktop. That way, we could make better purchasing decisions. Art Edwards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
Thanks for your response. We have the pgi compiler on the head node of a very old, 32-bit beowulf. I do my production calculations on a very nice large, 64-bit cluster at a national laboratory, but my desktop machine had, until about 6 weeks ago, been a 1.4 GHz 32-bit machine. The graphics had become hopelessly bogged down. So, ironically, our main internal compute engine is 32-bit and my desktop is 64. Go figure. I'm using my laptop for most code development and for making xmgrace figures for publication. Art Edwards On Sat, Jul 08, 2006 at 05:40:37PM +0100, Jimmy Tang wrote: > On 7/8/06, Art Edwards <[EMAIL PROTECTED]> wrote: > > > >I have been writing to the list about two applications that > >are so broken on the AMD64 distribution that they render the > >box pretty useless. I'm sure one could say that two measly > >applications are no big deal. However, if you do scientific computation > >for a living, and two of the primary tools are broken, you now have > >a rather clumsy paperweight where a computer should be. You could > >argue that we should simply learn new tools, and we could, but we > >should really be doing science instead. > > > >This brought up the question, who uses 64 bit Linux anyway? > >Surely gamers do not drive the 64-bit linux community. It can't be the > >desktop > >community, seeing that the standard office tool doesn't really > >work for 64-bit. I would think that scientific and engineering > >users would drive this community. Besides the instruction set, which > >can probably give some speed, but wouldn't justify the cost, the address > >space in 64-bit OS's mean that we can solve much larger problems. Unles > >you're > >not doing some heavy-duty, memory-intensive computation, 64-bits seems > >to be simply a status symbol. > > > >For compute servers the amd64 distribution is fine. All you really need > >are > >languages (compilers), libraries and decent MPICH. We run our small, 32 > >bit > >Beowulf on debian with abandon, and from my experience, I look forward to > >converting it to amd64 ... with a 32-bit node where things actually work. > > > >Unless such core pieces as the debugging tool (ddd) and the data display > >tool > >(xmgrace) are working, it is dishonest to pretend that the 64-bit version > >is ready for testing. It would be very nice if you, and other distro's, > >were > >to put appropriate caveats on the websites, saying that 64-bit is really > >not > >ready for the prime-time desktop. That way, we could make better > >purchasing > >decisions. > > > > > > > At the risk of imposing what we do at our work place onto your work flow, i > find that users generally should have access to better debuggers/profilers > than what ships with standard gnu distros. presumably if you are doing > scientific computations, you probably have access to a commercial compiler? > i know that the portland group compilers ship with a fairly good gui > debugger if you are not satisfied with gdb (in parallel attached to each > running process) > > also shouldnt users be using programs like xmgrace on their local > workstations? again with out trying to impose my workflow to yours, i find > sometimes users do silly things on the head node on clusters, and I tend to > try and get my users to do post analysis etc... stuff that can run serially > on their own desktops whenever possible. > > Jim > > > > -- > Jimmy Tang > Trinity Centre for High Performance Computing, > Lloyd Building, Trinity College Dublin. > http://www.tchpc.tcd.ie/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
Excuse me for chiming in, but I think many places simply look for the best performance and productivity/dollar(euro). We do use the PGI compiler, mostly because gnu had not had a f90-f95 compiler, and partly because of, maybe, a 10% improvement in speed. What I find interesting is that both Fedora and Debian have similar problems for different reasons. Debian has now stable release for AMD64 because Sarge was released before AMD64 was really ready. This means that we are all stuck in the beta test-site pool. It would be really nice if Debian actually packaged up a "stable-like" version of AMD64 at the same level as Sarge. Fedora has been moving so quickly, that they have incorporated the same problems into a nominally stable release. On Sat, Jul 08, 2006 at 07:28:21PM +0200, Oliver Rother wrote: > Jimmy Tang wrote: > > >At the risk of imposing what we do at our work place onto your work > >flow, i find that users generally should have access to better > >debuggers/profilers than what ships with standard gnu distros. > > Well, if you intend to start a flame war on the lists... but enough on that. > > >presumably if you are doing scientific computations, you probably have > >access to a commercial compiler? > > Oh, we do. Consider an project with a timeline of many years or even > decades of years. would you choose a non onepn source (commercial) > compiler/debugger for that project? I'm pretty sure, you won't. > > >also shouldnt users be using programs like xmgrace > > Talking about commerical applications from your point of view - why use > free software for data analysis when powerful commercial packages like > IDL are available? > > Olli > > -- > Oliver Rother, Department of Space Physics, > University of Kiel, Leibnizstr. 11/505a, D-24118 Kiel > phone: +49 (0)431 880 4802, fax: +49 (0)431 880 3968 > [EMAIL PROTECTED] www.ieap.uni-kiel.de/et -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
The point is that they do not work exactly fine. For ddd, the console at the bottom is dead. The keyboard fails. For grace(xmgrace) the same symptom is present in all text boxes. This appears to be a pretty general problem because the same is true for Fedora Core 5, but not for Fedora Core 4. I have compiled xmgrace from sources and I have the same problem. I have done some looking and this problem surfaced several years ago on a cygwin list. Just for the record, when I invoke xmgrace from the command line, I receive many errors like this: Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfHelp I get exactly the same set from ddd. Again, this is true for AMD64 for both Debian and for Fedora Core 5. Art Edwards On Sat, Jul 08, 2006 at 07:02:24PM +0200, Oliver Rother wrote: > Art Edwards wrote: > > >Unless such core pieces as the debugging tool (ddd) and the data display > >tool > >(xmgrace) are working, it is dishonest to pretend that the 64-bit version > >is ready for testing. > > ddd and grace are in Debian testing (etch) amd64 and work fine. So where > exactly is the issue? > > We use an mixture of testing and unstable here with the following > priority setting /etc/apt/preferences: > > Package: * > Pin: release a=testing > Pin-Priority: -1 > Package: * > Pin: release a=unstable > Pin-Priority: -2 > > So, if a package is still brocken in testing (as parts of gnome at least > at box installation time), we take it from unstable with > > apt-get install PACKAGE -t unstable, > > including its dependencies. > > So far, we observerd no major issues. > > -- > Oliver Rother, Department of Space Physics, > University of Kiel, Leibnizstr. 11/505a, D-24118 Kiel > phone: +49 (0)431 880 4802, fax: +49 (0)431 880 3968 > [EMAIL PROTECTED] www.ieap.uni-kiel.de/et -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
Thanks very much. See below. On Wed, Jul 12, 2006 at 02:54:14PM -0500, Ozzy Lash wrote: > On 7/12/06, Art Edwards <[EMAIL PROTECTED]> wrote: > >The point is that they do not work exactly fine. For ddd, the console at > >the bottom is dead. > >The keyboard fails. For grace(xmgrace) the same symptom is present in all > >text boxes. This appears to be a pretty general problem because the same > >is true for > >Fedora Core 5, but not for Fedora Core 4. I have compiled xmgrace from > >sources and > >I have the same problem. I have done some looking and this problem surfaced > >several years ago on a cygwin list. > >Just for the record, when I invoke xmgrace from the command line, I > >receive many errors like this: > > > >Warning: String to TranslationTable conversion encountered errors > >Warning: translation table syntax error: Unknown keysym name: osfHelp > > > >I get exactly the same set from ddd. Again, this is true for AMD64 for > >both Debian and for Fedora Core 5. > > > > > >Art Edwards > > I did a google search for "Warning: String to TranslationTable > conversion encountered errors" and found this link: > > http://www.ubuntuforums.org/showthread.php?t=82087 > > With the following suggestion: > The answer is: > > export XKEYSYMDB=/usr/share/X11/XKeysymDB This was, indeed, the problem. It arose because my .cshrc file pointed to an older place (/usr/X11R6/lib/X11/XKeysymDB). Again, thanks. Art Edwards > > > This is also needed to get the grace package to work right on Breezy, BTW. > > > Hope this helps > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
I posted the same initial message on the three sites I thought were appropriate. My plea for honesty was a measure of frustration with what should be well-established packages. It turns out that in the newer distros, the structure of /usr/X11R6 has changed dramatically enough that it broke a .cshrc file that had worked for five years. Art Edwards On Wed, Jul 12, 2006 at 10:18:40PM +0200, Thierry Chatelet wrote: > Ozzy Lash wrote: > >On 7/12/06, Art Edwards <[EMAIL PROTECTED]> wrote: > >>The point is that they do not work exactly fine. For ddd, the console > >>at the bottom is dead. > >>The keyboard fails. For grace(xmgrace) the same symptom is present in > >>all > >>text boxes. This appears to be a pretty general problem because the > >>same is true for > >>Fedora Core 5, but not for Fedora Core 4. I have compiled xmgrace > >>from sources and > >>I have the same problem. I have done some looking and this problem > >>surfaced > >>several years ago on a cygwin list. > >>Just for the record, when I invoke xmgrace from the command line, I > >>receive many errors like this: > >> > >>Warning: String to TranslationTable conversion encountered errors > >>Warning: translation table syntax error: Unknown keysym name: osfHelp > >> > >>I get exactly the same set from ddd. Again, this is true for AMD64 > >>for both Debian and for Fedora Core 5. > >> > >> > >>Art Edwards > > > >I did a google search for "Warning: String to TranslationTable > >conversion encountered errors" and found this link: > > > >http://www.ubuntuforums.org/showthread.php?t=82087 > > > >With the following suggestion: > >The answer is: > > > >export XKEYSYMDB=/usr/share/X11/XKeysymDB > > > > > >This is also needed to get the grace package to work right on Breezy, > >BTW. > > > > > >Hope this helps > > > > > What is that honesty things invading all news group from Debian? > Please answer only to the list the mail is originating. On top, I am > wondering why we have so many ' tell the truth mail lately. > Thierry > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
System sees only 65M of memory
I just purchased two Athalon-based systems, each with 768M of ram. However, under debian (potato runnin kernel 2.2.17) the OS sees only 65 M of memory. I have tried to use the append command mem=768M but it still sees only 65 M? Does anyone have any ideas? -- Arthur H. Edwards 712 Valencia Dr. NE Abq. NM 87108 (505) 256-0834 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Fwd: Exim and DSL]
-- Arthur H. Edwards 712 Valencia Dr. NE Abq. NM 87108 (505) 256-0834--- Begin Message --- I'm haveing some difficulty getting my network to accept mail messages. I'm using exim through a cicso router. I have forwarded port 25 to my mail machine. I am able to send mail to anyone. And I can receive mail from the local machines. When I try to send mail to my machine from another, I get nothing. I attach a typical dialog with exim when I use the -d9 switch to maximize debugging messages. lcws/home/edwards> exim -d9 [EMAIL PROTECTED] Exim version 3.12 debug level 9 uid=225 gid=231 probably Berkeley DB version 1.8x (native mode) lcws.ahpcc.unm.edu in local_domains? yes (matched lcws.ahpcc.unm.edu) Actual local interface address is 127.0.0.1 Actual local interface address is 129.24.244.32 user name "Arthur H. Edwards" extracted from gecos field "Arthur H. Edwards" sender address = [EMAIL PROTECTED] set_process_info: 14099 3.12 accepting a local non-SMTP message from <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] Recipients: [EMAIL PROTECTED] search_tidyup called Subject:Test This is a test. >>Original headers (size=28): Subject:Test This is a test. [EMAIL PROTECTED] in [EMAIL PROTECTED] no (end of list) rewritten sender = [EMAIL PROTECTED] search_tidyup called >>Final headers: P Received: from edwards by lcws.ahpcc.unm.edu with local (Exim 3.12 #1 (Debia ) id 14BfVB-0003fP-00 for <[EMAIL PROTECTED]>; Thu, 28 Dec 2000 09:02:13 - 00 Subject:Test I Message-Id: <[EMAIL PROTECTED]> F From: "Arthur H. Edwards" <[EMAIL PROTECTED]> T To: [EMAIL PROTECTED] Date: Thu, 28 Dec 2000 09:02:13 -0700 This is a test. Data file written for message 14BfVB-0003fP-00 Writing spool header file Size of headers = 369 LOG: 0 MAIN <= [EMAIL PROTECTED] U=edwards P=local S=386 exec /usr/sbin/exim -d9 -Mc 14BfVB-0003fP-00 lcws/home/edwards> Exim version 3.12 debug level 9 uid=8 gid=8 probably Berkeley DB version 1.8x (native mode) lcws.ahpcc.unm.edu in local_domains? yes (matched lcws.ahpcc.unm.edu) Actual local interface address is 127.0.0.1 Actual local interface address is 129.24.244.32 Caller is an admin user Caller is a trusted user set_process_info: 14100 3.12 delivering specified messages delivering message 14BfVB-0003fP-00 set_process_info: 14100 3.12 delivering 14BfVB-0003fP-00 Opened spool file 14BfVB-0003fP-00-H user=edwards uid=225 gid=231 [EMAIL PROTECTED] sender_local=1 resent=no ident=edwards Non-recipients: Empty Tree End of tree recipients_count=1 body_linecount=1 message_linecount=8 Delivery address list: [EMAIL PROTECTED] locked /var/spool/exim/db/retry.lockfile opened DB file /var/spool/exim/db/retry: flags=0 Considering: [EMAIL PROTECTED] icantbelieveimdoingthis.com in local_domains? no (end of list) unique = [EMAIL PROTECTED] dbfn_read: key=R:icantbelieveimdoingthis.com dbfn_read: key=R:[EMAIL PROTECTED] [EMAIL PROTECTED]: queued for routing After directing: Local addresses: Remote addresses: Failed addresses: Addresses to be routed: [EMAIL PROTECTED] Deferred addresses: routing [EMAIL PROTECTED], domain icantbelieveimdoingthis.co lookuphost router called for [EMAIL PROTECTED] dns lookup: route_domain = icantbelieveimdoingthis.com DNS lookup of icantbelieveimdoingthis.com (MX) succeeded DNS lookup of mail.thuntek.net () succeeded DNS lookup of mail2.thuntek.net () gave NO_DATA DNS lookup of mail.thuntek.net (A) succeeded Actual local interface address is 127.0.0.1 Actual local interface address is 129.24.244.32 fully qualified name = icantbelieveimdoingthis.com host_find_bydns yield = HOST_FOUND (2); returned hosts: buckhill.icantbelieveimdoingthis.com 206.206.97.132 10 1031 mail2.thuntek.net 206.206.98.15 20 2091 queued for remote_smtp transport: local_part=edwards domain=icantbelieveimdoin his.com routed by lookuphost router: deliver to [EMAIL PROTECTED] transport: remote_smtp host buckhill.icantbelieveimdoingthis.com [206.206.97.132] MX=10 host mail2.thuntek.net [206.206.98.15] MX=20 search_tidyup called >> Remote deliveries >> remote_smtp transport entered [EMAIL PROTECTED] icantbelieveimdoingthis.com in queue_smtp_domains? no (end of list) checking status of buckhill.icantbelieveimdoingthis.com locked /var/spool/exim/db/retry.lockfile opened DB file /var/spool/exim/db/retry: flags=0 dbfn_read: key=T:mail2.thuntek.net:206.206.98.15 dbfn_read: key=T:mail2.thuntek.net:206.206.98.15:14BfVB-0003fP-00 no host retry record no message retry record mail2.thuntek.net [206.206.98.15] status = usable host in ? no (option unset) delivering 14BfVB-0003fP-00 to mail2.thuntek.net [206.206.98.15] ([EMAIL PROTECTED] elieveimdoingthis.com) set_process_info: 14100 3.12 delivering 14BfVB-0003fP-00 to mail2.thuntek.net 06.206.98.15] ([EMAIL PROTECTED]) Connecting to mail2.thuntek.net [206.206.98.15] ... connected SMTP<< 220 mail2.thuntek.net ESMTP Sendmail 8.11.1/
kile
In testing, kile has been removed. It appears that texlive is undergoing a reorganization. As a result, kile's dependencies are at odds with the new organization. When will kile be returned to the distribution? -- Arthur H. Edwards Senior Research Physicist Air Force Research Laboratory AFRL/VSSE Bldg. 914 3550 Aberdeen Ave. SE KAFB, NM 87117-5776 (505) 853-6042 (O) (505) 463-6722 (C) (505) 846-2290 (F) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kile
This is a courtesy rejoinder: Today kile installed without problem. Last time I think that texlive was not completely loaded into testing. Art Edwards Steve Langasek wrote: On Tue, Jul 03, 2007 at 03:06:36PM -0600, Art Edwards wrote: In testing, kile has been removed. That doesn't appear to be the case. It appears that texlive is undergoing a reorganization. As a result, kile's dependencies are at odds with the new organization. I don't see this in any version of kile in etch/lenny/sid. -- Arthur H. Edwards Senior Research Physicist Air Force Research Laboratory AFRL/VSSE Bldg. 914 3550 Aberdeen Ave. SE KAFB, NM 87117-5776 (505) 853-6042 (O) (505) 463-6722 (C) (505) 846-2290 (F) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
