Re: [Cooker] XFree86-4.20-6
On 21 Feb 2002, Fabrice FACORAT wrote: It might make more sense to create some add-on packages that provide the selection of which XFree86 server and kernel modules are used. so 2 kernel et 2 XFree server just for this drivers ? No, have a simple package with the radeon kernel module and the ati.2 XFree86 driver. The sources are seperately available. To my mind you'd better critize incoherence in linux development. There's not enough coherence. For example : why does gatos drivers is still not merged with XFree and dri official drivers ? on top of that why don't they in official XFree team and DRI team ? etc ... On top of that because of DRI we have to sync kernel code with XFree code ! It seems to be the price for Direct rendering and better performance but ... Maybe UTAH-GLX project resurection will provide a better alternative ( acceptable 3D perf with no need to be sync with kernel code ). Don't get me wrong here, I'm not saying that the kernel development on this is great either. But if somebody likes to work with the official kernels and hack at them, these changes in Mandrake are a bit of a pain, not a major one, but still. Anyways, it's a thought and/or suggestion. Obviously, now, the Linus kernel in the distribution is not as useful to an ATI card owner (I have a Radeon, but no TV). Regards, John
Re: [Cooker] XFree86-4.20-6
Fabrice FACORAT wrote: http://gatos.sourceforge.net/ati.2.php do you use the right kernel version with the patched drm ? Seems to me that this makes Mandrake less likeable as a kernel development platform. Generally speaking, up until now, major software components (such as XFree86) did not break if you were working with the main kernel trees from Marcelo or Linus. Is this a wise idea to fall off the path like that? It might make more sense to create some add-on packages that provide the selection of which XFree86 server and kernel modules are used. John
[Cooker] unixODBC menu error
There are multiple repeating entries in the unixODBC-gui-qt menu file, amongst other things (including cat EOF ... ). John
[Cooker] XMorph conflict
[root@lion RPMS]# rpm -Uvh xmorph-20010220-5mdk.i586.rpm Preparing...### [100%] file /usr/lib/menu/menu from install of xmorph-20010220-5mdk conflicts with file from package menu-2.1.5-79mdk John
[Cooker] Re: [CHRPM] kernel-linus2.4-2.4.16-4mdk
Juan Quintela wrote: --=-=-= Name: kernel-linus2.4 Relocations: (not relocateable) Version : 2.4.16Vendor: MandrakeSoft Release : 4mdk Build Date: Sat Dec 15 17:58:48 2001 Hmm... this is cool, but being told about it a couple of dozen times is a bit excessive. ;o) I think your bots are acting up.
[Cooker] Which is the culprit?
I can't seem to build a bootable kernel anymore. It gets to: Loading linux. And then reboots. Very strange. However, two major and influential pieces have undergone updates on Cooker recently: binutils and gcc. One of these would appear to be the guilty party. I've tried grub and lilo, both fail. I can boot an older kernel, built before the binutils/gcc updates, but not anything compiled since. On the other hand, if I build a kernel on another machine, it's fine. John
[Cooker] Mirrors not synced?
As far as I can tell, neither primary mirrors have synced up with recent changes in the past two days. Which reminds me, the link from the cooker page on the Mandrake web site to sunsite.uio.no is wrong... Regards, John
[Cooker] Re: [CHRPM] XFree86-4.1.0-13mdk
On Sun, 9 Sep 2001, Frederic Lepied wrote: - radeon updates from cvs (need feedback from r128 and radeon users) Hosed, badly. Sample error messages: ... Symbol vgaHWRestore from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol vgaHWGetIndex from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol vgaHWUnlock from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! Symbol vgaHWRestore from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! ... John
Re: [Cooker] Re: [CHRPM] XFree86-4.1.0-13mdk
John Cavan wrote: On Sun, 9 Sep 2001, Frederic Lepied wrote: - radeon updates from cvs (need feedback from r128 and radeon users) Hosed, badly. Sample error messages: Further to that, I backed out the patch and rebuilt. Everything is up and running fine now. John
Re: [Cooker] starttime
Leon Brooks wrote: Guillaume Cottenceau wrote: Henrik Berglund SdU [EMAIL PROTECTED] writes: I have noticed that it takes about 12sec or longer to start abiword or other programs in gnome or kde but only about 1-2 sec in windowmaker why is that? You're probably low on RAM. Happens to me with K6-II-300 with 196MB (on AGP Banshee, plenty of free swap and HDD). Your call. )-: I see the same behaviour, except with KDE apps (since all of the KDE infrastructure has to start up, the speed is roughly even). In my case, I have a dual PIII 1 GHz with 1 GB of RAM, so memory and horsepower is not an issue here. This is one of the reasons that I've stuck with WindowMaker, the performance difference is actually noticeable. John
Re: [Cooker] New PHP doesn't have MySQL support built-in
Vincent Danen wrote: On Thu Jul 05, 2001 at 12:55:58AM +0200, Alexander Skwar wrote: So sprach John Cavan am Wed, Jul 04, 2001 at 06:42:57PM -0400: Now that MySQL support is not a seperate package, the new version doesn't have it built in though it obsoletes it. Simply remove the Or better, build a php-mysql package, instead. Ummm... there *is* a php-mysql package... I'm not sure what you guys are talking about... Read the specfile. Obsoletes: php3, php-mysql John
[Cooker] New mesa...
In mesa-demos .libs/* does not exist... John
[Cooker] Found the potential problem point for backspace in vim
Well... I've narrowed it down somewhat... the originator of the problem is in /etc/bashrc. When the backspace key is set: if [ -x /usr/bin/tput ]; then if [ x`tput kbs` != x ]; stty erase `tput kbs` elif [ -x /usr/bin/wc ]; then if [ `tput kbs|wc -c ` -gt 0 ]; stty erase `tput kbs` fi fi fi It screws up the terminals in some form. Commented out, and all but xterm work correctly, but with it in, all of them (including xterm) are messed up. It would appear that the problems lies within the ncurses package, though vim can't be completely ruled out. Anyways, I don't use xterm (I prefer aterm), so I've commented it out in /etc/bashrc for now. I haven't encountered any issues. John
Re: [Cooker] XFree86-4.0.99.900-2mdk
Arnd Bergmann wrote: 1. gccmakedepend creates wrong dependencies for *.S files. This causes the build of the xc/extras/Mesa/src/X86/*.S to fail. I fixed this by patching gccmakedepend (%patch11), you did the compile twice. My approach seems cleaner, but it could have some side effects, since I am not sure why they put that strange hack in in the first place. A similar problem, which may or may not be related, was noted on the DRI list for the CVS trunk. Mike Harris of Red Hat included the line: #define PreProcessCmd cpp In the associated host.def and apparently the build problems with Mesa went away. It seems to have the DRI/X guys confused as to why... so YMMV in this regards. John
[Cooker] From latest X install...
Some errors... XFree86 ## xftcache: error while loading shared libraries: xftcache: undefined symbol: XftDirSave execution of XFree86-4.0.99.900-2mdk script failed, exit status 127 XFree86-100dpi-fonts ## XFree86-75dpi-fonts ## mkfontdir: unable to process font ./helvBO12.pcf.gz, skipping mkfontdir: unable to process font ./lubI19-ISO8859-13.pcf.gz, skipping mkfontdir: unable to process font ./lubR19-ISO8859-13.pcf.gz, skipping John
Re: [Cooker] Problems with XFree86-4.0.99
J . A . Magallon wrote: First and more important, all the fonts in the dirs 100dpi, 75dpi and misc look like screwed, thay are all gzipped files of size 20 bytes. Same thing here... fonts are messed up in general. The Type1 module won't load as well. And just a detail, /usr/X11R6/lib/libPEX5.so.6 points nowhere. libPEX doesn't build, I tried a rebuild of the source RPM and discovered errors in two of the PEX header files. I managed to build it, after some edits, and copy it over. The source RPM wouldn't build completely anyways. However, even after getting the fonts and libraries sorted out, the X server won't start, it just hangs and locks my machine up tighter than a drum. Fortunately, I also have X from the DRI project installed, so I'm back in X without having to re-install the old packages. John
[Cooker] XCDRoast spec file buglet
Hi all, The specfile for XCRoast has a Requires: cdrecord = 1.9 cdrecord = 1.9-mdk4. John
[Cooker] WindowMaker WINGs -- missing pixmaps
Hadn't noticed this before, but the pixmaps for the WINGs library widget sets are not being installed into /usr/share/WINGs thus making WINGs cranky and display empty boxes where there should be icons. Just happened to run WSoundPrefs which uses the file browser mechanisms and saw the problem. John
Re: [Cooker] M$ Exchange server
OS wrote: Hello, Our company has just moved over to an Exchange server and the sys admins are being very unfriendly when it comes to giving access to things other than Outbreak 2000 !! Does anyone know if there is a Linux Exchange client out there any where ? http://www.bynari.net/Products/products.html Look for TradeXCH as the client. AFAIK, you have to buy it, but at least it isn't Outlook... John
Re: [Cooker] /etc/passwd in RPMs
Chmouel Boudjnah wrote: John Cavan [EMAIL PROTECTED] writes: Is it really necessary to have /etc/passwd and /etc/group in RPMs? I yes, needed for install in any case new/removed groups are merged by update-passwd file. Would it not make more sense for the install program to create the base files in /etc and then execute update-passwd? Keeps /etc from being littered with *.rpmnew files and keeps newbies from wondering what the heck is going on. Anyways there are users in the default passwd file that should only be added by the RPM for the software they belong to. Users like postgres, dhcpd, named, etc are not mandatory system users if you don't have the packages for them installed. John
Re: [Cooker] /etc/passwd in RPMs
On 3 Apr 2001, Chmouel Boudjnah wrote: John Cavan [EMAIL PROTECTED] writes: Would it not make more sense for the install program to create the base files in /etc and then execute update-passwd? Keeps /etc from being littered with *.rpmnew files and keeps newbies from wondering what the heck is going on. what's wrong with .rpmnew ? Nothing for me, but think about it from a newbie perspective. They will likely think that something went wrong during installation and around a rather critical file. Basically, all I'm suggesting is that we treat /etc/passwd and similar files like XF86Config... create it, never install it. After that, specific packages can add or remove as needed, including setup. John
Re: [Cooker] /etc/passwd in RPMs
Ed Wilts wrote: Basically, all I'm suggesting is that we treat /etc/passwd and similar files like XF86Config... create it, never install it. After that, specific packages can add or remove as needed, including setup. I disagree. I regularly go through and search for .rpmnew files and then compare what's in them with my own versions. Sometimes there are new defaults or options that weren't there when I did my own customizations. I then decide to either toss my file and start with the .rpmnew version, or apply some changes to my own. Not thinking like a newbie. :o) I do the same as you, but I'm not a newbie. What I'm suggesting applies mostly to system critical files that can easily be manipulated through existing tools and are expected to change. Look at the case that I keep bringing up... It is pretty simple for the pre-install script of the postgres RPM to run useradd and post-uninstall script to run userdel (and trap errors should the user exist/not exist). Why would you create users to run software that isn't installed? The same applies to other such files or RPMs. For configuration files which are not expected to change (such XftConfig), by all means, install them, even if they do end up with a .rpmnew extension. If the user has changed the file, then they can inspect for differences and make the change. Realizing, of course, that people who are newbies won't typically change these files and people who are experienced know what to do when a new file comes in. Just my opinion. John
[Cooker] /etc/passwd in RPMs
Hey guys, Is it really necessary to have /etc/passwd and /etc/group in RPMs? I can't possibly think of a install of Mandrake that would retain the initial copies of these files past about an hour, so updates just leave a bunch of *.rpmnew files lying around. Would it not be better to create the users during the pre-install phase of an RPM? If the user exists, then it will simply not create it. On the topic of /etc/passwd and friends, why would setup have users such as postgres if postgresql is not installed? As with above, the pre-install of postgresql should create it and the uninstall should remove it. This is an example, there are others where this applies as well. Thoughts? John
[Cooker] Updated spec for PHP
Hi all, Here's a diff of the php spec to make it work with the latest apache. It includes BuildRequires changes for new libs, etc. It works for me... :o) John php.spec.diff
[Cooker] Minor quibble...
Since the /usr/share/doc directory is mapped in the default Apache config, the index.html in the HOWTO section should be using relative links to the images, not hard paths through the filesystem. Relative is better anyways, more portable. As I said, minor quibble. :o) John
Re: [Cooker] Don't you trust XFree86? :)
Andrej Borsenkow wrote: With XFree86 4.x you don't need an external font server. Why are Mandrake still using xfs? Instead of FontPath "unix/:-1" in XF86Config you can add the font paths directly. Much simpler, more user-friendly and future proof. IMHO it should depend on selected "usage profile". For home computers having font server is probably an overkill. For business, LAN installation, I do want font server to be sure all X-workstations clients get consistent fonts. I've found that XFS has a real problem with large quantities of fonts, solved by dropping XFS and going with the usual fontpath in the config. John
[Cooker] Re: [CHRPM] modutils-2.4.2-3mdk
Matthias Badaire wrote: --=-=-= Name: modutils Relocations: (not relocateable) Version : 2.4.2 Vendor: MandrakeSoft Version 2.4.3 is out with some fixes. John
[Cooker] kdeutils depends on APM?
Following up on the kdenetwork depending on PPP is kdeutils on APM... Umm... same thing, if the APM functions are split out, that would be a good thing. Using the calculator is definitely not dependent on advanced power management support... :o) John
[Cooker] kdenetwork depends on PPP?
Just wondering why... the majority of the network apps have nothing to do with PPP, it would be better to split the PPP dependent apps out into a dial-up package. I shouldn't need PPP to read mail... John
Re: [Cooker] Driver for Matrox 450 dual head
Alex Hulse wrote: Yes, very much, as my online banking requires that I use Netscape 4 or IE 4 onwards. Mozilla/Konqueror won't work and you don't think I'm mad enough to install NS6 do you? :) Maybe make it a little less prominent, but still include it please. AFAIK, you can have konquerer identify itself as either Netscape or IE. John
Re: [Cooker] Re: [CHRPM] kernel-2.4.1-16mdk
Question how do you make using ecgs instead of gcc Normally... "export CC=kgcc" and similar for kg++... For building the kernel, I usually just edit the Makefile. John
[Cooker] WindowMaker 0.64.0 is out
Some bug fixes... but nothing super major that I can tell, 0.63.1 has been working great for me. :o) John
Re: [Cooker] rpm won't install some rpm packages
Richard -Gilligan- Uschold wrote: I'm having problems installing a number of rpm packages. Can't install these: Guppi-0.35.2-1.i586.rpm glibc-2.2.1-3mdk.i586.rpm glibc-devel-2.2.1-3mdk.i586.rpm bonobo-0.33-2mdk.i586.rpm rpm error message: "only packages with major numbers =3 are supported by this version of RPM" You need to upgrade RPM to version 4.
Re: [Cooker] XFree86-4.0.2-4mdk.i586.rpm
600fps on which card? It's possible. I get over 800fps with a Radeon and the DRI code. John
Re: [Cooker] XFree86-4.0.2-4mdk.i586.rpm
Giuseppe Ghibo' wrote: OK, I was wondering if someone successfull get 3D accel under Matrox G400 with XF 4.0.2. I haven't been able to get my Matrox G400 working under 4.0.2 even with the DRI code from SourceForge. I've tried it with the Matrox HAL and without. Always dumps with Sig 11. Kind of sucks, I'm missing multi-head, but the Radeon stuff is fast. John
[Cooker] And the good news is...
Linus has finally added ReiserFS to the main kernel tree, officially in 2.4.1-pre5, working in 2.4.1-pre7... :o) John
Re: [Cooker] XFree86-4.0.2-4mdk.i586.rpm
uli wrote: But there is still a problem with hardware acceleration of my ATI Rage 128. Since kernel-2.4.0-1 /var/log/XFree86.0.log says "(II) R128(0): Direct rendering enabled ". But XFree86-libs-4.0.2-4mdk seems not to deliver the right libGL.so.1.2. All programs that use this lib stop with the note "Loading required GL library /usr/X11R6/lib/libGL.so.1.2 ", then nothing happens. Of course I may use the Mesa-libs by linking the libGL.so.1.2 to the Mesa-lib, but that's not what I what. Which Mesa RPMS do you have installed?
Re: [Cooker] XFree86-4.0.2-4mdk.i586.rpm
uli wrote: John Cavan wrote: uli wrote: But there is still a problem with hardware acceleration of my ATI Rage 128. Since kernel-2.4.0-1 /var/log/XFree86.0.log says "(II) R128(0): Direct rendering enabled ". But XFree86-libs-4.0.2-4mdk seems not to deliver the right libGL.so.1.2. All programs that use this lib stop with the note "Loading required GL library /usr/X11R6/lib/libGL.so.1.2 ", then nothing happens. Of course I may use the Mesa-libs by linking the libGL.so.1.2 to the Mesa-lib, but that's not what I what. Which Mesa RPMS do you have installed? I have installed Mesa-3.4-7mdk. All you should install is the Mesa-common-* and Mesa-demos RPMs. XFree86 supplies the core Mesa libraries for DRI. John
Re: [Cooker] Re: [CHRPM] XFree86-4.0.2-3mdk
Antony Suter wrote: I cannot compile XFree86-4.0.2-3mdk.src.rpm My system is Mandrake 7.2 with some cooker packages and kernel 2.4.0 from www.kernel.org. make[9]: Entering directory `/usr/src/RPM/BUILD/XFree86-4.0.2/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel' === KERNEL HEADERS IN /usr/src/linux/include === SMP=0 MODULES=1 MODVERSIONS=1 AGP=1 === kill_fasync has 3 parameters === Compiling for machine i686 cc -O2 -Wall -Wwrite-strings -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -Wpointer-arith -D__KERNEL__ -DMODULE -fomit-frame-pointer -DCONFIG_AGP -DCONFIG_AGP_MODULE -DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h -DKILLFASYNCHASTHREEPARAMETERS -I/usr/src/linux/include -c gamma_dma.c -o gamma_dma.o gamma_dma.c: In function `gamma_irq_install': gamma_dma.c:654: structure has no member named `next' make[9]: *** [gamma_dma.o] Error 1 The current version of XFree86 4.0.2 pre-dates a change made to the linked list structure in the 2.4.0 kernel series. If cooker is going to run with the latest kernel, it need to either patch the X source (3 files are effected, one liners) or not build the kernel modules that come with it during the RPM build (one of the flags in the host.def). John
[Cooker] Problems with latest cooker RPMS
Hey all, some probs: bcast-2000b-1mdk.i586.rpm: - got: "error: bcast-2000b-1mdk.i586.rpm cannot be installed" gcc-2.96-0.31mdk.i586.rpm: - alternatives are not updated AfterStep-1.8.8-1mdk.i586.rpm and libAfterStep1-*: - got: "error: failed dependencies: netscape is needed by AfterStep-1.8.8-1mdk" - why does a window manager depend on Netscape? fribidi-0.1.15-2mdk.i586.rpm libfribidi0-*: - got: "error: failed dependencies: fribidi = 0.1.12 is needed by fribidi-devel-0.1.12-1mdk" binutils-2.10.1.0.2-2mdk.i586.rpm: - did not issue a dependency on libbinutils2-2.10.1.0.2-2mdk.i586.rpm libungif4-*-12mdk libungif-progs-*-12mdk: - got: "error: failed dependencies: libungif4 = 4.1.0-11mdk is needed by libungif4-progs-4.1.0-11mdk" John
[Cooker] Re: [CHRPM] XFree86-4.0.2-3mdk
"Giuseppe Ghib" wrote: * Sat Jan 06 2001 Giuseppe Ghib [EMAIL PROTECTED] 4.0.2-3mdk - make freetype2 conditional in SPEC file (for Mandrake 7.2 backport). - make HAL conditional in SPEC file (e.g. mgaHALlib.a). - added glxinfo, xgamma, pcitweak, showfont, revpath and their man pages to %files. Does this also fix the xfs start-up problem? John
Re: [Cooker] Problem with XFree86-4.0.2-2mdk
Guillaume Cottenceau wrote: I don't need droppriv to make it work. here's mine: daemon xfs -port -1 -daemon -user xfs -droppriv causes xfs to run as user xfs -user allows you to specify the user to run as They are basically the same. If you su to xfs before running xfs, you can't write to /var/run. John
[Cooker] xfs initscript and kdm
The latest initscript for xfs fails to start the font server (4.0.2-2mdk). I haven't debugged the script yet, but the font server is fine if started from the command line. Also, would it be possible to NOT have the kdm config file blown away on upgrades? Once you tweak it for your system, such as picking which users to show, requiring root for shutdown, etc, it's disconcerting to see it blown away on the next install. The same would apply to dosemu, but I saved that config before installing... :o) John
Re: [Cooker] error compiling gimp-1.2.0-1mdk.src.rpm
Guillaume Rousse wrote: I got the same problem as Anthony with the same configuration (Mandrake 7.2, perl 5.6-17mdk, and gimp 1.1.25-13mdk) : creating script-fu make[4]: Quitte le répertoire `/home/guillaume/RPM/BUILD/gimp-1.2.0/plug-ins/script-fu' make[3]: Quitte le répertoire `/home/guillaume/RPM/BUILD/gimp-1.2.0/plug-ins/script-fu' Making all in perl make[3]: Entre dans le répertoire `/home/guillaume/RPM/BUILD/gimp-1.2.0/plug-ins/perl' make[3]: *** Pas de règle pour fabriquer la cible `all'. Arrêt. make[3]: Quitte le répertoire `/home/guillaume/RPM/BUILD/gimp-1.2.0/plug-ins/perl' make[2]: *** [all-recursive] Erreur 1 make[2]: Quitte le répertoire `/home/guillaume/RPM/BUILD/gimp-1.2.0/plug-ins' make[1]: *** [all-recursive] Erreur 1 make[1]: Quitte le répertoire `/home/guillaume/RPM/BUILD/gimp-1.2.0' make: *** [all-recursive-am] Erreur 2 Bad exit status from /home/guillaume/RPM/tmp/rpm-tmp.21122 (%build) You need to uninstall the old version of Gimp first, building the perl stuff gets confused otherwise. John
[Cooker] Re: [Contrib-Rpm] kfontinst-0.9.1-1mdk
Lenny Cartier wrote: [Contrib-RPM] --=-=-= Name: kfontinstRelocations: (not relocateable) Version : 0.9.1 Vendor: MandrakeSoft Release : 1mdk Build Date: Tue Jan 2 17:35:45 2001 Install date: (not installed) Build Host: bi.mandrakesoft.com Group : Graphical desktop/Other Source RPM: (none) Size: 395422 License: GPL Packager: Lenny Cartier [EMAIL PROTECTED] URL : http://www.cpdrummond.uklinux.net/kfontinst/ Summary : KDE-based TrueType and Type1 font installer Description : Xsane is a graphical frontend for sane. Install this if you want a graphical frontend for sane for use in the X Windowing System. --=-=-= * Tue Jan 02 2001 Lenny Cartier [EMAIL PROTECTED] 0.9.1-1mdk - new in contribs -- http://www.linux-mandrake.com/en/cookerdevel.php3 Err... kfontlist with the xsane description? John
Re: [Cooker] Most of the kio libs are missing in latest KDE
kdebase-2.1-0.20001229.2mdk is the version I have. The spec file simply
needs to add:
%{kde2dir}/kio_audiocd.so
%{kde2dir}/kio_filter.so
%{kde2dir}/kio_finger.so
%{kde2dir}/kio_gopher.so
%{kde2dir}/kio_help.so
%{kde2dir}/kio_info.so
%{kde2dir}/kio_man.so
%{kde2dir}/kio_nfs.so
%{kde2dir}/kio_nntp.so
%{kde2dir}/kio_pop3.so
%{kde2dir}/kio_smb.so
%{kde2dir}/kio_smtp.so
%{kde2dir}/kio_tar.so
Somewhere in the %files section to work. The libs are built, just not
included.
John
Christopher Molnar wrote:
What is the rpm name for kdebase you are using? We have a few kde versions
floating around right now. Also, in any application help--- About KDE gives
a version number and string. What is yours saying?
Most of these libs should have moved to /usr/lib/kde2 are they there?
-Chris
On Sunday 31 December 2000 15:01, you wrote:
In particular:
kio_audiocd.so
kio_filter.so
kio_finger.so
kio_gopher.so
kio_help.so
kio_info.so
kio_man.so
kio_nfs.so
kio_nntp.so
kio_pop3.so
kio_smb.so
kio_smtp.so
kio_tar.so
This is just a cursory inspection, there may be others. Some seem to
come from kde-base and others from kde-libs.
I'd do more, but, well, I'm going out to party. :o)
John
[Cooker] Most of the kio libs are missing in latest KDE
In particular: kio_audiocd.so kio_filter.so kio_finger.so kio_gopher.so kio_help.so kio_info.so kio_man.so kio_nfs.so kio_nntp.so kio_pop3.so kio_smb.so kio_smtp.so kio_tar.so This is just a cursory inspection, there may be others. Some seem to come from kde-base and others from kde-libs. I'd do more, but, well, I'm going out to party. :o) John
Re: [Cooker] fix proposal: XFree86
Stefan van der Eijk wrote: This updated package will fix XFree86 running on the alpha (perhaps also other non-ix86 platforms -- just change the "%ifarch alpha" into "%ifnarch %ix86") with MGA hardware. Take a look at this e-mail from Jay Estabrook below. http://d10179.dtk.chello.nl/build/fixes/cooker/XFree86-4.0.2-2mdk.src.rpm http://d10179.dtk.chello.nl/build/fixes/cooker/XFree86-4.spec http://d10179.dtk.chello.nl/build/fixes/cooker/XFree86-4.spec.diff http://d10179.dtk.chello.nl/build/fixes/cooker/XFree86-4.spec.orig Can this fix please be included in the next release (the only thing touched was the .spec file)? Stefan === Subject:Re: XFree-4.0.2 mga alpha Date: Wed, 27 Dec 2000 10:22:46 -0500 From: Jay Estabrook [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: 1 , 2 On Mon, Dec 25, 2000 at 10:49:41PM -0500, Christopher C. Chimelis wrote: On Sun, 24 Dec 2000, Stefan van der Eijk wrote: The alpha (miata) has a 4Mb Matrox Millienium II card in it... The problem probably lies in the mga_drv.o module (see the error messages below): Any idea's? Check to see if the modules are stripped. For some reason, I have had nothing but problems when trying to use modules that are stripped on Alpha. I haven't yet had time to see why this happens, but the "unresolved symbol" problems go away if the modules are unstripped (at least for the two cards that I've tried...s3virge and tdfx). Been there, done that... ;-} The problem is that the Matrox HAL was enabled by default at a very late date, and not tested on Alpha, if that's even possible. The HAL is, IIRC, a low-level library between the server and the card that Matrox wants to supply, and it may be in binary only at the moment, source later. So, IIRC, the patch for the build was to put: #define UseMatroxHalNO in the host.def file before starting the build. The only thing affected, again AFAIK, would be the mga_drv.o. AFAIK, unless you are including the mgaHALlib for x86 builds, you need to do this as well. I haven't tried that yet, but I've been unable to get any available X 4.0.2 binaries to run on my dual P3 system. John
[Cooker] Re: [CHRPM] XFree86-4.0.1z-2mdk
Frederic Lepied wrote: --=-=-= Name: XFree86 Relocations: (not relocateable) Version : 4.0.1zVendor: MandrakeSoft Is this being built with the Matrox HALlib for the MGA driver or with init routines supplied by XFree86.org? The reason I'm asking is that if the Matrox library is used then multi-head in X is possible (and can be accelerated with OpenGL). AFAIK, the last time I tried the stock XFree86 driver it would not work. The only sad thing is that Matrox won't open the HALlib, but the XFree86 guys have merged the supporting code into the tree to allow that to be built in as an option over the default. John
Re: [Cooker] Re: [CHRPM] XFree86-4.0.1z-2mdk
Frederic Lepied wrote: Is this being built with the Matrox HALlib for the MGA driver or with init routines supplied by XFree86.org? The reason I'm asking is that if the Matrox library is used then multi-head in X is possible (and can be accelerated with OpenGL). AFAIK, the last time I tried the stock XFree86 driver it would not work. The only sad thing is that Matrox won't open the HALlib, but the XFree86 guys have merged the supporting code into the tree to allow that to be built in as an option over the default. This is built without the HALlib because we don't want to put non open source components in the distribution. Hmm... well, just a few thoughts for you: There already is non-OSS components in the distribution, notably Netscape communicator. I fundementally agree with you around the OSS versus non-OSS issue here, but there is a little bit of pragmatism involved in this as well. Basically, your user base is of a more primary concern than a general cause, there are other ways to push companies into opening their source without punishing the user with sub-par functionality. Not an issue for myself, I'll simply stick with the current released X or manually build it with the library, but a newbie rolling into Linux for the first time may just as quickly roll back out once they discover that their hardware doesn't work the way they expected it to. I want to stress the last point a little bit here... folks like us prefer to work with Linux because it is open and we can get involved and help out. On the other hand, many people are beginning to look at Linux as an alternative to Windows not because it is open, but because it is reliable, fast, much less expensive, etc. They neither understand nor care for the cause that GNU is pursuing, though they may benefit from it. It's a catch 22. We need to support their interest and use it so that hardware companies see a benefit from supporting Linux. Hardware companies see a benefit when there are enough people using Linux to warrant it, but these people won't bother with Linux if they can't get the functionality expected because of philisophical standoff. Sometimes you have to bend a little in the beginning to make the long run pay off. Food for thought. John
[Cooker] orphaned packages in Cooker
Hi all, Do you suppose that something could be done to rid cooker of the various orphaned packages now kicking around? These extras just confuse the migration to the new lib formats. John
Re: [Cooker] ld.so-1.9.11-7mdk reports multiple libc's
Chmouel Boudjnah wrote: Meir Faraj [EMAIL PROTECTED] writes: Yep I could confirm that :-( I've also tryed to upgrade it and receive the same message ... but I think it will be fixed , there are a lot of thing to be done . last glibc obsoletes ld.so and should fix that.. It does... thanks. John
[Cooker] latest rpm and ld are messed up in Cooker...
Hi all, The latest rpm still has an empty macros and a number of messed up symbolic links in /usr/lib/rpm and consistently prints: dbiSetConfig: unrecognized db option: "db3" ignored In addition, ldconfig will always report: ldconfig: warning: /lib/libdl.so.1 appears to be for multiple libc's ldconfig: warning: /lib/libdl.so.1.9.11 appears to be for multiple libc's John
Re: [Cooker] latest rpm and ld are messed up in Cooker...
Chmouel Boudjnah wrote: John Cavan [EMAIL PROTECTED] writes: In addition, ldconfig will always report: ldconfig: warning: /lib/libdl.so.1 appears to be for multiple libc's ldconfig: warning: /lib/libdl.so.1.9.11 appears to be for multiple libc's what ls /lib/libdl* give you ? /lib/libdl-2.2.so* /lib/libdl.so.1@ /lib/libdl.so.1.9.11* /lib/libdl.so.2@ John
[Cooker] libdl messages still coming
Hi, I'm still getting: ldconfig: warning: /lib/libdl.so.1.9.11 appears to be for multiple libc's ldconfig: warning: /lib/libdl.so.1 appears to be for multiple libc's From ld.so-1.9.11-7mdk. Running ldd on the file produces: libc.so.6 = /lib/libc.so.6 (0x40021000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x2000) Note that ld-linux.so.2 comes from the glibc package and ld-linux.so.1.9.11 comes from ld.so package as does libdl.so.1.9.11... looks like a linking issue. John
Re: [Cooker] Re: [CHRPM] gcc-2.96-0.7mdk
Why not just offer it as "hackgcc-2.96..." and provide both? That way, we have a stable compiler series for critical stuff and a developmental compiler for experimentation. John
Re: [Cooker] gcc 2.96
Tim McKenzie wrote: I hope that next time I run that lovely little ./no_rsync.pl I won't see this version coming in the 7.2 beta directory. If the oppinion of the beta testers count for anything as far as the distribution is concerned it seems quite obvious that most if not all of the people on the list are against this "upgrade." As a c++ coder I can say I am definately not happy with the reports I've read about 2.96 and after experimenting with it I'm dead set against it. I reallize it is just in the cooker directories so far but even the thought of making the same mistake RH made is scary. So, here is yet another voice against 2.96 Tim McKenzie Appalachian State University [EMAIL PROTECTED] http://linuxtoday.com/news_story.php3?ltsn=2000-10-07-009-20-NW-SW I'd suggest that if the GCC folks strongly recommend against it, that's a pretty strong argument to not use it. Count me as another voice against... I don't want to be playing games just to get my kernel to compile. John
Re: [Cooker] gcc 2.96
Pixel wrote: Tim McKenzie [EMAIL PROTECTED] writes: I've read about 2.96 and after experimenting with it I'm dead set against it. seems like redhat managed to build their full distro with it, so C++ is not dead broke. Yep, everything except the most important part: the kernel. John
Re: [Cooker] rpm-3.0.5-22mdk
It's the new wait-for-lock patch, it get's caught in an endless loop. I haven't tried debugging it, but as soon as I removed the patch and re-installed the package it was fine. John Never saw this behavior before with any distribution?! Of course perhaps there is already a new rpm and I just haven't gotten through to the site with the update?
[Cooker] Re: [CHRPM] Eterm-O.8.10-10mdk
--=-=-= Name: EtermRelocations: (not relocateable) Version : O.8.10Vendor: MandrakeSoft ^^ I think you have a versioning problem... letter O rather than 0. John
Re: [Cooker] initscript
[EMAIL PROTECTED] wrote: I get this when i uograde initscript(from cooker) warning: /etc/X11/prefdm created as /etc/X11/prefdm.rpmnew unpacking of archive failed on file /etc/init.d: cpio: unlink I hit this as well, it happened with earlier Gimp packages. It seems to bomb out on symbolic links, though that never used to be a problem. John
[Cooker] initscripts problem figured out
The failure of the install has to do with the current situation of harddrake. Harddrake installs it's init script in /etc/init.d where /etc/init.d is a proper directory and not a symlink to /etc/rc.d/init.d. So what happens is that when you try to upgrade initscripts it can't create the symlink for /etc/init.d on the existing hard directory. Basically, I removed harddrake and then installed the initscripts package, then re-installed harddrake. All went well from what I can tell. Harddrake's spec needs a fix-up. John
[Cooker] Prob. with Konquerer
When I run Konquerer from WindowMaker, I get: Unable to run the command specified. The file or directory file:/home/johnc/%u does not exist. That's the first time I've encountered this one running Konquerer in WindowMaker. John
[Cooker] Nevermind my last, re: Konqueror
I figured out my problem... I've modified the WindowMaker menu config to say that it handles the KDE and Gnome as well. Seems that may be a bit problematic... John
[Cooker] PHP and MySQL problems
Hi guys, There seems to be a definite problem with MySQL support in the latest PHP/Apache RPMs. I've got all of the RPMs installed and PHP support enabled, the php.ini says to load mysql.so, but no matter what, making MySQL calls fails with: Fatal error: Call to undefined function: mysql_connect() in /home/httpd/html/welcome.php on line 13 Calling phpinfo() shows the MySQL extension is not loaded, yet the ini files has told it to do so. Oddly enough, the GD extension loads fine. So then I tried using the dl( "mysql.so" ) call and got: Warning: Unable to load dynamic library '/usr/lib/php/extensions/mysql.so' - /usr/lib/php/extensions/mysql.so: undefined symbol: pthread_key_create in /home/httpd/html/welcome.php on line 11 Which would appear to pin the problem on glibc (I have the latest cooker version installed). John
Re: [Cooker] imwheel
Serge Lussier wrote: - Original Message - From: Amien Salie [EMAIL PROTECTED] To: Cooker Repeat Email (E-mail) [EMAIL PROTECTED] Sent: Saturday, July 22, 2000 9:50 AM Subject: Re: [Cooker] imwheel Who will admit along with me that the worlds worst sofware maker (Micro$oft) is ironically one of the better Hardware makers :P Amin -- w00 Hehehe, I agree... My mouse :Microsoft Intellimouse Explorer My Joystick: Miscrosoft Sidewinder Precision Pro - Bretzel I have to agree too... Intellimouse Explorer, Sidewinder joystick. I hate natural keyboards though. John
Re: [Cooker] libX11.so.6 problem
Jim Bradley wrote: I just did a new install of a cooker mirror, the installation of which went great, but when X is started, I get an error message: winbook login: gdm: error in loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory Yet when I look , /usr/X11R6/lib/libX11.so.6 does exist. What do I need to do to get X working (and what do you need to do to get the installation to work properly? Thanks for your help. Jim Bradley -- Maryville, MO USA ([EMAIL PROTECTED]) Did you check for existence by looking in the directory or with ldconfig? run: ldconfig -p |grep libX11 and see if the library is found. Also, check /etc/ld.so.conf to ensure that /usr/X11R6/lib is included. John
Re: [Cooker] Re: [CHRPM] xv-3.10a-8mdk
Guillaume Cottenceau wrote: [EMAIL PROTECTED] writes: ftp://ftp.cis.upenn.edu/pub/xv/xv-3.10a.tar.gz Location of source. It isn't open in the sense of GPL/BSD/Artistic, BUT the source is available and that puts it a cut above commercial software. In the practical way, yes. In the theorical way, no: the first freedom of the GPL, the freedom to redistribute bugfixed versions, is prohibited. This license is the same as Sun Community License, or the license for Yast2. You can look, you can't touch. Hey, I said I didn't want to get into a license war. :o) My main point was that being non-GPL should not be a bar from the main distribution if the program is useful or desired. I'm all for educating or promoting more open licenses from commercial developers and I think this guy is half-way there. So instead of "punishing" him, we should encourage him to change the license. Maybe he's working now and doesn't need the income? Bitching about his license gets us nowhere. I don't begrudge the guy the right to sell his efforts, but at least give him credit for supplying the source code along with it. That credit is 100% provided by the GPL. We at MandrakeSoft license under the GPL *and* sell our efforts. One of the reasons that I personally appreciate Mandrake and other vendors who do this. Perhaps the reasons that Mandrake does this will also encourage him the same way, it's worked for others (i.e. Troll's QT). John
Re: [Cooker] Re: [CHRPM] xv-3.10a-8mdk
ftp://ftp.cis.upenn.edu/pub/xv/xv-3.10a.tar.gz Location of source. It isn't open in the sense of GPL/BSD/Artistic, BUT the source is available and that puts it a cut above commercial software. I don't begrudge the guy the right to sell his efforts, but at least give him credit for supplying the source code along with it. Guillaume Cottenceau wrote: [EMAIL PROTECTED] writes: XV is available with source, but it has a price tag. AFAIK, the GPL does not prohibit the sale of open source software. Not that I'm claiming that XV is necessarily GPL compatible, but it is open, placing it miles ahead of any commercial closed package. XV is open?? please have a sleep and rethink in the light of some extracts of their README file: XV IS SHAREWARE FOR PERSONAL USE ONLY. You may use XV for your own amusement, and if you find it nifty, useful, generally cool, or of some value to you, your registration fee would be greatly appreciated. $25 is the standard registration fee, though of course, larger amounts are quite welcome. Folks who donate $40 or more can receive a printed, bound copy of the XV manual for no extra charge. If you want one, just ask. BE SURE TO SPECIFY THE VERSION OF XV THAT YOU ARE USING! COMMERCIAL, GOVERNMENT, AND INSTITUTIONAL USERS MUST REGISTER THEIR COPIES OF XV. [...] If you use XV in the course of doing your work, whatever your 'work' may happen to be, you *must* register your copy of XV. [...] Permission to copy and distribute XV in its entirety, for non-commercial purposes, is hereby granted without fee, provided that this license information and copyright notice appear in all copies. If you redistribute XV, the *entire* contents of this distribution must be distributed, including the README, and INSTALL files, the sources, and the complete contents of the 'docs' directory. -- Guillaume Cottenceau -- Distribution Developer for MandrakeSoft http://www.mandrakesoft.com/~gc/
Re: [Cooker] Re: [CHRPM] xv-3.10a-8mdk
Alexander Skwar wrote: On Wed, Jul 26, 2000 at 03:34:25PM +0200, Guillaume Cottenceau wrote: We have to at least move it to the contribs (I say at least because it falls into the commercial app category (as being a shareware) so it must go theorically in the commercial CD's). That be to harsh IMHO. The author is fair enough to provide the source code free of charge, and his license is quite fair, again IMHO. Contrib is good enough, but at least get it of the GPL (!!) CDs, because it ain't GPL. Not that I want to start a license war... Neither is Apache, Netscape, and a host of other packages. Not being GPL'd should not be a bar from being on the main distribution. Pragmatism falls in line with functionality and some of us like XV, it's very reliable, unlike some of the others I have seen. It is the reason I keep using it. John
Re: [Cooker] Re: [CHRPM] xv-3.10a-8mdk
Pixel wrote: [EMAIL PROTECTED] writes: Not that I want to start a license war... well ... ;p LOL, anytime GPL versus other comes up... Neither is Apache, Netscape, and a host of other packages. Not being GPL'd should not be a bar from being on the main distribution. no, be not being open source, aka not following debian guideline can be. apache is free, netscape is not, nor is xv. XV is available with source, but it has a price tag. AFAIK, the GPL does not prohibit the sale of open source software. Not that I'm claiming that XV is necessarily GPL compatible, but it is open, placing it miles ahead of any commercial closed package. I hope you are not suggesting that Netscape disappear from the distro? It's a buggy mess, but it's pretty much the only buggy mess that we have right now. Konquerer is looking pretty darn good though, so I have future hopes of dumping Netscape Pragmatism falls in line with functionality and some of us like XV, it's very reliable, unlike some of the others I have seen. It is the reason I keep using it. i really don't the point for xv, open yours eyes and you'll see a whole bunch of *good* xv replacements. xv should be removed because it is shareware. (replacements: ImageMagick, ee, eog, gqview, pixie, gimp, all fully working) I've tried them all. ImageMagick is not GPL either, but is a fantastic program. I love the Gimp, use it all the time, but it's a little heavy for quick image viewing. The others, they've all crapped out too often on me, but I still do use them, it varies. All I'm getting at is that "non-GPL" (which is what the guy was pushing on) is not a good reason to exclude a package. Exclude it for other reasons, such as better alternatives, and all is well in the world. :o) The Unix world is pragmatic: you use what works until there is better, then you switch to better. It's the Microsoft way to force people down a path that suits Microsoft's purpose and not their customers. John
Re: [Cooker] Re: [CHRPM] xv-3.10a-8mdk
Alexander Skwar wrote: On Wed, Jul 26, 2000 at 07:32:53PM -0400, [EMAIL PROTECTED] wrote: Not that I want to start a license war... Neither is Apache, Netscape, and a host of other packages. Not being Well, you're right, none of your examples is GPL, that's true. BUT (big but, in bright blinky colors): Netscape and XV are not free! That's my point, whereas Apache and many of the IMHO superior replacements, like ImageMagick, Electric Eyes (ee) ... for xv are. Actually, Netscape is free, just not open source (not counting Mozilla, of course, but it isn't ready for prime time yet). XV is shareware (though thankfully not nagware), but is available in source form. Kind of a pick your poison... OTH, I read the license... apparently XV needs to be licensed for redistribution in a commercial product. NOW that is a reason that I would remove it from the main CD and move it to contrib.
Re: [Cooker] Re: [CHRPM] xv-3.10a-8mdk
Alexander Skwar wrote: On Wed, Jul 26, 2000 at 08:26:35PM -0400, [EMAIL PROTECTED] wrote: All I'm getting at is that "non-GPL" (which is what the guy was pushing on) is not a good reason to exclude a package. Exclude it for other Well, yes, that's what I said, but that's not what I meant. I rather meant, that un-free programs should be excluded. Excluding every non GPL application would be way to harsh, granted. I buy argument 1, if it isn't free... Not only would excluding non-GPL code be harsh, but it would pretty much lead to a dysfunctional system... You wouldn't believe the number of packages that have different licenses.
Re: [Cooker] BM
Just out of curiosity, why the move? I think I missed that one on the list. Guillaume Cottenceau wrote: Alex Boag-Munroe [EMAIL PROTECTED] writes: This has probably been asked already, but wtf does "BM" mean on the changelogs? Big Move. /usr/man - /usr/share/man /usr/info - /usr/share/info /usr/doc - /usr/share/doc -- Guillaume Cottenceau -- Distribution Developer for MandrakeSoft http://www.mandrakesoft.com/~gc/
Re: [Cooker] 3dfx voodoo3 with XFree4
The kernel module in the X tree is broken against the latest development kernels and the module that ships with the kernel is flagged as too old to work with X. According to David Miller, this patch will fix up the kernel shipped module to work: --- vanilla/linux/drivers/char/drm/drm.hTue Mar 14 09:27:31 2000 +++ linux/drivers/char/drm/drm.hSun Jun 18 00:28:26 2000 @@ -247,7 +247,7 @@ #define DRM_IOCTL_VERSIONDRM_IOWR(0x00, drm_version_t) #define DRM_IOCTL_GET_UNIQUE DRM_IOWR(0x01, drm_unique_t) -#define DRM_IOCTL_GET_MAGIC DRM_IOW( 0x02, drm_auth_t) +#define DRM_IOCTL_GET_MAGIC DRM_IOR( 0x02, drm_auth_t) #define DRM_IOCTL_IRQ_BUSID DRM_IOWR(0x03, drm_irq_busid_t) #define DRM_IOCTL_SET_UNIQUE DRM_IOW( 0x10, drm_unique_t) I should also note that there is a version flag in the tdfx driver that also has to be adjusted or X will still reject it. John Guillaume Cottenceau wrote: José Luiz Barci Neves [EMAIL PROTECTED] writes: Where i can take a XFREE 4.01 mdk of course ? thanks a lot! For the moment it does not work. We've worked on that yesterday but not yet finished -- the dri/tdfx module does not compile anymore with 4.0.1 and Fred does not no why. FYI I was meaning the tdfx.o kernel module, not tdfx_drv.o for which fred answered. He managed to compile that yesterday but we have to decide whether it's possible to put it in the kernel package which would be better of course. -- From: Frederic Lepied[SMTP:[EMAIL PROTECTED]] Reply To: [EMAIL PROTECTED] Sent: quinta-feira, 13 de julho de 2000 06:07 To: [EMAIL PROTECTED] Subject:Re: [Cooker] 3dfx voodoo3 with XFree4 Guillaume Cottenceau [EMAIL PROTECTED] writes: "Hoyt" [EMAIL PROTECTED] writes: Isn't the newest 4.0.1 supposed to include the tdfx.0 driver now? supposed to, yes. i did not tested it so I don't know. fred? yes : $ rpm -qlp XFree86-server-4.0.1-2mdk.i586.rpm | grep tdfx /usr/X11R6/lib/modules/drivers/tdfx_drv.o -- Fred - May the source be with you -- Guillaume Cottenceau -- Distribution Developer for MandrakeSoft http://www.mandrakesoft.com/~gc/
Re: [Cooker] a pure RMS compliant Linux-Mandrake distro (only GPLpackages)
Pixel wrote: [EMAIL PROTECTED] writes: no Perl nope, perl is GPL *or* artistic, aka compatible with gpl... According to them, it's artistic, "a kinder and gentler" version of the GPL... It may be compatible, but it isn't the GPL, which was my point. :o) I don't know how you resolve the BSD issues in the kernel on this one, but I think you lose some networking... I don't think you could make a useful system out of GPL only software.
Re: [Cooker] Man Page for resolv.conf
Francis Galiegue wrote: On Wed, 5 Jul 2000, Don Head wrote: Any posiblity of sticking in a symlink for resolv.conf in the man-pages RPM? I spent quite a few minutes figuring out that "man resolver" needs to be used rather than "man resolv.conf". A simple "ln -s /usr/man/man5/resolver.5.bz2 /usr/man/man5/resolv.conf.5.bz2" would be appreciated. Huh, the resolver manpage is not about the format of resolv.conf file at all... As there is no relationship between this manpage and the resolv.conf file, I'm against that symlink (which should be a link anyway, because they're in the same directory). And moreover, as this manpage describes the resolver API, it should be in section 3 IMHO. Did you try "man resolver"? If so, you would have discovered that it is specific to the format of /etc/resolv.conf and that Don was correct: RESOLVER(5) System Programmer's Manual RESOLVER(5) NAME resolver - resolver configuration file SYNOPSIS /etc/resolv.conf DESCRIPTION The resolver is a set of routines in the C library (resolve(3)) that provide access to the Internet Domain Name System. The resolver configu ration file contains information that is read by the resolver routines the first time they are invoked by a process
Re: [Cooker] 3dfx voodoo3 with XFree4
You need the Glide module from the contribs rather than the mainline, the XFree glide module contains the video driver for the older Voodoo cards, not the Voodoo3. The Glide stuff in contribs supplys the glide library for general apps. John Guillaume Cottenceau wrote: Hi, Just my final report about using the acceleration with a voodoo3 under XFree4. First word: it's not quicker than under XFree-3.3.6 . I used the tip provided by [EMAIL PROTECTED] to compile the tdfx kernel module. (I'll have to see with fredl and chmou with which package we can provide this module) Some warnings at the compile time but the compile went fine, the modprobe also. . the good resource is there: http://dri.sourceforge.net/DRIuserguide.html . I used Xfree86-libs-4.0-6mdk for the libGL stuff . I used Mesa-common-3.2-4mdk for the libGLU and libglut stuff . I used XFree86-glide-module-4.0-6mdk for the dri module (the 4.0.1 is no more working AFAIK; fred working on it) . misc point: I had a message with grDRIsomething missing when trying to load any program. Yoann help me: it was a problem with Glide_V3 library; we have to use the Glide_V3-DRI instead (worked for me prepending a LD_PRELOAD=/usr/lib/libglide3x.so.2 to the programs) -- Guillaume Cottenceau
[Cooker] Problems with XFree86 4.0.1 RPMs
Hi, The new RPMs for XFree86 4.0.1 are missing all the DRI drivers in /usr/X11R6/lib/modules/dri thus causing 3D hardware acceleration to fail. All the other modules appear to be correct, this is the only missing set. John P.S. I solved my immediate problem by grabbing the binary versions from XFree86, they're in Xmod.tgz for those who need them.
[Cooker] More notes on XFree86 4.0.1
For those who are running the Linux development kernels, make sure that you grab the latest kernel drivers from the DRI site (dri.sourceforge.net). You'll have to pull them in from CVS, but acceleration won't work unless you do. Hopefully the development kernels will catch up. Specifically, you need to grab this directory from CVS: /xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel Compile it, in that directory, with: make -f Makefile.linux tdfx.o The tdfx.o is for Voodoo3 users, choose a different one for other card types. By the way, the latest appears to use the agpgart stuff finally and seems to be faster. Ignore the compiler warnings, it seems to be fine. Put it in the appropriate module location, modprobe it, and restart X. See my other email about the missing dri drivers for X and how to get them. Or redo the SRPM, I don't have the time right now for myself. John
[Cooker] New XFree86 4
For the XFree86 maintainers out there... Version 4.0.1 has been unleashed on the public. :o) John
[Cooker] hackgimp revisited
1.1/gimpressionist/
%dir %{prefix}/share/gimp/1.1/gimpressionist/Paper
%dir %{prefix}/share/gimp/1.1/gimpressionist/Presets
%dir %{prefix}/share/gimp/1.1/gradients
%dir %{_prefix}/lib/perl5/site_perl/*/*/Gimp
%dir %{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp
%dir %{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/Lib
%dir %{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/Net
%dir %{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/UI
%{_prefix}/share/icons/mini/wilbur.xpm
%{_prefix}/lib/menu/gimp
%{prefix}/bin/gimp
%{prefix}/lib/gimp/1.1/plug-ins/*
%{prefix}/lib/gimp/1.1/modules/lib*.a
%{prefix}/lib/gimp/1.1/modules/lib*.la
%{prefix}/lib/gimp/1.1/modules/lib*.so
%{_prefix}/lib/perl5/man/man3/*
%{_prefix}/lib/perl5/site_perl/*/*/*.pm
%{_prefix}/lib/perl5/site_perl/*/*/Gimp/*
%{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/*.bs
%{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/*.so
%{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/Lib/*
%{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/Net/*
%{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/UI/*
%{prefix}/share/locale/*/LC_MESSAGES/*
%{prefix}/share/gimp/1.1/scripts/*
%{prefix}/share/gimp/1.1/fractalexplorer/*
%{prefix}/share/gimp/1.1/gfig/*
%{prefix}/share/gimp/1.1/gimpressionist/Presets/*
%{prefix}/share/gimp/1.1/gimpressionist/Brushes/*
%{prefix}/share/gimp/1.1/gimpressionist/Paper/*
%{prefix}/share/gimp/1.1/gradients/*
%{prefix}/share/gimp/1.1/palettes/*
%{prefix}/share/gimp/1.1/patterns/*
%{prefix}/share/gimp/1.1/brushes/*
%{prefix}/share/gimp/1.1/tips/*
%{prefix}/share/gimp/1.1/help/*/*/*/*/*.html
%{prefix}/share/gimp/1.1/help/*/*/*/*.html
%{prefix}/share/gimp/1.1/help/*/*/*.html
%{prefix}/share/gimp/1.1/help/*/*.*
%{prefix}/share/gimp/1.1/devel-docs/html/libgimp/*
%{prefix}/share/gimp/1.1/user_install
%{prefix}/share/gimp/1.1/gimprc
%{prefix}/share/gimp/1.1/gimprc_user
%{prefix}/share/gimp/1.1/gtkrc
%{prefix}/share/gimp/1.1/unitrc
%{prefix}/share/gimp/1.1/gimp_logo.ppm
%{prefix}/share/gimp/1.1/gimp_splash.ppm
%{prefix}/share/gimp/1.1/ps-menurc
%{prefix}/share/aclocal/gimp.m4
%{prefix}/man/man1/*
%{prefix}/man/man5/*
%doc AUTHORS COPYING ChangeLog INSTALL NEWS README TODO
%files devel
%defattr(-,root,root,0755)
%{prefix}/bin/gimptool
%{prefix}/include/libgimp/*
%{prefix}/include/gck/gck.h
%{prefix}/lib/lib*.a
%{prefix}/lib/lib*.la
%files libgimp
%defattr(-,root,root,755)
%{prefix}/lib/*.so*
%clean
%post
[ -x %{_prefix}/bin/update-menus ] %{_prefix}/bin/update-menus || true
%postun
if [ "$1" = "0" ]; then
[ -x %{_prefix}/bin/update-menus ] %{_prefix}/bin/update-menus || true
fi
if [ -d %{prefix}/lib/gimp/1.1 ] rm -rf %{prefix}/lib/gimp/1.1
%post libgimp
/sbin/ldconfig
%postun libgimp
/sbin/ldconfig
%changelog
* Tue Jun 27 2000 John Cavan [EMAIL PROTECTED] 1.1.24-1mdk
- new version
- enabled the perl
- redefined the prefixing to more easily support relocation
* Wed Jun 21 2000 Lenny Cartier [EMAIL PROTECTED] 1.1.23-2mdk
- merge fixes from Jan Dittberner
- fix install
* Tue Jun 20 2000 Jan Dittberner [EMAIL PROTECTED] 1.1.23-1mdk
- 1.1.23
- add BuildRequires
* Thu May 04 2000 Geoffrey Lee [EMAIL PROTECTED] 1.1.21-1mdk
- 1.1.21
- remove segfault patch
- i can't believe we really used disable perl .. :-( :-(
* Thu Apr 27 2000 Thierry Vignaud [EMAIL PROTECTED] 1.1.20-2mdk
as Lords L. L. ask for help,
- fix compilation on Mandrake :-(
- various spec cleanups for rpmlint (invalid groups, post postun scripts,
...)
- new group scheme for libgimp
- use spechelper
- nearly 99% of the new doc has been forgotten in previous rpm: greaat...
* Wed Apr 26 2000 Geoffrey Lee [EMAIL PROTECTED]
- 1.1.20
- add patch to fix segfault
- _tmppath
- _prefix
- fix group
* Fri Mar 31 2000 Geoffrey Lee [EMAIL PROTECTED]
- removed obsoletes, it's stupid. used serial: 1 instead
- postun for gimp to remove the %{prefix}/lib/gimp/1.1 that's left behind
- 1.1.19
* Mon Mar 13 2000 Geoffrey Lee [EMAIL PROTECTED]
- provides: gimp
- add some compat symlinks
- obsolete old gimp packages to make upgrade painless
- add some old compat symlinks to provides
* Mon Mar 06 2000 Geoffrey Lee [EMAIL PROTECTED]
- renamed this package to hackgimp since this is devel
- add devel warning to package description
- changed the buildroot to include version
- use prefix define in files section
- patched to v 1.1.18
* Sat Feb 12 2000 Geoffrey Lee [EMAIL PROTECTED]
- version 1.1.17
* Thu Feb 03 2000 Thierry Vignaud [EMAIL PROTECTED]
- v1.1.16
* Thu Dec 09 1999 Thierry Vignaud [EMAIL PROTECTED]
- v1.1.13
* Thu Nov 25 1999 Thierry Vignaud [EMAIL PROTECTED]
- v1.1.12 (hoping that Lenny won't put his one above my RPM.
* Fri Nov 19 1999 Lenny Cartier [EMAIL PROTECTED]
- v1.1.11
- used SRPM provided by Jan Dittberner
# PDL.spec
%define name perl-PDL
%define real_name PDL
%define version 2.004
%define release 1mdk
Summary: perlDL, an efficient numerical language for scientific computing
Name: %{name}
Version: %{version}
Release: %{release}
Copyright: GPL
Group: Development/Perl
Buildroot: /var/tmp/%{nam
Re: [Cooker] [ANNOUNCE] New macros in rpm
Maybe I'm being a little dense here, but the original method would seem
to be much more generic.
John
Geoffrey Lee wrote:
can i use %update-menus for postun too?
If you have a package who need a menu entry, please don't use in %post
the :
%post
if [ -x /usr/bin/update-menus ];then
/usr/bin/update-menus
fi
or others variants, simply do :
%post
%{update_menus}
--
MandrakeSoft Inchttp://www.mandrakesoft.com
San-Francisco, CA USA --Chmouel
[Cooker] hackgimp revisited
1.1/gimpressionist/
%dir %{prefix}/share/gimp/1.1/gimpressionist/Paper
%dir %{prefix}/share/gimp/1.1/gimpressionist/Presets
%dir %{prefix}/share/gimp/1.1/gradients
%dir %{_prefix}/lib/perl5/site_perl/*/*/Gimp
%dir %{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp
%dir %{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/Lib
%dir %{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/Net
%dir %{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/UI
%{_prefix}/share/icons/mini/wilbur.xpm
%{_prefix}/lib/menu/gimp
%{prefix}/bin/gimp
%{prefix}/lib/gimp/1.1/plug-ins/*
%{prefix}/lib/gimp/1.1/modules/lib*.a
%{prefix}/lib/gimp/1.1/modules/lib*.la
%{prefix}/lib/gimp/1.1/modules/lib*.so
%{_prefix}/lib/perl5/man/man3/*
%{_prefix}/lib/perl5/site_perl/*/*/*.pm
%{_prefix}/lib/perl5/site_perl/*/*/Gimp/*
%{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/*.bs
%{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/*.so
%{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/Lib/*
%{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/Net/*
%{_prefix}/lib/perl5/site_perl/*/*/auto/Gimp/UI/*
%{prefix}/share/locale/*/LC_MESSAGES/*
%{prefix}/share/gimp/1.1/scripts/*
%{prefix}/share/gimp/1.1/fractalexplorer/*
%{prefix}/share/gimp/1.1/gfig/*
%{prefix}/share/gimp/1.1/gimpressionist/Presets/*
%{prefix}/share/gimp/1.1/gimpressionist/Brushes/*
%{prefix}/share/gimp/1.1/gimpressionist/Paper/*
%{prefix}/share/gimp/1.1/gradients/*
%{prefix}/share/gimp/1.1/palettes/*
%{prefix}/share/gimp/1.1/patterns/*
%{prefix}/share/gimp/1.1/brushes/*
%{prefix}/share/gimp/1.1/tips/*
%{prefix}/share/gimp/1.1/help/*/*/*/*/*.html
%{prefix}/share/gimp/1.1/help/*/*/*/*.html
%{prefix}/share/gimp/1.1/help/*/*/*.html
%{prefix}/share/gimp/1.1/help/*/*.*
%{prefix}/share/gimp/1.1/devel-docs/html/libgimp/*
%{prefix}/share/gimp/1.1/user_install
%{prefix}/share/gimp/1.1/gimprc
%{prefix}/share/gimp/1.1/gimprc_user
%{prefix}/share/gimp/1.1/gtkrc
%{prefix}/share/gimp/1.1/unitrc
%{prefix}/share/gimp/1.1/gimp_logo.ppm
%{prefix}/share/gimp/1.1/gimp_splash.ppm
%{prefix}/share/gimp/1.1/ps-menurc
%{prefix}/share/aclocal/gimp.m4
%{prefix}/man/man1/*
%{prefix}/man/man5/*
%doc AUTHORS COPYING ChangeLog INSTALL NEWS README TODO
%files devel
%defattr(-,root,root,0755)
%{prefix}/bin/gimptool
%{prefix}/include/libgimp/*
%{prefix}/include/gck/gck.h
%{prefix}/lib/lib*.a
%{prefix}/lib/lib*.la
%files libgimp
%defattr(-,root,root,755)
%{prefix}/lib/*.so*
%clean
%post
[ -x %{_prefix}/bin/update-menus ] %{_prefix}/bin/update-menus || true
%postun
if [ "$1" = "0" ]; then
[ -x %{_prefix}/bin/update-menus ] %{_prefix}/bin/update-menus || true
fi
if [ -d %{prefix}/lib/gimp/1.1 ] rm -rf %{prefix}/lib/gimp/1.1
%post libgimp
/sbin/ldconfig
%postun libgimp
/sbin/ldconfig
%changelog
* Tue Jun 27 2000 John Cavan [EMAIL PROTECTED] 1.1.24-1mdk
- new version
- enabled the perl
- redefined the prefixing to more easily support relocation
* Wed Jun 21 2000 Lenny Cartier [EMAIL PROTECTED] 1.1.23-2mdk
- merge fixes from Jan Dittberner
- fix install
* Tue Jun 20 2000 Jan Dittberner [EMAIL PROTECTED] 1.1.23-1mdk
- 1.1.23
- add BuildRequires
* Thu May 04 2000 Geoffrey Lee [EMAIL PROTECTED] 1.1.21-1mdk
- 1.1.21
- remove segfault patch
- i can't believe we really used disable perl .. :-( :-(
* Thu Apr 27 2000 Thierry Vignaud [EMAIL PROTECTED] 1.1.20-2mdk
as Lords L. L. ask for help,
- fix compilation on Mandrake :-(
- various spec cleanups for rpmlint (invalid groups, post postun scripts,
...)
- new group scheme for libgimp
- use spechelper
- nearly 99% of the new doc has been forgotten in previous rpm: greaat...
* Wed Apr 26 2000 Geoffrey Lee [EMAIL PROTECTED]
- 1.1.20
- add patch to fix segfault
- _tmppath
- _prefix
- fix group
* Fri Mar 31 2000 Geoffrey Lee [EMAIL PROTECTED]
- removed obsoletes, it's stupid. used serial: 1 instead
- postun for gimp to remove the %{prefix}/lib/gimp/1.1 that's left behind
- 1.1.19
* Mon Mar 13 2000 Geoffrey Lee [EMAIL PROTECTED]
- provides: gimp
- add some compat symlinks
- obsolete old gimp packages to make upgrade painless
- add some old compat symlinks to provides
* Mon Mar 06 2000 Geoffrey Lee [EMAIL PROTECTED]
- renamed this package to hackgimp since this is devel
- add devel warning to package description
- changed the buildroot to include version
- use prefix define in files section
- patched to v 1.1.18
* Sat Feb 12 2000 Geoffrey Lee [EMAIL PROTECTED]
- version 1.1.17
* Thu Feb 03 2000 Thierry Vignaud [EMAIL PROTECTED]
- v1.1.16
* Thu Dec 09 1999 Thierry Vignaud [EMAIL PROTECTED]
- v1.1.13
* Thu Nov 25 1999 Thierry Vignaud [EMAIL PROTECTED]
- v1.1.12 (hoping that Lenny won't put his one above my RPM.
* Fri Nov 19 1999 Lenny Cartier [EMAIL PROTECTED]
- v1.1.11
- used SRPM provided by Jan Dittberner
# PDL.spec
%define name perl-PDL
%define real_name PDL
%define version 2.004
%define release 1mdk
Summary: perlDL, an efficient numerical language for scientific computing
Name: %{name}
Version: %{version}
Release: %{release}
Copyright: GPL
Group: Development/Perl
Buildroot: /var/tmp/%{nam
Re: [Cooker] hackgimp and perl
Geoffrey Lee wrote: I went to rebuild the hackgimp RPM because it doesn't include the perl stuff in binary form and noticed your comments in the spec file. The they were my comments. however: i remember building on a box with gimp installed (stable) and it didn't bail out reason the perl stuff keeps bombing out is the shared libraries in the perl autoload directory link themselves to the older Gimp libraries rather than the new ones being built. The simple solution to the problem is to remove the older version of Gimp first, rebuild, then install. you have verified this ? Not directly with the RPM file. I first encountered the issue with a direct build of Gimp and sorted it out by removing all of the installed files, including the perl ones, and then rebuilding. I'm going to try the RPM today or tomorrow. I'm on the road with work today, so I may not get to it right away. John
Re: [Cooker] hack menu group
I agree, it very nicely indicates software that is in development mode and potentially quite unstable. It has my vote. John Chmouel Boudjnah wrote: Stefan van der Eijk [EMAIL PROTECTED] writes: [ creating a hack root menu group for hack*applis ] What do you think? Stupid idea, isn't it? good idea for me, but flepied is the last voice on this subject. -- MandrakeSoft Inchttp://www.mandrakesoft.com Pasadena, CA USA --Chmouel
[Cooker] So, if 7.1 is now final...
Is the code freeze off? It would be good if we could start packaging up some of the newer versions of the software that is out there. By the way, I tried the new installation (FTP'd, through a firewall on an ADSL connection) and I'd like to say that it went great. Two minor problems that I saw: 1. If you try install Netscape from Crypto after installing the normal version, it blows out. The installer may want to be a little smarter and uninstall the weak encryption version first. 2. When you create a normal user at install time it also creates a group that matches the user. That means I get john:john instead of john:users as would be expected. Easy to fix, but it's a goofy problem. Other than that, the install was smooth and the graphical installer is much better than before. Keep it up guys. John
Re: [Cooker] So, if 7.1 is now final...
Chmouel Boudjnah wrote: John Cavan [EMAIL PROTECTED] writes: 2. When you create a normal user at install time it also creates a group that matches the user. That means I get john:john instead of john:users this is the standard way on our distribution, a user has a group and after the administrator manage to set him on a different group. It may be the standard way on Mandrake, but it's not a standard way for Unix... it is unexpected behaviour and you do have a group labled "users" which I assume is for this purpose. It's not a big problem or anything, I just can't see the reason for doing it that way. The last thing any of us would want is a hundred different groups with the exact same name as the user IDs in the system. John
Re: [Cooker] So, if 7.1 is now final...
Chmouel Boudjnah wrote: John Cavan [EMAIL PROTECTED] writes: It may be the standard way on Mandrake, but it's not a standard way for Unix... it is unexpected behaviour and you do have a group labled it's the standard way on a Linux System see on a RH/Debian/Slack Fair enough, note I said Unix :o). I don't think they always did it that way, it appears to be a logic change in useradd. I find it odd that it was done that way, normally you shouldn't have to tell something to explicitly take system defaults... it should be the other way around. Anyways, I personally, and that's just personally, think it's the wrong way to do it, but as I said, it's not a big problem. I'll just have to remember to add -D or -n to useradd when creating users. :o) John
Re: [Cooker] So, if 7.1 is now final...
Geoffrey Lee wrote: patch the code yourself if youd on't like how it works :ppp No offense, but that's a crummy response to user feedback, a habit on this list I might add. Yes, I can patch the code, but that's not relevant to the discussion, nor can I do that during install. In actual fact, it's a question of NOT patching the code, as the "feature" has been added via a Redhat specific patch, take a look at the source RPM. I've been a Unix/Linux user for a long time and I spend a lot of time educating Windows users on the advantages of going with Linux, but it's less easy to do that when behaviour is counter-intuitive. The whole point of defaults is just that: defaults. It's EXPECTED behaviour of just about any software you encounter that the defaults are accepted in the absence of instructions to the contrary, otherwise why bother with defaults? The wrong answer, if we desire Linux to grow, is "patch the code". I can assure you that companies in the business of selling Linux want it to grow. Anyways, enough said. I don't plan to modify the RPM, it's a maintenance headache to keep doing that everytime an upgraded RPM comes down the pipe, so I'll deal with the behaviour. John
Re: [Cooker] So, if 7.1 is now final...
John Grange wrote: it is actualy very usefull because say you want user A to be able to access files in a dirrectory but you do not want the people in the users group to be able to access them, then you just set the gid of the dir to that users gid , it's not stupid it's very usefull and i find i use it very often on my server. I didn't say it wasn't useful, I said it was counter-intuitive. There's a difference here. As I noted, the defaults of the system are specified (see /etc/default/useradd) but ignored by the software. That is not the expected behaviour of software. The way I normally do the behaviour you mention is: chmod 0700 xxx That allows only the user and root to access it, and is the normal way of implementing Unix security permissions. Bear in mind that the inutuitive model comes from people migrating from both Windows and traditional Unix systems. John
Re: [Cooker] Graphical installer
Derek Wildstar wrote: On Thu, 25 May 2000, John Cavan wrote: Well now that input has been requested about improvements/additions... The graphical installer is nice and all, but it has a very irritating tendency to have treeviews disappear when expanded or collapsed, requiring some scrolling to bring it visible again. Fixing this would be a huge blessing for installation. And don't get me started on the colour scheme... ;o) I noticed this with 7.0 on several machines, but havn't experienced it on 7.1beta1 and higher...do you notice the same "disappearing" thing with 7.1 betas also? I haven't tried the latest beta installs, I usually update the RPMs directly. If it's fixed, bonus. :o) John
Re: [Cooker] Graphical installer
I don't think that you want to remove the choice of selecting individual, optional packages. What I recommend though is that you remove all required packages from the list, which should trim the info back a bit. John Denis HAVLIK wrote: :~The graphical installer is nice and all, but it has a very irritating :~tendency to have treeviews disappear when expanded or collapsed, :~requiring some scrolling to bring it visible again. Fixing this would be This tree had a major rewrite for 7.1 :~a huge blessing for installation. And don't get me started on the colour :~scheme... ;o) Actually, I would like to get some input on color scheme. I have a feeling that noone is really happy with it as it is, but noone offers anything better either. If you can put some examples of better collor schemes online (we cannot discuss colors withouth pictures), please do so. :~This will probably cause a flame war, but it may be better to take a :~slightly different approach to the package selection, more similar :~to the way Windows does it. Bear in mind that the Windows style does At the moment, we offer three ways of choosing packages: 1) you trust us to give you a nice set of packages. 2) step 1: you tell the installer what kind of packages you are interested in, and trust us that we know which packages go in which group step 2: by moving a slider left-right, you decide how many MB of packages you really want, and trust us to give you only "the best of" if you move the slider to the left. 3) you want to choose the packages individually I beleive that 1 and 2 are fine, but 3 is a kind of stupid with 1000+ packages. This is a major problem, but at the moment noone knows how to improve the process - we are completely open for sugestions here. cu Denis -- - Dr. Denis Havlikhttp://www.ap.univie.ac.at/users/havlik Mandrakesoft||| e-mail: [EMAIL PROTECTED] Quality Assurance (@ @)(private: [EMAIL PROTECTED]) ---oOO--(_)--OOo-
Re: [Cooker] Suugestion for new utility
The program you are looking for is called "tee". Hoyt wrote: There is a way to start a program that redirects the error messages to a text file. I' ve used it several times to debug X, but I always have to look it up. Couldn't it be put into a shell script called, for example, errlog, and then given the program name as the argument and have the text file written to /tmp as programnane.errlog ? A small utility such as this would go a long way toward aiding newbies in diagnosing problems. Hoyt -- * Tell me and I may forget, Show me and I may remember, Involve me and I will understand. *
[Cooker] Graphical installer
Well now that input has been requested about improvements/additions... The graphical installer is nice and all, but it has a very irritating tendency to have treeviews disappear when expanded or collapsed, requiring some scrolling to bring it visible again. Fixing this would be a huge blessing for installation. And don't get me started on the colour scheme... ;o) This will probably cause a flame war, but it may be better to take a slightly different approach to the package selection, more similar to the way Windows does it. Bear in mind that the Windows style does two things: 1. Reduces clutter 2. Provides a "comfortable look" to people migrating to Linux Never underestimate the value of the new user's prior experiences in their evaluation of something new. It's not to say I want a Windows look (shudder), but installation experiences in Linux can be painful enough for the average newbie, why make it worse? John -- * Tell me and I may forget, Show me and I may remember, Involve me and I will understand. *
[Cooker] Typo in unistd.h in glibc 2.1.3
Hi guys, Ran into a problem compiling the latest test kernels... the file /usr/include/unistd.h has a little typo on line 468: extern int execle`__P ((__const char *__path, __const char *__arg, ...)); But, AFAIK, it should be: extern int execle __P ((__const char *__path, __const char *__arg, ...)); Notice the backtick after "execle"? Causes a parse error for any program including the file, in this case the kernel... I don't know if this is in the glibc mainline or specific to Mandrake. John -- * Tell me and I may forget, Show me and I may remember, Involve me and I will understand. *
Re: [Cooker] Typo in unistd.h in glibc 2.1.3
That's what I have installed... weird. David BAUDENS wrote: John Cavan écrivit : Hi guys, Ran into a problem compiling the latest test kernels... the file /usr/include/unistd.h has a little typo on line 468: extern int execle`__P ((__const char *__path, __const char *__arg, ...)); [...] Seems fixed in Cooker (glibc-devel-2.1.3-5mdk) -- MandrakeSofthttp://www.mandrakesoft.com PARIS, FRANCE --David -- * Tell me and I may forget, Show me and I may remember, Involve me and I will understand. *
Re: [Cooker] Netscape 4.73 !!!
The 128 bit version is not yet available. :o( Does anyone know if the file name loss on directory changes still happens? That's one of the goofiest things I think I've ever seen. John Geoffrey Lee wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mircea Ciocan Sent: Saturday, May 06, 2000 5:45 PM To: cooker Subject: [Cooker] Netscape 4.73 !!! Subject stays in: ftp://ftp.netscape.com/pub/communicator/english/4.73/unix/supporte d/linux20_glibc2/ Did somebody work at some mandrakized rpms, it will be included in 7.1 ??? yes, i think it should be included, since there are some secuirty fixes. btw, what you are you doing logging in as root ? :) Mircea C. -- * Tell me and I may forget, Show me and I may remember, Involve me and I will understand. *
[Cooker] A dummy kernel spec
Hi all...
For those who care... this is a spec file for use in creating a dummy
kernel package. It's a minor irritant of
mine to continually use --nodeps on RPMs. :o)
To use it, create a source package, kernel.tar.bz2 with the following
files:
kernel-2.2.15/usr/doc/kernel/base
kernel-2.2.15/usr/doc/kernel/headers
Mine are zero length files created using "touch".
As I said, I don't know if anyone cares, but here it is...
John
%define name kernel
%define version 2.2.15
%define release 1mdk
Summary: Dummy kernel RPMs for those who are well past Mandrake...
Name: %{name}
Version: %{version}
Release: %{release}
Source0: %{name}.tar.bz2
Copyright: GPL
Group: System/Kernel
BuildRoot: %{_tmppath}/%{name}-buildroot
Prefix: %{_prefix}
%description
Dummy kernel package that fools the RPM database into believing
that the kernel is installed.
%package headers
Summary: Dummy kernel headers
Group: Development/Kernel
Requires: kernel
%description headers
Dummy kernel headers that allows you to fool the RPM database
into thinking you have the kernel packages installed.
%prep
%setup
%build
%install
rm -rf $RPM_BUILD_ROOT
mkdir $RPM_BUILD_ROOT
cp -R * $RPM_BUILD_ROOT/usr
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
/usr/doc/kernel/base
%files headers
%defattr(-,root,root)
/usr/doc/kernel/headers
%changelog
* Thu May 4 2000 John Cavan [EMAIL PROTECTED]
- Created dummy kernel packages
[Cooker] Re: [CHRPM] xinitrc-2.4.4-18mdk
Did the messed up call to WindowMaker make it in? RunWM looks for /usr/X11R6/bin/wmaker (.inst too) instead for /usr/bin/wmaker as the new RPMs have it located. John Frederic Lepied wrote: --=-=-= Name: xinitrc Distribution: Linux-Mandrake Version : 2.4.4 Vendor: MandrakeSoft Release : 18mdk Build Date: Tue Apr 11 07:53:26 2000 Install date: (not installed) Build Host: kenobi.mandrakesoft.com Group : System/XFree86Source RPM: (none) Size: 15519 Packager: Frederic Lepied [EMAIL PROTECTED] Summary : The default startup script for the X Window System. Description : The xinitrc package contains the xinitrc file, a script which is used to configure your X Window System session or to start a window manager. The xinitrc package should be installed if you use the X Window System. --=-=-= * Tue Apr 11 2000 Frederic Lepied [EMAIL PROTECTED] 2.4.4-18mdk - launch scripts in /etc/X11/xinit.d - removed imwheel stuff. -- http://www.linux-mandrake.com/en/cookerdevel.php3 -- * Tell me and I may forget, Show me and I may remember, Involve me and I will understand. *
