tkinter-2.3.4-14.4.el4_6.1.i386.rpm
Hi, I have trying to install gLite3.1 on my SL4.5 and it complains that tkinter is not found. Browsing at the link I can see it is not there. What should I do? What other mirror can I use? Downloaded from somwhere and just do a yum localinstall These are the steps I followed: yum install glite-UI Everything is fine until it gets to this step Downloading header for tkinter to pack into transaction set. http://ftp.scientificlinux.org/linux/scientific/4x/i386/errata/SL/RPMS/tkinter-2.3.4-14.4.el4_6.1.i386.rpm: [Errno 4] IOError: HTTP Error 404: Not Found Trying other mirror. ftp://ftp.scientificlinux.org/linux/scientific/4x/i386/errata/SL/RPMS/tkinter-2.3.4-14.4.el4_6.1.i386.rpm: [Errno 4] IOError: HTTP Error 404: Not Found Trying other mirror. Error: failure: tkinter-2.3.4-14.4.el4_6.1.i386.rpm from sl-errata: [Errno 256] No more mirrors to try. If I do yum info tkinter Loading "kernel-module" plugin Setting up repositories Reading repository metadata in from local files Available Packages Name : tkinter Arch : i386 Version: 2.3.4 Release: 14.4.el4_6.1 Size : 271 k Repo : sl-errata Summary: A graphical user interface for the Python scripting language. Description: So it expects it under sl-errata. Can I change that? Thanks for your help, Aldo -- -- Aldo F. Saavedra Phone: +61 (0) 2 9351 5970 Fax : +61 (0) 2 9351 7726 Email: [EMAIL PROTECTED] Mail : High Energy Physics School of Physics A28 University of Sydney NSW 2006 Sydney, Australia
RE: fsck.ext3 on large file systems?
On Thu, 27 Mar 2008, Bly, MJ (Martin) wrote: On our hardware RAID arrays (3ware, Areca, Infortrend) with many (12/14) SATA disks, 500/750GB each, we fsck 2TB+ ext3 filesystems (as infrequently as possible!) and it takes ~2 hours each. We have some 5.5TB arrays that take less than three hours. Note that these are created with '-T largefile4 -O dir_index' among other options. At least one pass of the ext3 fsck involves checking every inode table entry so '-T largefile4' would help you since you will get smaller numbers of inodes. As the inode tables are spread through the disk it will read the various chunks then seek off somewhere and read more... [ one of the planned features for ext4 is a way to safely mark than an entire inode-table lump is unused to save things like fsck from having to scan all those unusd blocks. Of course doing so safely isn't quite trivial and it causes problems with the current model of how to choose the locations for an inode for a new file... ] I'd be very suspicious of a HW RAID controller that took 'days' to fsck a file system unless the filesystem was already in serious trouble, and from bitter experience, fsck on a filesystem with holes it it caused by a bad raid controller interconnect (SCSI!) can do more damage than good. To give you one example at least one fsck pass needs to check that every inode in use has the right (link-count) number of directory entries pointing at it. The current ext3 fsck seems to do a good impersonation of a linear search though it's in-memory inode-state-table for each directory entry - at least for files with non-trivial link-counts. A trivial analysis shows that such a set of checks would be O(n^2) in the number of files needing to be checked, not counting the performance problems when the 'in-memory' tables get too big for ram... [ In case I'm slandering the ext3 fsck people - I've not actually checked the ext3 fsck code really does anything as simple as a linear search but anything more complex will need to use more memory and ... ] Last year we were trying to fsck a ~6.8TB ext3 fs which was about 70% filled with hundereds of hard-link trees of home directories. So huge numbers of inode entries (many/most files are small), and having a link-counts of say 150. Our poor server had only 8G ram and the ext3 fsck wanted rather a lot more. Obviously in such a case it will be *slow*. Of course that was after we built a version which didn't simply go into an infinite loop somewhere between 3 and 4TB into scanning through the inode-table. Now as you can guess any dump needs to do much the same kind of work wrt scanning the inodes, looking for hard-links, so you may not be shocked to discover that attempting a backup was rather slow too... -- Jon Peatfield, Computer Officer, DAMTP, University of Cambridge Mail: [EMAIL PROTECTED] Web: http://www.damtp.cam.ac.uk/
Re: fsck.ext3 on large file systems?
On Thu, Mar 27, 2008 at 4:40 PM, Michael Hannon <[EMAIL PROTECTED]> wrote: > On Thu, Mar 27, 2008 at 05:06:53PM +0100, [EMAIL PROTECTED] wrote: > > On Thu, 27 Mar 2008, Stephen John Smoogen wrote: > . > . > > . > > Hmm, we successfully fsck'd ext3 filesystems 1.4 TB in size frequently a > > couple of years ago, under 2.4 (back then, it was SuSE 8.2 + a vanilla > > kernel). This took no more than a few hours (maybe 2,3, or 4). It was > > hardware RAID, not too reliable (hence "frequently"), and not too fast (< > > 100 MB/s). A contemporary linux server with software RAID should complete > > an fsck *much* faster, or something is wrong. > > Hi, Stephan. Yea, I think I must be doing something wrong here, but I > haven't been able to figure out what it is. > Well this could be a hardware error on the wire (bad scsi wire etc). It could also depend on how the data is laid out on the disk. The long fsck's were tons of directories and files.. and they were read, deleted, etc in random order (eg INN news). but then again it could be that I had crap hardware then too :). > > > And I still wonder why fsck at at all just because a broken disk was > > replaced in a redundant array? > > The system seems to insist on it. Again, there may be some cockpit > error involved. > Usually it will require an fsck if the disk did not shutdown clearly or some other issue it is detecting. I would need to know more about the hardware in place (controller, number of drives, type of drives, how many spares etc) to make a more educated guess. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"
Re: fsck.ext3 on large file systems?
On Thu, Mar 27, 2008 at 05:06:53PM +0100, [EMAIL PROTECTED] wrote: > On Thu, 27 Mar 2008, Stephen John Smoogen wrote: . . . > Hmm, we successfully fsck'd ext3 filesystems 1.4 TB in size frequently a > couple of years ago, under 2.4 (back then, it was SuSE 8.2 + a vanilla > kernel). This took no more than a few hours (maybe 2,3, or 4). It was > hardware RAID, not too reliable (hence "frequently"), and not too fast (< > 100 MB/s). A contemporary linux server with software RAID should complete > an fsck *much* faster, or something is wrong. Hi, Stephan. Yea, I think I must be doing something wrong here, but I haven't been able to figure out what it is. > And I still wonder why fsck at at all just because a broken disk was > replaced in a redundant array? The system seems to insist on it. Again, there may be some cockpit error involved. Thanks. - Mike -- Michael Hannonmailto:[EMAIL PROTECTED] Dept. of Physics 530.752.4966 University of California 530.752.4717 FAX Davis, CA 95616-8677
Re: fsck.ext3 on large file systems?
On Thu, Mar 27, 2008 at 06:56:17AM -0600, Stephen John Smoogen wrote: > On Wed, Mar 26, 2008 at 7:34 PM, Michael Hannon <[EMAIL PROTECTED]> wrote: > > Greetings. We have a lately had a lot of trouble with relatively large > > (order of 1TB) file systems mounted on RAID 5 or RAID 6 volumes. The > > file systems in question are based on ext3. . . . > > After the RAID array has completed its rebuild, we run fsck on the RAID > > device. When we do that, fsck seems to run forever, i.e., for days at a > > time, occasionally spitting out messages about files with recognizable > > names, but never completing satisfactorily. > > > > fsck of 1TB is going to take days due to the linear nature of it > checking the disk. [ I think the disks for mirrors.kernel.org take > many weeks to fsck.] The bigger question is what kind of data are you > writing to these disks, and is the ext3 journal large enough for those > writes? > > > > The systems in question are typically running SL 4.x. We've read that > > the version of fsck that is standard in SL 4 has some known bugs, > > especially wrt large file systems. > > > > Hence, we've attempted to repeat the exercise with fsck.ext3 taken from > > the Fedora 8 distribution. This gives us improved, but still not > > satisfactory, results. > > > > Did you recompile the binary from source, or did you use it straight? > I am just wondering if fsck is dependant on some kernel particulars... We just used the binary straight. Thanks, Stephen. - Mike -- Michael Hannonmailto:[EMAIL PROTECTED] Dept. of Physics 530.752.4966 University of California 530.752.4717 FAX Davis, CA 95616-8677
emacs versions in SL5.1
http://ftp.scientificlinux.org/linux/scientific/51/x86_64/SL/ has
emacs-21.4-18.1.el5.x86_64.rpm
but http://ftp.scientificlinux.org/linux/scientific/51/i386/SL/ has
emacs-21.4-20.el5.i386.rpm
... so x86_64 has an earlier emacs than i386
http://ftp.scientificlinux.org/linux/scientific/51/SRPMS/vendor/ has
emacs-21.4-18.1.el5.src.rpm
Should I be looking for emacs-21.4-20.el5.{src,x86_64}.rpm somewhere
else ?
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna
RE: fsck.ext3 on large file systems?
In-line... > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: 27 March 2008 16:07 > To: [EMAIL PROTECTED] > Subject: Re: fsck.ext3 on large file systems? > > On Thu, 27 Mar 2008, Stephen John Smoogen wrote: > > > On Wed, Mar 26, 2008 at 7:34 PM, Michael Hannon > <[EMAIL PROTECTED]> wrote: > >> Greetings. We have a lately had a lot of trouble with > relatively large > >> (order of 1TB) file systems mounted on RAID 5 or RAID 6 > volumes. The > >> file systems in question are based on ext3. > >> > >> In a typical scenario, we have a drive go bad in a RAID > array. We then > >> remove it from the array, if it isn't already, add a new > hard drive > >> (i.e., by hand, not from a hot spare), and add it back to the RAID > >> array. The RAID operations are all done using mdadm. This is of course a software RAID... > >> After the RAID array has completed its rebuild, we run > fsck on the RAID > >> device. When we do that, fsck seems to run forever, > i.e., for days at a > >> time, occasionally spitting out messages about files with > recognizable > >> names, but never completing satisfactorily. > >> > > > > fsck of 1TB is going to take days due to the linear nature of it > > Hmm, we successfully fsck'd ext3 filesystems 1.4 TB in size > frequently a > couple of years ago, under 2.4 (back then, it was SuSE 8.2 + > a vanilla > kernel). This took no more than a few hours (maybe 2,3, or > 4). It was > hardware RAID, not too reliable (hence "frequently"), and not > too fast (< > 100 MB/s). A contemporary linux server with software RAID > should complete > an fsck *much* faster, or something is wrong. On our hardware RAID arrays (3ware, Areca, Infortrend) with many (12/14) SATA disks, 500/750GB each, we fsck 2TB+ ext3 filesystems (as infrequently as possible!) and it takes ~2 hours each. We have some 5.5TB arrays that take less than three hours. Note that these are created with '-T largefile4 -O dir_index' among other options. I'd be very suspicious of a HW RAID controller that took 'days' to fsck a file system unless the filesystem was already in serious trouble, and from bitter experience, fsck on a filesystem with holes it it caused by a bad raid controller interconnect (SCSI!) can do more damage than good. Maybe the controller has some missconfiguration. Not so sure about software raid setups though. But if you have a lot of disks on a single controller chip, say driving 4 SATA disks, you *might* max out the PCI(-e/X) bandwidth to the controller chip. One thing that will kill you though - if you have a lot of remapped blocks on your device, that can slow things down considerably. The device may be OK but performance would suck. Another thing that some harwdare RAID controllers do is turn off the device cache in some circumstances - that bit us a while back and made a controller crawl (BBU failed, controller went into 'safe' mode). > And I still wonder why fsck at at all just because a broken disk was > replaced in a redundant array? Yes - should not be necessary, but I've done it for super-critical (small) systems 'just in case' due to paranoid user groups. > -- > Stephan Wiesand >DESY - DV - >Platanenallee 6 >15738 Zeuthen, Germany Martin. -- Martin Bly RAL Tier1 Fabric Team
Re: Firefox crash on SL5
On 26/03/08 15:39, Faye Gibbins wrote: Hi, Lots of our users are having trouble when using firefox with SL5 with the NVidia drivers (both legacy and newer ones). Running firefox using /usr/bin/firefox --sync --no-xshm this error message was reported after mine crashed and disappeared from the desktop: snip--- [EMAIL PROTECTED] ~ $ firefox [NoScript] [NoScript] browserDOMWindow wrapped for external load interception [NoScript] [NoScript] browserDOMWindow wrapped for external load interception [NoScript] [NoScript] browserDOMWindow wrapped for external load interception [NoScript] [NoScript] browserDOMWindow wrapped for external load interception [NoScript] Component returned failure code: 0x80570009 (NS_ERROR_XPC_BAD_CONVERT _JS) [nsIXPCComponents_Utils.lookupMethod] while showing NOSCRIPT element [NoScript] Component returned failure code: 0x80570009 (NS_ERROR_XPC_BAD_CONVERT _JS) [nsIXPCComponents_Utils.lookupMethod] while showing NOSCRIPT element The program 'Gecko' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 22989464 error_code 1 request_code 0 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [EMAIL PROTECTED] ~ $ snip--- has anyone seen this before/know how to fix it? Haven't seen this myself. But the above would lead me to suspect a bug in the "NoScript" extension. If you can reproduce this at will, perhaps you could try first without NoScript, then retry with the latest&greatest (unless you have that already), then install the firefox-debuginfo RPM (matching your firefox RPM version+architecture), then run the bove under gdb (you will need to set up the environment for firefox to find its libraries, have a look at /usr/bin/firefox). This at least should provide a helpful backtrace, which might allow the NoScript people to guess where the problem is. "request_code 0" indeed does not exist. This would look more like a bug in Firefox, it should not be making such a bogus request. You could see whether using the "vesa" X11 driver makes the problem go away, this would allow to take the proprietary NVidia drives out of the issue... On the other hand, have a look at the changes proposed at the end of http://www.nvnews.net/vbulletin/archive/index.php/t-96192.html Regards jan
SL5 and nx
I use nx/nxclient connecting SL4 and SL5 nx servers to windows XP clients (nxclient) and to other linux PCs.To avoid the license restrsictions on the www.nomachine.com freeware versions, (2 connections per server), I've used freenx and an earlier www.nomachine.com release (nxclient-1.5.0-141.i386.rpm). This continues to work very well with SL4. On SL5, gnome never played well with nx due to applet issues that I chose not to delve into. Kde worked fine, so one could connect to SL5 via kde using nx and all is well - until recently. Recently on SL5 (there must have been an update of a kde package?), keystrokes are not recognized when connecting with nx from linux or windows XP to the SL5 nxserver. If I hit a screen saver button (Print Scrn?) that will bring up a screen saver window during the SL5 nx session, but otherwise no keystrokes show in terminals. Very unsatisfying. I did try updating the kernel from 2.6.18-8.1.15.el5 to 2.6.18-53.1.14.el5 and I updated nx and freenx via yum (atrpms). No change. I figure I'm on my own on this as I reallly should be using the latest freeware from www.nomachine.com (and accepting their 2 connection limitation). Nevertheless, my questionss are: 1) Is there a simple keystroke behavior fix that I have missed? 2) I suspect it has to be yum updates that changed kde behavior. As I don't have an exact day for when the nx keystroke misbehavior started, I'm not fully certain what software package triggered this, plus I don't see any recent kde updates when I take a look via yumex (ages list). My best guess is that thie keystroke misbehavior started within the last month. Bill Lutter To compare SL4 and SL5 nx so you see how old these packages are that still work... SL4.0 nx-1.5.0-0.FC4.1.i686 nxclient-1.5.0-141.i386 freenx-0.4.4-1.fdr.0.noarch SL4.1 nx-1.5.0-4.FC4.1.i686 freenx-0.4.4-2.fdr.0.noarch SL5 freenx-0.7.1-5.el5.i386 nx-2.1.0-22.el5.i386 nxclient-1.5.0-141.i386
Re: fsck.ext3 on large file systems?
On Thu, 27 Mar 2008, Stephen John Smoogen wrote: On Wed, Mar 26, 2008 at 7:34 PM, Michael Hannon <[EMAIL PROTECTED]> wrote: Greetings. We have a lately had a lot of trouble with relatively large (order of 1TB) file systems mounted on RAID 5 or RAID 6 volumes. The file systems in question are based on ext3. In a typical scenario, we have a drive go bad in a RAID array. We then remove it from the array, if it isn't already, add a new hard drive (i.e., by hand, not from a hot spare), and add it back to the RAID array. The RAID operations are all done using mdadm. After the RAID array has completed its rebuild, we run fsck on the RAID device. When we do that, fsck seems to run forever, i.e., for days at a time, occasionally spitting out messages about files with recognizable names, but never completing satisfactorily. fsck of 1TB is going to take days due to the linear nature of it Hmm, we successfully fsck'd ext3 filesystems 1.4 TB in size frequently a couple of years ago, under 2.4 (back then, it was SuSE 8.2 + a vanilla kernel). This took no more than a few hours (maybe 2,3, or 4). It was hardware RAID, not too reliable (hence "frequently"), and not too fast (< 100 MB/s). A contemporary linux server with software RAID should complete an fsck *much* faster, or something is wrong. And I still wonder why fsck at at all just because a broken disk was replaced in a redundant array? -- Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany
Re: Problems with 4.5 TB disk array (LVM & ext3)
[EMAIL PROTECTED] wrote: We're successfully using devices up to 7 TB with a single XFS filesystem on them, under SL4/5 (but I think we started doing this with 4.3, not 4.2). I have no hope to be able to check (xfs_repair) those should this ever become necessary though - from what I've read it would require more RAM than fits into a server today. On this year's linux.conf.au, there was a talk about fixing the fsck.xfs [1]. They claim that they reduce both memory usage and required time. [1] http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf Cheers, -jkt smime.p7s Description: S/MIME Cryptographic Signature
Re: Problems with 4.5 TB disk array (LVM & ext3)
On Wed, 26 Mar 2008, Jon Peatfield wrote: On Wed, 26 Mar 2008, Jan Schulze wrote: Hi all, I have a disk array with about 4.5 TB and would like to use it as one large logical volume with an ext3 file system. When mounting the logical volume , I get an "Input/Output error: can't read superblock". Do you get any interesting kernel messages in the output of dmesg (or /var/log/messages etc)? Which exact kernel is this (uname -r) and what arch (i386/x86_64 etc; uname -m)? And what driver/hardware? I'm using SL 4.2 with kernel 2.6 and this is what I did so far: - used parted to create a gpt disk label (mklabel gpt) and one large partition (mkpart primary ext3 0s -1s) - used parted to enable LVM flag on device (set 1 LVM on) I know it would be slow but can you test that you can read/write to all of /dev/sda1? Using dd's "seek" parameter, this should not take too much time. But if creating the GPT label & partition was successful, chances are the whole device is accessible. - created one physical volume, one volume group and one logical volume (pvcreate /dev/sda1, vgcreate raid6 /dev/sda1, lvcreate -l 1189706 -n vol1 raid6) - created an ext3 filesystem and explicitly specified a 4K blocksize, as this should allow a filesystem size of up to 16 TB (mkfs.ext3 -m 0 -b 4096 /dev/raid6/vol1) For some reason my EL4 notes tell me that we also specify -N (number of inodes), as well as -E (set RAID stride), -J size= (set journal size) and -O sparse_super,dir_index,filetype though most of that is probably the default these days... Specifying the stripe width is also supposed to be a good idea, as is aligning the start of the partition to a stripe boundary (although that's more likely to be useful without LVM on top). However, mounting (mount /dev/raid6/vol1 /raid) gives the superblock error, mentioned above. Everything is working as expected, when using ext2 filesystem (with LVM) or ext3 filesystem (without LVM). Using a smaller volume (< 2 TB) is working with ext3+LVM as well. Only the combination of > 2TB+ext3+LVM gives me trouble. Any ideas or suggestions? We found that in at least some combinations of kernel/hardware (drivers really I expect), that support for >2TB block devices was still rather flakey (at least in the early versions of EL4). We ended up getting our RAID boxes to present as multiple LUNs each under 2TB which we can then set up as PVs and join back together into a single VG and still have an LV which was bigger than 2TB. I'm rather conservative in such things so we still avoid big block devices at the moment. [ obviously with single disk sizes growing at the rate they are it means that the block-devices >2TB code is going to get a LOT more testing! ] We're successfully using devices up to 7 TB with a single XFS filesystem on them, under SL4/5 (but I think we started doing this with 4.3, not 4.2). I have no hope to be able to check (xfs_repair) those should this ever become necessary though - from what I've read it would require more RAM than fits into a server today. However, some of the tools (e.g. ext2/3 fsck) still seemed to fail at about 3.5TB so we ended up needing to build the 'very latest' tools to be able to run fsck properly (the ones included in EL4 - and EL5 I think - get into an infinite loop at some point while scanning the inode tables). Currently we try to avoid 'big' ext3 LVs ; the one where we discovered the fsck problems was originally ~6.8TB but we ended up splitting that into several smaller LVs since even with working tools it still took ~2 days to fsck... (and longer to dump/copy/restore it all!) Some of my co-workers swear by XFS for 'big' volumes but then we do have SGI boxes where XFS (well CXFS) is the expected default fs. I've not done much testing with XFS on SL mainly because TUV don't like XFS much... I think it's still the best choice for large (> 2 TB) filesystems. The xfs available in SL4 contrib has done very well here. There are some interesting effects when such a filesystem runs full and you have to remount it with the "inode64" option in order to be able to create new files and you discover that quite a few applications are not ready for 64-bit node numbers. But that aside, it has done very well. No other headaches. We're now beginning to deploy large (>10TB) XFS filesystems under SL5. This being said, we now also have lustre OSTs (using a modified ext3) 7.5 TB in size. No problems so far, but then none of them has run full or required an fsck yet. -- Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany
Re: fsck.ext3 on large file systems?
On Wed, Mar 26, 2008 at 7:34 PM, Michael Hannon <[EMAIL PROTECTED]> wrote: > Greetings. We have a lately had a lot of trouble with relatively large > (order of 1TB) file systems mounted on RAID 5 or RAID 6 volumes. The > file systems in question are based on ext3. > > In a typical scenario, we have a drive go bad in a RAID array. We then > remove it from the array, if it isn't already, add a new hard drive > (i.e., by hand, not from a hot spare), and add it back to the RAID > array. The RAID operations are all done using mdadm. > > After the RAID array has completed its rebuild, we run fsck on the RAID > device. When we do that, fsck seems to run forever, i.e., for days at a > time, occasionally spitting out messages about files with recognizable > names, but never completing satisfactorily. > fsck of 1TB is going to take days due to the linear nature of it checking the disk. [ I think the disks for mirrors.kernel.org take many weeks to fsck.] The bigger question is what kind of data are you writing to these disks, and is the ext3 journal large enough for those writes? > The systems in question are typically running SL 4.x. We've read that > the version of fsck that is standard in SL 4 has some known bugs, > especially wrt large file systems. > > Hence, we've attempted to repeat the exercise with fsck.ext3 taken from > the Fedora 8 distribution. This gives us improved, but still not > satisfactory, results. > Did you recompile the binary from source, or did you use it straight? I am just wondering if fsck is dependant on some kernel particulars... To tell you the truth, I have not done anything with Linux Raid in the Terabyte range.. Usually I go with a hardware solution at that point (usually for business reasons.. that much storage usually comes with a box with hardware raid). I did run into a similar issue though trying to help someone last week on a SuSE box with ext3. They also had a long fsck and weird file names coming up. I think they went with the same solution ( restore from backups). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"
Re: Generating PDF via PHP in SL 5.1?
Hi, > We're trying to make these applications work on the new system, and I > have to say it's a can of worms. Yes, pdflib is a Mega-Can of worms. It has an very bad record of incompatible API changes, and the license is way off from a free License. > I suppose that if we remove some more of the standard SL PHP packages > we might eventually come into equilibrium here, but I keep thinking > there must be a better way One way is to rebuild PHP from SL's src.rpm's with included pdflib support and give it different release/version number. Of course you have to do that every time a security update comes out. Also you could try to build the pdflib support for PHP as a Module (you need to install the php-devel Package). > If you've got any cleaner way to deal with PHP/PDF, will you please let > me know ASAP? The cleanest way, but maybe very hard way depending on how well written you're php apps are is probably to change the apps to use FPDF instead. http://www.fpdf.org/ It's a PHP Class, so it doesn't a lib, just plain PHP, and its really free. Sincerly, Klaus -- Klaus Steinberger Beschleunigerlaboratorium Phone: (+49 89)289 14287 Am Coulombwall 6, D-85748 Garching, Germany FAX: (+49 89)289 14280 EMail: [EMAIL PROTECTED] URL: http://www.physik.uni-muenchen.de/~Klaus.Steinberger/ smime.p7s Description: S/MIME cryptographic signature
