Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL,gimp, gimp1_3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thierry Vignaud wrote: |Given that gimp1_3 obsoletes gimp-data-min, and gimp provides |gimp-data-min, if rpm -U gimp1_3 doesn't want to uninstall gimp, I |think that would be a bug in RPM? | | they both provides/obsoletes it, so there's no bug there. And I think the gimp-data-min shouldn't be obsoleted/provided by gimp1_3, since this is an really old artifact from 1.0-1.2 days. If gimp-data-min package still exist for now, it won't conflict with gimp1_3, so there's not much point to provide/obsolete gimp-data-min in gimp1_3. |The main difference between the two lies in other packages' requirements. If |gimp-1.2 provides hackgimp, then other packages can depend on hackgimp when |they mean gimp = 1.1. I don't think this is a good thing. For one, it |pretty much fixes the definition of hackgimp to be gimp = 1.1 forever |(or at least until 1.4 comes out). For another, it's a bit weird conceptually |for hackgimp to mean the old 1.1 development tree rather than the |current development tree. | | the point is that we do not want to break updates. | we cannot change the past, only the future, so here's the hackgimp | definition. This is true, for gimp 1.2. But for 1.3, I guess we don't need to provide/obsolete hackgimp again. |but when do you upload those fixed packages (at least those |belonging to contribs) ? | |I already uploaded the .spec files, as I explained in the previous |message. I realize that the cooker submission instructions say to |upload the .src.rpm. | | it would just be easier if you send me the spec files for my packages Titi, would you mind if I'm submitting changes to you too? Beside the stuff Andy mentioned, I have heavily modified quite a lot of places so that many old artifacts from 1.1/1.2 days are gone, and bring back color modules etc. Abel - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Cex2QVLh8cZxhv8RAjpuAJ49HLNTTNQtTdWWgSGBhQQwhtnRYACfeHSQ UUlG6iqp3T56kirx1K2P/+I= =MsUv -END PGP SIGNATURE-
Re: [Cooker] Contrib packages: libsigc++1.0, libsigc++1.2, MySQL,gimp, gimp1_3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andi Payn wrote: | But, is it too late to remove gimp-data-min from gimp1_3 when it was provided | by the gimp1_3 package in 9.1 contribs? Never too late. Nothing requires gimp-data-min, except gimp itself. And it came from gimp-1.0/1.1 days. Abel |This is true, for gimp 1.2. But for 1.3, I guess we don't need to |provide/obsolete hackgimp again. | | Again, is it ok to remove hackgimp now when it was already in the 9.1 release | of gimp1_3? (The same test as above shows nothing in Cooker requires hackgimp | either.) - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Cf3dQVLh8cZxhv8RAl6hAKDBtYH0kE5UBoZkjX9M6p7JsyYHwQCcCGv4 /KxtORT3Fxzp/qBQFquWDPs= =eTxc -END PGP SIGNATURE-
Re: [Cooker] can the Gentium font be included in 9.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Helge Hielscher wrote: | today I read about the Gentum font in a newsgroup. It is located here: | http://www.sil.org/~gaultney/gentium/ and the samples look very good. | | But the licence may be to strict: Then such fonts would be PLF candidate. :-) Abel | These fonts may not be altered in any way, and can be distributed to | others only if the complete font archive remains unchanged and all | files are distributed together. They can be placed on web sites or | CD-ROMs as long as no cost is charged for their use. They may not be | 'bundled' with products for sale without my written permission. The | fonts are copyright 2002 Victor Gaultney. - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Cf5NQVLh8cZxhv8RAmz7AJ9GaMYHIvHKtmZrpv+VagdprTlP+ACfcmwE RyoKHpQ6nwkSxEb1FWRZt6I= =EMyq -END PGP SIGNATURE-
Re: [Cooker] pcre doesn't have UTF-8 support?
On 2003-07-04(Fri) 10:30:49 +0200, Gtz Waschk wrote: I'm trying to build regexxer http://regexxer.sourceforge.net/ and it's spewing errors. Anyone know if pcre can be rebuild with UTF-8 support for cooker please? This shouldn't be a problem, just add --enable-utf8 to the configure call. I hope it doesn't break grep, but I doubt that it will cause any I think it won't affect anything unless you are using perl regex mode in grep (grep -P). Abel harm. The readme says it also has to be enabled at runtime. CU -- What difference does it make to the dead, the orphans and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty or democracy? Mahatma Gandhi (1869 - 1948), Non-Violence in Peace and War -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] kernel-2.4.21.3mdk-1-1mdk
On 2003-07-05(Sat) 13:24:01 -0500, Tom Brinkman wrote: All kernels testbooted with 2 systems: - one nForce2 system with 1GB ram (running enterprise now...) - ond dual P2-333 with 256MB ram (running secure now...) Wouldn't boot successfully for me, hung on Finding module dependencies Nothin I tried (Alt-SysRq-E) would get it to finish, just a spontaneous reboot. Even worse, my previous kernels wouldn't boot either, hanging on Finding module... in the same way. I guess this problem comes from initscript 7.06-13mdk; I have no luck booting, seeing the same error as you do. But after copying /sbin/initlog and /sbin/minilogd from 9.1 partition, it boots perfectly. == [EMAIL PROTECTED] root]# LC_TIME=C rpm -q --changelog initscripts| head * Mon May 26 2003 Frederic Lepied [EMAIL PROTECTED] 7.06-13mdk [...] - allow minilogd to open /dev/log as a STREAM (Andrey Borzenkov) [...] == Andrey, is there something to do with the patched minilogd? Abel So I did a 9.1 install formatting /boot and /. Then I installed 2421-3 and it booted jus fine. After resyncing to current cooker using urpmi --auto-select, 2421-3 would then still successfully boot. So I'm usin it, jus took me two hours to get it goin ;) -- Tom Brinkman Corpus Christi, Texas -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] initscripts-7.06-13mdk breaks pcmcia
On 2003-07-05(Sat) 18:41:30 +0200, Gtz Waschk wrote: That initscripts package seems to be really buggy as I couldn't even boot with 13mdk. It hung during the depmod part. I also had to revert to 12mdk. Probably you can try using /sbin/minilogd from -12mdk? Abel -- What difference does it make to the dead, the orphans and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty or democracy? Mahatma Gandhi (1869 - 1948), Non-Violence in Peace and War -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] WARNING: .so problems
On 2003-07-03(Thu) 08:22:12 +0200, Michael Scherer wrote: But Charles, upgrading to 1.5 can mean a lot of trouble too. Yes, sooner or later we will move on, but for now, you have do these steps when building stuff with libtool 1.5, if software was bundling libtool 1.4: %{_libtoolize} -c -f aclocal autoconf maybe i am saying something dump, but, what about adding these steps to the %configure macro ? I would have suggested it if it's possible. But you will see such variants when executing aclocal and autoconf: aclocal-1.7 aclocal-1.4 aclocal -I /usr/share/aclocal/something WANT_AUTOCONF_2_5=1 autoconf WANT_AUTOCONF_2_1=1 autoconf Everything can be different on each package. Sometimes different automake and autoheader calls may be inserted in between too. But note that if the software is already bundling libtool 1.5, then nothing other than libtoolize is needed. I want to grind autotool maintainers into powder. :) Abel Of course, the whole process of rebuilding will be slower. This is not much, but, for each package, this can be significant. -- Mickal Scherer -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] WARNING: .so problems
On 2003-07-03(Thu) 08:22:12 +0200, Michael Scherer wrote: Argh, Michael, next time can you quote others' words more completely? Abel maybe i am saying something dump, but, what about adding these steps to the %configure macro ? Of course, the whole process of rebuilding will be slower. This is not much, but, for each package, this can be significant. -- Mickal Scherer -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
[Cooker] Re: [Contrib-Rpm] crossfire-server-1.5.0-1mdk
On 2003-07-03(Thu) 17:15:59 +0200, Austin Acton wrote: Name: crossfire-server Relocations: (not relocateable) Version : 1.5.0 Vendor: MandrakeSoft Release : 1mdk Build Date: Thu Jul 3 16:48:43 2003 --=-=-= * Thu Jul 03 2003 Austin Acton [EMAIL PROTECTED] 1.5.0-1mdk - prereq rpm-helper Austin, actually it's intentional that I don't add it; this dependency was not necessary. rpm already prereq'ed rpm-helper, that means basesystem has already included it. Actually I'd suggest flepied to remove this warning in rpmlint... Abel - from Abel Cheung [EMAIL PROTECTED]: - 1.5.0 - Update init script (use gprintf) - Update patch0 - Rename this package to crossfire-server to avoid confusion -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] so problems
On 2003-07-02(Wed) 22:50:46 +0200, Guillaume Cottenceau wrote: I have two packages now that if I configure with: ./configure I get the right filenames: libname.so libname.so.0 libname.so.0.0.0 But rpm uses: ./configure i586-mandrake-linux-gnu and the filenames become: libname libname.0 libname.0.0.0 Sounds like something to do with libtool 1.5. Try defining __libtoolize to /bin/true and try again? Abel s/%configure/%configure2_5x/ ? -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/ -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
[Cooker] WARNING: .so problems
On 2003-07-02(Wed) 17:40:24 -0400, Charles A Edwards wrote: That's fine if it works. But why not upgrade the distros libtool to 1.5? (gc, don't know if you can spare some time for libtool package, I have virtually modified ALL patches so they do the right thing now) But Charles, upgrading to 1.5 can mean a lot of trouble too. Yes, sooner or later we will move on, but for now, you have do these steps when building stuff with libtool 1.5, if software was bundling libtool 1.4: %{_libtoolize} -c -f aclocal autoconf Here, aclocal is for picking up the right libtool.m4 macros, and autoconf is for including these correct macros into ./configure. Otherwise, libtool won't be generated correctly, and you'll see lots of error or warning messages when executing libtool. This serves as alert message to everybody as well, since we will be facing it some time later. Abel WE have abundant quantities of betas, alphas and hacks, but a basic program that has been the stable release for 3 months, We do not have. Charles P.S. I have built and installed libtool-1.5 on 1 of my systems so that I can at least make use of it's functionality for my personal builds. -- There is always a way, and it usually doesn't work -- Murphy's Military Laws n94 - Mandrake Linux 9.2 on PurpleDragon Kernel- 2.4.21-0.1mdk http://www.eslrahc.com - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] gettext and libiconv.so.2
On 2003-07-01(Tue) 09:22:25 -0400, Charles A Edwards wrote: to do so :). Pablo, would you like becoming official maintainer of gettext? It would be more sensible than myself I guess.. Someone please do so. I am currently using gettext-0.12.1 as CVS sylpheed-claws now requires it. If we do not have 'official' get text rpms for 0.12.1 by the time of the nearing new claws release I will be unable to upload it. Yes, I'm waiting for it to have xgettext generate po files with UTF-8 msgid too. :) Abel Charles -- Smoke was coming out of the stricken piano. The Librarian's hands were walking through the keys like Casanunda in a nunnery. (Soul Music) - Mandrake Linux 9.2 on PurpleDragon Kernel- 2.4.21-0.1mdk http://www.eslrahc.com - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] gettext and libiconv.so.2
On 2003-06-27(Fri) 17:27:03 -0400, Charles A Edwards wrote: Yes, the stock libtool 1.5 has just partially fixed the DESTDIR issue. Now at least stuff can build successfully even if no preinstalled libraries were present, but if you have preinstalled older libraries, then these old libraries in system library path will be picked up during relinking stage. Nasty. Not sure what you mean. Are you speaking of the build or the performance of the resulting rpms? Building. Using libtool-1.5, built from a mdkized rh spec, I do not have any problem building gettext-1.2 with all other libs and apps being current cooker. The problem occurs when there is gettext 0.11.x preinstalled. You can run into trouble (the resulting gettext 0.12.1 requires gettext 0.11.x libraries). That's the result I got with the stock libtool 1.5. When calling libtoolize (thus have libtool 1.4.3 overwriting the stock 1.5), libraries won't have any .so extension. BTW why is there not a mdk pkg for libtool-1.5? It been the stable release since April. Don't tell me we are planning to release 9.2 still with 1.4.3. Who knows. Abel Charles -- Laetrile is the pits. - Mandrake Linux 9.2 on PurpleDragon Kernel- 2.4.21-0.1mdk http://www.eslrahc.com - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] gettext and libiconv.so.2
On 2003-06-28(Sat) 16:20:50 +0800, R.I.P. Deaddog wrote: The problem occurs when there is gettext 0.11.x preinstalled. You can run into trouble (the resulting gettext 0.12.1 requires gettext 0.11.x libraries). That's the result I got with the stock libtool 1.5. If words are not clear enough, let's see command output under buildroot: [EMAIL PROTECTED] src]$ cd ~/rpmdevel/tmp/gettext-0.12.1-buildroot/usr/lib/ [EMAIL PROTECTED] lib]$ ldd libgettextpo.so libgettextsrc-0.11.5.so = /usr/lib/libgettextsrc-0.11.5.so (0x40014000) libgettextlib-0.12.1.so = not found libc.so.6 = /lib/i686/libc.so.6 (0x40032000) libgettextlib-0.11.5.so = /usr/lib/libgettextlib-0.11.5.so (0x40173000) libintl.so.2 = /lib/libintl.so.2 (0x40182000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) [EMAIL PROTECTED] lib]$ LD_LIBRARY_PATH=/home/deaddog/rpmdevel/tmp/gettext-0.12.1-buildroot/usr/lib ldd libgettextpo.so libgettextsrc-0.11.5.so = /usr/lib/libgettextsrc-0.11.5.so (0x40014000) libgettextlib-0.12.1.so = /home/deaddog/rpmdevel/tmp/gettext-0.12.1-buildroot/usr/lib/libgettextlib-0.12.1.so (0x40032000) libc.so.6 = /lib/i686/libc.so.6 (0x40042000) libgettextlib-0.11.5.so = /usr/lib/libgettextlib-0.11.5.so (0x40183000) libintl.so.2 = /lib/libintl.so.2 (0x40192000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) Abel When calling libtoolize (thus have libtool 1.4.3 overwriting the stock 1.5), libraries won't have any .so extension. BTW why is there not a mdk pkg for libtool-1.5? It been the stable release since April. Don't tell me we are planning to release 9.2 still with 1.4.3. Who knows. Abel Charles -- Laetrile is the pits. - Mandrake Linux 9.2 on PurpleDragon Kernel- 2.4.21-0.1mdk http://www.eslrahc.com - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] kernel-2.4.21-0.0.1mdk-1-1mdk
On 2003-06-28(Sat) 13:28:14 +0200, Stefan van der Eijk wrote: I guess everybody in this thread was trying to boot the kernel on an AMD based machine. Is this correct? Have people been able to boot this kernel? On which CPU? I've got the same error too, on a Pentium 3 mobile. Abel Stefan This (enterprise-) kernel doesn't want to boot on my box (Asus NForce2, AMD althonXP, 1.5Gb). It panics before init message is shown on the screen. Anybody else? regards, Stefan --=-=-= * Tue Jun 24 2003 Juan Quintela [EMAIL PROTECTED] 1-1mdk - update cpufreq to 2.4.22-1 snapshot. - update bootsplash to 3.0.7 (make warly happy). - update andrea VM to rc8aa1. - acpi 20030523. - disabled several options - bcm4400 2.0.0 (thanks ronin). - 2.4.21-final. --=-=-= E: kernel-2.4.21-0.0.1mdk invalid-spec-name kernel-2.4.spec --=-=-= --=-=-= -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] gettext and libiconv.so.2
On 2003-06-28(Sat) 09:42:48 -0400, Charles A Edwards wrote: That,s not the output I get. You might want build libtool-1.5 using the patches from the rh libtool-1.5-3.src.rpm ( gc, do you have time to upgrade gettext and libtool packages? ) Charles, why don't you tell me earlier :) I have checked it; it's the approach I used when patching libtool 1.4.2 in mandrake package; but later I found it wrong. It just put the -L$DESTDIR/usr/lib argument _after_ all other -L arguments, and let libtool re-re-re-re-revert it until it becomes first argument. But somehow some packages still manage to get the library path order wrong. I have made another libtool patch in gettext package below that IMO does the right thing; after all the reverting of arguments is done, it puts -L$DESTDIR/usr/lib unconditionally in front of all other arguments. I've put up another package that corrects other patches and have java stuff splitted. Now only the LSB/Li18nux conformance patch is not integrated. To make msgfmt fully comply with LSB 1.3, some more work is needed. If you have time, may you try http://deaddog.org/files/Mandrake/enhancement/SRPMS/gettext-0.12.1-0.1mdk.src.rpm Abel [EMAIL PROTECTED] charles]$ cd /home/charles/rpm/tmp/gettext-0.12.1-buildroot/usr/lib [EMAIL PROTECTED] lib]$ rpm -q gettext gettext-base gettext-devel libintl2 gettext-0.11.5-6mdk gettext-base-0.11.5-6mdk gettext-devel-0.11.5-6mdk libintl2-0.11.5-6mdk [EMAIL PROTECTED] lib]$ ldd libgettextpo.so libgettextsrc-0.12.1.so = not found libgettextlib-0.12.1.so = not found libc.so.6 = /lib/i686/libc.so.6 (0x4001d000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) [EMAIL PROTECTED] lib]$ LD_LIBRARY_PATH=/home/charles/rpm/tmp/gettext-0.12.1-buildroot/usr/lib ldd libgettextpo.so libgettextsrc-0.12.1.so = /home/charles/rpm/tmp/gettext-0.12.1-buildroot/usr/lib/libgettextsrc-0. 12.1.so (0x40003000) libgettextlib-0.12.1.so = /home/charles/rpm/tmp/gettext-0.12.1-buildroot/usr/lib/libgettextlib-0. 12.1.so (0x40027000) libc.so.6 = /lib/i686/libc.so.6 (0x4005) libintl.so.2 = /lib/libintl.so.2 (0x40191000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) Charles -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] gettext and libiconv.so.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles A Edwards wrote: | When trying to build gettext-12.1, or even rebuilding the current | cooker gettext-0.11.5-6mdk.src.rpm the build fails because | libiconv.so.2 can not be found. AFAIK libiconv was only needed for those platforms which don't have native iconv(), isn't it? Abel | Unless I have missed something there are no libiconv rpms and no current | pkg includes any libiconv.so*, though glibc-devel does contain | libiconv.h | | I can pkg libiconv-1.8 and the gettext build will successfully | complete but how is that the Mdk build of gettext is able to be done? | The last update for it was Jun 03 by Stew Benedict. | | As I said I may just be missing something but I would be most grateful | if someone could enlighten me as to what it is. | | | Charles | - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE++y/gQVLh8cZxhv8RAh4WAJ9a474vvJ2OOrkM28+JlOwoxwxGngCgmKpD 2jAIpAhLS8979pQtUJN2i0s= =wrAp -END PGP SIGNATURE-
Re: [Cooker] gettext and libiconv.so.2
On 2003-06-24(Tue) 14:04:40 -0400, Charles A Edwards wrote: Well I did not save the errors when they happened and today when I tried to reproduce, the build had no problems. Go figure. ... If you have preinstalled 0.12.1 before building? I was trying to make big modification to gettext spec (cleanup, split java subpackage etc), and submit to gc afterwards for review. Gettext package really needs some love now. Are you working on 0.12.1? I had to use libtoolize --copy --force autoconf for the libs to build properly. Yes, the stock libtool 1.5 has just partially fixed the DESTDIR issue. Now at least stuff can build successfully even if no preinstalled libraries were present, but if you have preinstalled older libraries, then these old libraries in system library path will be picked up during relinking stage. Nasty. Worse yet, this problem has been reported by many people, but still ignored in libtool list. Abel Charles -- Before marriage the three little words are I love you, after marriage they are Let's eat out. - Mandrake Linux 9.2 on PurpleDragon Kernel- 2.4.21-0.1mdk http://www.eslrahc.com - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] gettext and libiconv.so.2
On 2003-06-22(Sun) 13:52:05 -0400, Charles A Edwards wrote: When trying to build gettext-12.1, or even rebuilding the current cooker gettext-0.11.5-6mdk.src.rpm the build fails because libiconv.so.2 can not be found. After sending I realized what was causing this. The gettext.spec runs %configure2_5x --enable-shared --with-included-gettext but it should be %configure2_5x --enable-shared --with-included-gettext --without-java Charles, can you let me see the related error messages? I was trying to make big modification to gettext spec (cleanup, split java subpackage etc), and submit to gc afterwards for review. Gettext package really needs some love now. Abel Without that addition at configure, if gcc-java is installed, the default is to build with java which does require that libiconv.so.2 be present. -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] gweather-applet still not working for now a few weeks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olivier Blin wrote: |Evolution weather informations are working well. | | Do you know the url of the xml file used by Evolution ? | We could make a temporary patch to fix this problem. That's not so simple. Currently evolution weather reporting code is the same as what gweather used in gnome-applets 2.2.x. Since then, gweather undergoes a big rewrite, so gweather from gnome-applets 2.3.x is completely different. The incerceptvector.com info is XML, while the one in weather.noaa.gov (yes, evolution and gweather 2.2.x use it) is text. Abel | | Olivier Blin | - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+8yG7QVLh8cZxhv8RAuOSAJ0XD6GaPxFxL4pljHu4V0+ZUetfVACfbGWQ 3EIynsGF3a7/dXAnBBXTqGY= =RkEu -END PGP SIGNATURE-
Re: [Cooker] Re: [Contrib-Rpm] abiword-1.0.6-1mdk
On 2003-06-17(Tue) 15:48:40 +0200, Marcel Pol wrote: Yes, it has just been fixed, bug in rpm fixed in rpm-4.2.1 with backport to original rpm. Thanks. I guess this was already covered in another thread. I should probably read better. It still leaves me with my question about update-alternatives. Not confirmed, but my bet is: since /usr/bin/abiword is present in 1.0.4 but not 1.0.6 in %%files, rpm removes the files AFTER update-alternatives is run. That is, after running postin script in new package, it goes ahead to remove all non-existant (which it thinks so) files in the old package. Is it so, fpons? Abel -- Marcel Pol -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] [Bug 4046] [kdebase] Taiwan's and Mainland China's flagsall are shown on the Country list.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Han Boetes wrote: | If we keep a neutral stance and keep the taiwanese flag we will be | boycotted anyway. (This is a reply to everybody, not only to Han) The situation is 1. If it's just average joe downloading MDK from mirrors, then those Chinese officials don't care. Mandrake doesn't need to do anything, and there's no reason to do anything. 2. If Mandrake wants to sell it commercially in mainland China like RH do, then need to provide a no-flag kdebase/kdelibs in boxset sold in mainland China, to avoid problem. I'm not sure why everybody keeps blowing hot air to this subject, without considering that what Mandrake concerned most is market share and profit for now. Whether this 'problem' should be fixed or not depends on Mdk sales and marketing decision, and not on any single person's supporting/opposition of any politics. Abel | | | | # Han - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+6Ya7QVLh8cZxhv8RAkF/AJ4hl6cjgPteOWQW4unvnqVEc97R1wCff50P GQz8Psp1aXic2sWU76Gb2WY= =Nkz8 -END PGP SIGNATURE-
Re: [Cooker] Re: [Contrib-Rpm] gnome-themes-extras-0.1-1mdk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Götz Waschk wrote: | Ximian has a special copyright on it's logos (like many other free | software companies): | http://www.ximian.com/about_us/policies/copyrights.html | | This includes the evolution logo. IANAL but if Mandrake didn't need a | permission to distribute evolution, they don't need one for | ximian-artwork. I think fred is mostly talking about respecting Ximian, more than any specific license issue. Abel - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+6ihXQVLh8cZxhv8RAmlsAJ9xWnqbi1ZA3ftRFMyT4hXKTfXxWwCgzVlF q9Gw5ClQib4m03N77QAnAPo= =nRHo -END PGP SIGNATURE-
Re: [Cooker] [Bug 4046] [kdebase] Taiwan's and Mainland China's flagsall are shown on the Country list.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brant Fitzsimmons wrote: | Morals and ethics be damned as long as you have have a healthy bottom | line. Isn't there another large software company that takes that same | approach. If it's not correct for them to do it... | | There is a reason some of us use and promote free (as in freedom) | software and it's not to cater to those who would take that freedom away. | | Don't like dealing with politics--move to another planet. Not sure why you take the opposite of what I mean and criticize on this opposite meaning. This is funny. I wonder if you have simply read the last line and guess this is all I said, and reply to this last line only. We're living in an ugly world; especially in some places where politics can override virtually everything (including thoughts, ideals, etc), you have to comply to its rules. But if you're not playing the game, you needn't obey it's rule at all. This is the case here. If Mandrake wants to go into Chinese markets, it really need to remove flags in boxsets sold to chinese market; otherwise nothing need to be done. This rule applies even when any company wants to sell any commercial products. The problem has nothing related to freedom at all. Imagine when Mandrake wants to sell boxsets to England, while displaying bold words on its installer: Her Majesty is a bitch. You will be sure that such product can't be sold to England. Don't know why everybody wants to express themselves without knowing the root of the problem. That's _interesting_. Abel - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+6kRVQVLh8cZxhv8RAkH1AKCNsUBLKzRbskrrz/LmaySOtg808QCgmIue slrrvAGkSBjhUEay8F2fUk0= =q7LF -END PGP SIGNATURE-
Re: [Cooker] [Bug 4046] [kdebase] Taiwan's and Mainland China's flags all are shown on the Country list.
On 2003-06-12(Thu) 13:15:11 +0800, Leon Brooks wrote: On Thu, 12 Jun 2003 12:39, Gary L. Greene wrote: This bug is about the removal of a (albet not recognized officiailly) democratic nation's flag from the distribution. While this is an issue to the communist Chinese government, I loath the idea of not supporting a nation's people that have chosen free choice over another form of government. 1) I am not a mdk employee. 2) IANAL. 3) I don't live in mainland China, so what I say can possibly be wrong. Dunno about Mandrake's official position, but I bet it's been installed in both places already. I'd be tempted to leave it in unless/until China asks us to remove it (even via a distributor). While it won't, unless Mandrake wants to _actively_ enter mainland Chinese market. But the GB18030 encoding compliance can be a big obstacle. Given that China already have Red Flag Linux apparently run by the Chairman's son, I don't know that China will be offically happy about other Linuces anyway. Probably Red Flag is still being announced as a semi-official distro in China, but it doesn't receive much official support from PRC now. The favorite distro among mainland China people is RH. Abel Cheers; Leon -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] [Bug 4046] [kdebase] Taiwan's and Mainland China's flags all are shown on the Country list.
On 2003-06-12(Thu) 00:39:54 -0400, Gary L. Greene wrote: 2003-12-06 06:22 --- Everything simply depends on whether Mandrake will enter Chinese market in the future. If they won't (which seems to be the case), then this issue can be ignored completely. Otherwise, flags gotta be removed completely to avoid future trouble. Political issues are NOT FUNNY. before I begin, I've CC'd this message to deaddog, since I don't know if he's on the Cooker ML. I apologize if you are and for this action to the list. No need to Cc, I'm on cooker list. I'm bringing this conversation to the main mailing list to better get the opinion of the Mandrake people and the community at large. This bug is about the removal of a (albet not recognized officiailly) democratic nation's flag from the distribution. While this is an issue to the communist Chinese government, I loath the idea of not supporting a nation's people that have chosen free choice over another form of government. What is the position of the MDK employeees on this one? Will it be left in, or shall it be removed, as RH did a several months previously, which got them blasted for it by a section of the free software community? This problem isn't even remotely related to free software. Any reasoning about free software means nothing here. In those days, RH wants to actively enter both Chinese markets (mainland and Taiwan). Of course, the mainland side complains that Taiwan flag is seen in RH product, and they want it removed. And RH do it. Otherwise, they obviously won't be able to sell it officially at all in mainland China. But after Taiwan flag removal, RH becomes the target of Taiwan people, which you knew already (the complaint bombardment). In order to please both sides, RH choose to remove ALL flags altogether, to show it's fairness. Yet, all these things happen because RH want to enter Chinese market. If Mandrake doesn't, then why care about it? Abel I will not continue this conversation any further, if it's wished. However, I want the input of the cooker community about this. - -- Gary L. Greene, Jr. Sent from 12:26am up 5 days 22:39, 4 users, load average: 0.30, 0.37, 0.16 Founder and president of the Grand Valley Linux Users Group. -=http://www.gvlug.org=- Chief Systems Architect, SSC Limited, Inc. - OS Department. PHONE : 331-0562 EMAIL : [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+6AQdyPw381UL7WcRAvDsAJ9KCX7XpFwNvaL9yrbE+lCln0Bz0gCbB46w /mSVd+RxpgqzJS4TyJywgKw= =q8rR -END PGP SIGNATURE- -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] guile-compat-1.4.1-5mdk
On 2003-06-09(Mon) 18:38:19 +0200, Stefan van der Eijk wrote: You should test if the applications that use these libraries still run with your newest package. I've tested it with beast and glame. Seem to run fine. Oh. What Gtz want to ask is, whether apps runs fine *when they are using the functionalities that need guile*. Abel Stefan -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Mandrake's Gimp has a big bug!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ricardo Cruz wrote: | Hi, | | I'm new here and I would like to report a bug. Probabily it was already | reported. If this bug is specific to Mandrake (you found that no such problem exists in other distro), then you can report it in qa.mandrakesoft.com. Otherwise, you'd like to subscribe to gimp mailing lists and report it, or report it on bugzilla.gnome.org. Abel | Anyway by the Gimp version that is delivered in the Mandrake 9.x (both 9.0 | and 9.1 has this problem) has a big bug: | If you draw single pixels with a big zoom, it will not display the image | correctly until you refresh the window! | | This is real an huge bug to artists, and I don't know why hasn't it been | fixed, or isn't any artist using Mandrake? | | Ricardo Cruz | - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+5OOhQVLh8cZxhv8RApP9AKDKXROcvz/dKGhrnc0hA89i7nfJxACgu3yj g87X3KCqsWRkIwiMuvjnRvw= =TprJ -END PGP SIGNATURE-
Re: [Cooker] bad rpms still in contrib from before 5-28-03
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Salane King wrote: | These rpms are still bad in cooker/contrib | contrib/i586/crossfire-client-gtk-1.0.0-4mdk.i586.rpm | contrib/i586/crossfire-client-sounds-1.0.0-4mdk.i586.rpm | contrib/i586/crossfire-client-x11-1.0.0-4mdk.i586.rpm Argh, sorry, actually I have already updated it. But who can I submit to? (I don't want to dump it into /incoming) Abel - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+5Qs2QVLh8cZxhv8RAgrsAKCvQSORE+/5puXnFaqgqUlsBfc46ACeMqpo RieOFUzeMLbD0UqjN6t94Gg= =Qqb/ -END PGP SIGNATURE-
Re: [Cooker] debug files in normal packages
On 2003-06-08(Sun) 01:34:07 +0200, Olivier Thauvin wrote: Is it possible to have an automatic macros in rpm which make: %exclude %_libdir/debug Somes specs have in %files: %_libdir/* and rpm stupidly include debug files ! Of course, automatic exclusion would be nice too, but badly packaged RPMs should also be fixed too. Sure, but how do you fix a non existing issue, this appears only because rpm made debug package now. This dir is created by rpm itself. It's the glob. For better packaging, you would at least use something like %{_libdir}/%{name} %{_libdir}/whatever while %_libdir/* is not much better than using %files /* Abel Abel -- Linux pour Mac !? Enfin le moyen de transformer une pomme en vritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/ -- Linux pour Mac !? Enfin le moyen de transformer une pomme en vritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/ -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] debug files in normal packages
On 2003-06-08(Sun) 12:41:07 +0200, [EMAIL PROTECTED] wrote: while %_libdir/* is not much better than using %files /* It's much better. /* would own many directories owned by other packages (mainly filesystem), whereas for any package that doesn't have lib subpackages, %_libdir/* is perfectly valid, as it will only own files the package should own. OK, our opinion about quality are too different, I think we shouldn't discuss about that anymore. I don't want to go into heated argument. BTW, is there actually any real use for these debug packages. I had a samba3-debug package (containing benchmark/validation tools), which I now had to rename, and add provides/obsoletes for also. They could at least have chosen a better name (-rpm_debug or something) which is guaranteed not to conflict with other package names ... You can use %define _enable_debug_packages 0 to avoid it for now. Abel Buchan -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] debug files in normal packages
On 2003-06-08(Sun) 16:47:37 +0200, [EMAIL PROTECTED] wrote: You can use %define _enable_debug_packages 0 to avoid it for now. I don't like making uninformed decisions, which is why I asked the question above. But IMHO this is a bug in rpm, they should use a name which is guaranteed not to conflict with any other potential subpackages. It's been a royal waste of time so far, and I don't see any benefits yet Neither do I. Probably because I don't know the intention of creating those debug info yet. Is this something new from stock rpm 4.2? If so, I'd guess the name debug is chosen because Red Hat don't use this as package name. Abel -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
[Cooker] Does find-requires has AI?
Hi all, This is what I get when I'm trying to make gtranslator package (GNOME2 port): = + cp -pr AUTHORS COPYING ChangeLog DEPENDS INSTALL NEWS README THANKS TODO /home/maddog/rpmdevel/tmp/gtranslator-0.99-buildroot/usr/share/doc/gtranslator-0.99 + exit 0 Finding Provides: /usr/lib/rpm/filter.sh ' ' /usr/lib/rpm/find-provides Using BuildRoot: /home/maddog/rpmdevel/tmp/gtranslator-0.99-buildroot to search libs Finding Requires: /usr/lib/rpm/filter.sh ' ' /usr/lib/rpm/find-requires /home/maddog/rpmdevel/tmp/gtranslator-0.99-buildroot i586 error: line 137: Dependency tokens must begin with alpha-numeric, '_' or '/': - Using spec file from src package for gtranslator-0.39.2-1 for RedHat = Even the spec file in source tarball is updated to 0.99! Abel -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Does find-requires has AI?
On 2003-06-08(Sun) 17:52:27 +0200, Oden Eriksson wrote: /home/maddog/rpmdevel/tmp/gtranslator-0.99-buildroot i586 error: line 137: Dependency tokens must begin with alpha-numeric, '_' or '/': - Using spec file from src package for gtranslator-0.39.2-1 for RedHat = Even the spec file in source tarball is updated to 0.99! Check for errors in the changelog section on line 137 in your spec file. Yes, I looked stupid. Time to file a bug too, find-requires is searching inside changelog for dependency info. Abel -- Regards // Oden Eriksson, Deserve-IT.com -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] debug files in normal packages
On 2003-06-07(Sat) 05:14:47 +0200, Olivier Thauvin wrote: Is it possible to have an automatic macros in rpm which make: %exclude %_libdir/debug Somes specs have in %files: %_libdir/* and rpm stupidly include debug files ! Of course, automatic exclusion would be nice too, but badly packaged RPMs should also be fixed too. Abel -- Linux pour Mac !? Enfin le moyen de transformer une pomme en vritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/ -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] find_requires script don't take to statically linked obj
On 2003-06-05(Thu) 09:17:13 +0200, Gtz Waschk wrote: Am Donnerstag, 5. Juni 2003, 03:58:38 Uhr MET, schrieb R.I.P. Deaddog: On 2003-06-03(Tue) 10:58:42 +0200, Gtz Waschk wrote: it would be nice if the find_requires script would parse the dependancies of static libraries, but how to do this? It's easy to find out the dependant libs of shared libraries, but AFAIK shared libraries only contain information about which symbols are unresolved, but no information on where to get that symbols. Has anyone thought Yes, I discussed with Stefan about static lib dependency too, and don't have any conclusion about it. Here are the possible difficulties: For any missing symbol in one static lib, we can possibly find more than one matches in other static libs. Besides, searching through ALL static libs in one machine to find matches is very time consuming, and (unconfirmed) possibly give different results in different machines. This is not unsolvable, for example, by recording all missing symbols of static libs somewhere, and grep the lists of symbols instead. I have a conjecture: dependency of static libs must be a subset of dependency of dynamic libs. Will it be simpler if my guess is true? Abel Seems you can obtain dependency info via objdump too: [EMAIL PROTECTED] lib]$ objdump -p /usr/lib/libqtmcop.so.1 | grep NEEDED Arrgh, that was a typo, I wanted to write 'AFAIK static libraries only contain ...'. -- What difference does it make to the dead, the orphans and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty or democracy? Mahatma Gandhi (1869 - 1948), Non-Violence in Peace and War -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] automake-1.4 vs. automake1.7
On 2003-06-05(Thu) 23:27:54 +0200, Stefan van der Eijk wrote: Eventually we came to the following conclusion: - removing Provides: automake from automake1.7 (my preference) was not prefered; In my not so humble opinion, no package should ever require automake without indicating the version. In current way foobar: BuildRequires automake is just asking for trouble. Packagers are freely asking other versions of automake to overwrite the stock files in tarball. (And the version is dependent on which machine the package is built -- say, automake1.7 in machine A, automake1.6 in B, automake1.4 in C) - using automake1.7 to fill in the Requires automake in rpmbuild (instead of automake) isn't a good idea, since it pulls in autoconf2.5. This will impact packages that BuildRequires: autoconf2.5 when building with automake1.4; Hardcode rpmbuild and use automake1.7 to replace Requires automake !?!? - automake-1.4 is not exactly the same as automake1.7 (so perhaps it shouldn't Provide automake after all?). Some packages that work with automake-1.4 may not work with automake1.7, however, we don't know _what_ will be impacted. That's my suggestion; no automake* package should ever Provides automake, and no other packages should Requires automake. They should Requires automake1.4 or Requires automake1.7 (or 1.6) instead. Then fix all spec files that need to execute automake. Just a suggestion anyway, though I've been suggesting this since automake 1.4p6 tarball is released. :-( anyway... that's the status. we're letting things be as they are for now. I guess automake-1.4 is considered the standard. While all of the world is slowly moving away from automake 1.4. :-( Abel regards, Stefan -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
[Cooker] Re: [Contrib-Rpm] rhythmbox-0.4.1-10mdk
On 2003-06-06(Fri) 10:45:12 +0200, Gtz Waschk wrote: Name: rhythmboxRelocations: (not relocateable) Version : 0.4.1 Vendor: MandrakeSoft Release : 10mdk Build Date: Fri Jun 6 10:32:38 2003 --=-=-= * Fri Jun 06 2003 Gtz Waschk [EMAIL PROTECTED] 0.4.1-10mdk - fix build with new gcc 3.3 Just in case you want to know, rhythmbox is active again, and all extra goodies from netrhythmbox is merged into rhythmbox. When new version of rhythmbox is available, you can Obsoletes netrhythmbox. :-) Abel -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] find_requires script don't take to statically linked obj
On 2003-06-06(Fri) 00:20:13 +0200, Stefan van der Eijk wrote: It would be perfect if a -static-devel packages would Require it's -devel counterpart (dependency from the .spec file) and get the rest of the info from the files in the package, like the way the current -devel dependencies work. Is this assumption correct? Any guru knows? But how? do the same as with the .so dependencies, but then add a Provides: .a and Requires: .a dependencies? Probably won't work as expected. Quite some packages only have shared libraries installed, but not static libraries. With the numbers as they are above, quite some -devel packages will need to be split up into -static-devel packages, or the .a dependencies will just be added to the -devel packages. Why not move the static-devel packages back into the -devel packages? I always wondered. The main intention of splitting .a files is saving space; but actually how much space is saved by not installing .a files? - quite some packages containing plugins (gnomegames comes to mind) need to be fixed -- .so's need to be built with -avoid-version?? Of course fixes need to be communicated back to the original projects; Once I have encountered .la files as modules; when I removed those .la files, the program prints 'foobar.la is missing'. (my memory is vague now) - I'd like to see a comprehensive rpm package dependency (and / or naming) standard be made which is distribution independant. Using dependency information based on capabilities is a step forward. This way we can become less dependany on the actual name a package has. I've proposed the .so stuff in redhat's rpm-list, no response from any rpm developers there. If this doesn't get pushed beyond mdk, it's only going to make the rpm hell worse, while it _could_ help solve it; Probably dependency is never an important subject in all distro; even in Debian, many dependencies are hand-edited. Abel - the find-provides and find-requires in rpm-4.2-7mdk need to be updated to the latest version. The one in -7mdk doesn't pick up the dependencies in the rpm-devel package. Luckily no -devel package I know of Requires rpm-devel, which makes it less urgent. regards, Stefan -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] libgtop2-2.0.2-1mdk
On 2003-06-04(Wed) 11:30:28 +0200, Frederic Crozat wrote: Fred, probably you will want to release libgtop 1.0.14 too? 2.0.2 is released because of security problem, and 1.0.14 is the same. Well, 1.0.14 has still not been released !! How come... it has been tagged as 1.0.14 in CVS but no tarball uploaded to GNOME CVS... Anyway, I'll grab the security fix from our security updates.. Just checked, all security fixes are already in 1.0.13-4mdk... I checked again, that particular fix is not in 1.0.13-4mdk. The fix is applied on May 12th. Attached with this mail. Abel -- Frederic Crozat MandrakeSoft -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF diff -ur --exclude=CVS --exclude=po libgtop.0509/ChangeLog libgtop/ChangeLog --- libgtop.0509/ChangeLog 2002-12-11 21:07:50.0 +0800 +++ libgtop/ChangeLog 2003-05-12 06:23:47.0 +0800 @@ -1,3 +1,7 @@ +2003-05-11 Andrew Sobala [EMAIL PROTECTED] + + * up version to 1.0.14 + 2002-12-11 Stanislav Brabec [EMAIL PROTECTED] * sysdeps/guile/Makefile.am, sysdeps/guile/names/Makefile.am: diff -ur --exclude=CVS --exclude=po libgtop.0509/LIBGTOP-VERSION libgtop/LIBGTOP-VERSION --- libgtop.0509/LIBGTOP-VERSION2001-11-27 06:36:18.0 +0800 +++ libgtop/LIBGTOP-VERSION 2003-05-12 06:23:47.0 +0800 @@ -8,7 +8,7 @@ # LIBGTOP_MAJOR_VERSION=1 LIBGTOP_MINOR_VERSION=0 -LIBGTOP_MICRO_VERSION=13 +LIBGTOP_MICRO_VERSION=14 LIBGTOP_INTERFACE_AGE=12 LIBGTOP_BINARY_AGE=12 diff -ur --exclude=CVS --exclude=po libgtop.0509/src/daemon/ChangeLog libgtop/src/daemon/ChangeLog --- libgtop.0509/src/daemon/ChangeLog 2001-11-27 06:12:02.0 +0800 +++ libgtop/src/daemon/ChangeLog2003-05-12 06:23:52.0 +0800 @@ -1,3 +1,7 @@ +2003-05-11 Andrew Sobala [EMAIL PROTECTED] + + * gnuserv.c: (permitted): fix buffer overflow vulnerability + 2001-11-26 Kevin Vandersloot [EMAIL PROTECTED] * gnuserv.c: Apply patch fixing security issue from diff -ur --exclude=CVS --exclude=po libgtop.0509/src/daemon/gnuserv.c libgtop/src/daemon/gnuserv.c --- libgtop.0509/src/daemon/gnuserv.c 2001-11-27 06:12:02.0 +0800 +++ libgtop/src/daemon/gnuserv.c2003-05-12 06:23:52.0 +0800 @@ -200,6 +200,11 @@ auth_data_len = atoi (buf); + if (auth_data_len 1 || auth_data_len sizeof(buf)) { + syslog_message(LOG_WARNING, Invalid data length supplied by client); + return FALSE; + } + if (timed_read (fd, buf, auth_data_len, AUTH_TIMEOUT, 0) != auth_data_len) return FALSE; pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [Contrib-Rpm] gnome-network-1.99.0-1mdk
On 2003-06-04(Wed) 17:23:13 +0200, Gtz Waschk wrote: Description : GNOME network programs. GNOME is the GNU Network Object Model Environment. That's a fancy name but really GNOME is a nice GUI desktop environment. It makes using your computer easy, powerful, and easy to configure. This could need a better description. Could anyone of the native english speakers please suggest one? You can take a better description from the announcement: http://mail.gnome.org/archives/gnome-announce-list/2003-June/msg8.html Abel -- What difference does it make to the dead, the orphans and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty or democracy? Mahatma Gandhi (1869 - 1948), Non-Violence in Peace and War -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] find_requires script don't take to statically linked obj
On 2003-06-03(Tue) 10:58:42 +0200, Gtz Waschk wrote: it would be nice if the find_requires script would parse the dependancies of static libraries, but how to do this? It's easy to find out the dependant libs of shared libraries, but AFAIK shared libraries only contain information about which symbols are unresolved, but no information on where to get that symbols. Has anyone thought Seems you can obtain dependency info via objdump too: [EMAIL PROTECTED] lib]$ objdump -p /usr/lib/libqtmcop.so.1 | grep NEEDED NEEDED libmcop.so.1 NEEDED libdl.so.2 NEEDED libqt-mt.so.3 NEEDED libpng.so.3 NEEDED libz.so.1 NEEDED libXext.so.6 NEEDED libX11.so.6 NEEDED libSM.so.6 NEEDED libICE.so.6 NEEDED libpthread.so.0 NEEDED libstdc++.so.5 NEEDED libm.so.6 NEEDED libc.so.6 NEEDED libgcc_s.so.1 But objdump -p don't show any dep info about static archives. about using the libtool .la files to get the dependant libs? Or maybe it would be possible to use the dependany information from the shared libraries for static libs, that means if libfoo.so depends on libbar.so, does libfoo.a depends on libbar.a? I don't know much info about it. Abel -- What difference does it make to the dead, the orphans and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty or democracy? Mahatma Gandhi (1869 - 1948), Non-Violence in Peace and War -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
[Cooker] GNOME + libtool 1.4.3 = big problem
Hi Fred, Just saw you have updated almost all gnome packages (welcome back!), but some are probably in trouble. Recently, many packages switched libtool to 1.5, due to partial fix of DESTDIR issue. However, we still have 1.4.3 in cooker, and that will run into trouble when %configure calls libtoolize, which overwrites the stock ltmain.sh/libtool in the tarball. As a result, all libraries won't have .so extension (say, /usr/lib/libpanel-applet-2.0.0.15). To resolve this, probably it's time to move to libtool 1.5, or just remove all libtoolize calls in gnome packages... Abel -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
[Cooker] Re: [CHRPM] libgtop2-2.0.2-1mdk
On 2003-06-03(Tue) 14:16:06 +0200, Frederic Crozat wrote: --=-=-= Name: libgtop2 Relocations: (not relocateable) Version : 2.0.2 Vendor: MandrakeSoft Release : 1mdk Build Date: Tue Jun 3 13:57:42 2003 --=-=-= * Tue Jun 03 2003 Frederic Crozat [EMAIL PROTECTED] - 2.0.2-1mdk - Release 2.0.2 - mklibnamification - Patch0 (rawhide): fix autoconf/automake environment - Remove libgtop_daemon2, it has security issues. Fred, probably you will want to release libgtop 1.0.14 too? 2.0.2 is released because of security problem, and 1.0.14 is the same. Abel -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] perl(the) MySQL-client-4.0.13-1mdk
On 2003-06-03(Tue) 21:09:31 +0200, Oden Eriksson wrote: I think I've found what is triggering /usr/lib/rpm/perl.req to think a perl(the) module is needed..., and the answer is use the. rpm -qp --qf [%{requirename}\n] MySQL-client-4.0.13-1mdk.i586.rpm | grep the perl(the) grep use the /usr/bin/mysqlaccess use the option --old_server. #When matching, use the first found match. I tried this hack but it didn't work: Yup, probably you're true; the regex matching of use . is not perfect. Can you try the attached patch on perl.req, and check perl dep again? Abel %global __perl_requires /usr/lib/rpm/perl.req $* | sed -e '/perl(the)/d' It's currently impossible to install mysql on klama because of this... -- Regards // Oden Eriksson, Deserve-IT.com -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF --- /usr/lib/rpm/perl.req.bak 2003-05-13 23:07:19.0 +0800 +++ /usr/lib/rpm/perl.req 2003-06-04 03:26:29.0 +0800 @@ -122,9 +122,9 @@ (m/^(\s*) # we hope the inclusion starts the line (require|use)\s+(?!\{) # do not want 'do {' loops # quotes around name are always legal -[\'\]?([^\;\ \'\\t]*)[\'\]?[\t\;\ ] +[\'\]?([^\;\ \'\\t]*)[\'\]?[\t\ ] # the syntax for 'use' allows version requirements -\s*([.0-9]*) +\s*([.0-9]*)\s*\; /x) ) { my ($whitespace, $statement, $module, $version) = ($1, $2, $3,$4); pgp0.pgp Description: PGP signature
Re: [Cooker] GNOME + libtool 1.4.3 = big problem
On 2003-06-03(Tue) 21:18:29 +0200, Frederic Crozat wrote: To resolve this, probably it's time to move to libtool 1.5, or just remove all libtoolize calls in gnome packages... Yep, I know.. That is why I'm running aclocal-1.7 and autoconf before 0uild in the package I upload.. Argh, I should have checked more clearly before asking... ok, pretend I've never said anything :) Abel It is up to Gwenole to upload a new libtool version.. (He uploaded gcc so there is hope :) -- Frdric Crozat MandrakeSoft -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
[Cooker] Re: [CHRPM] gettext-0.11.5-6mdk
On 2003-06-04(Wed) 01:00:19 +0200, Stew Benedict wrote: --=-=-= Name: gettext Relocations: (not relocateable) Version : 0.11.5Vendor: MandrakeSoft Release : 6mdk Build Date: Wed Jun 4 00:49:48 2003 --=-=-= * Tue Jun 03 2003 Stew Benedict [EMAIL PROTECTED] 0.11.5-6mdk - LSB/LI18NUX test requirements - patch7 - (msgfmt ignore duplicate strings in multiple domains when -o specified) - BuildRequires: emacs-el, use %mklibname As gettext is updated, can we have gettext 0.12 instead? (at least it will be beneficial to translators) Abel -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
[Cooker] libcups1 dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan van der Eijk wrote: | next one: libcups1? | | $ ~/test06.sh libcups1 | libcups1 Provides: libcups.so | libcups1 Requires: libcrypto.so | libcups1 Requires: libdl.so | libcups1 Requires: libssl.so [EMAIL PROTECTED] deaddog]$ rpm -q libcups1 libcups1-1.1.19-1mdk [EMAIL PROTECTED] maddog]$ rpm -ql libcups1 /usr/lib/libcups.so.2 /usr/lib/libcupsimage.so.2 Where does the libcups.so come from? libcups1-devel? Abel | | Stefan | | - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+2Ng2QVLh8cZxhv8RAsttAKChh04KpfAMrY3XR8iOoAWhXwtsHwCg56ks q+OvpgUwGuozQtCw4QPkXQk= =cnLJ -END PGP SIGNATURE-
Re: [Cooker] Re: libcups1 dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan van der Eijk wrote: | Due to this symlink being in the package. | | $ rpm -ql libcups1-1.1.19-0.9mdk | grep \.so$ | /usr/lib/libcups.so | | In cups.spec I found the following: | | # This .so link is in the main package but not in the devel package | # because it is needed for the function overloading in XPP and QTCUPS | %{_libdir}/libcups.so Huh! | Wouldn't it be better to move the \.so$ file to the -devel package and | let xpp and qtcups Require libcups1-devel or add -avoid-version to it? | Then the issue is put with the packages that are causing the problem. If it's me, I would never touch such files, since Till knows the ins and outs of cups, and he should know what to do in this situation, better than everybody else. You are likely breaking his packages without asking him. ~From what I observed, yes, %libdir/libcups.so is used for development, but it's likely used by other userland apps. You discarded one important point: if some development files are needed for normal operation of user programs, then it should be put into main package instead of -devel package. IDL files serves as good example. The most important reason of splitting main/devel package is that, most people are USERS, and they don't need devel packages. The only case they want devel packages is when they wanna be developers or they want to compile things that need these devel packages. Otherwise, there is no reason to split package anymore -- the programs in main package don't have full functionality, or simply won't run. That doesn't make much sense, right? I'd suggest you to *promptly* revert the change, and ask Till now, to make sure if his comment about libcups.so is right. In such kind of situation, Till knows the most about it, and his decision must be respected. Best, Abel | | regards, | | Stefan | - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+2PvUQVLh8cZxhv8RAvb3AKDoOrVn6kixJj1Wm59WZZ60hhlfggCfTPLd uy/RgZF1rltMmmk3fm9Q+Y4= =xGec -END PGP SIGNATURE-
Re: [Cooker] Re: [CHRPM] docbook-utils-0.6.13-3mdk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Götz Waschk wrote: | Yes, messing around with the provides and obsoletes is only a | workaround and no fix. We should also keep in mind that this must be a | bug in rpm. If both openjade and docbook-utils provide and obsolete | sgml-tools, this doesn't mean they obsolete each other. Both package Camille, probably you know most clearly how the transition from sgml-tools to openjade+docbook-utils is done; is the above true? (openjade dbk-utils both provides a part of sgmltools) | obsolete only one part of the provides of the other package, that's | why I think it is a rpm bug. It would be nice if someone could test | this on a RH9 machine, maybe it's an upstream bug. I'm not quite sure if it's a bug or a design flaw :) Flepied, is such kind of situation solvable? Not only openjade docbook-utils, similar situation do appear in apache-conf / apache2-common too (apache-conf obsoletes apache-common, so it obsoletes any other package that provides apache-common). - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+2QF5QVLh8cZxhv8RAuyQAKDl0iOkir2X769sF7u5eb2ecMyDtwCgmqgI zWMHL/flSoNeHmIT3R8YdYY= =/y4z -END PGP SIGNATURE-
Re: [Cooker] Re: [CHRPM] ORBit2-2.7.1-2mdk
Stefan van der Eijk wrote: Götz Waschk wrote: [...] BTW ORBit2 should be fixed with the attached patch. I'm not sure. I was expecting the .so.0.0.0 files to go and that the .so file would remain. This is not the case: Did you run automake after applying the patch from Götz? Btw, the patch is just applied to ORBit2 CVS, and the versioned files would not be there in next release. In case you're not sure how to handle the patch, I've attached another patch against ORBit2.spec. Abel $ ls -l total 36 -rwxr-xr-x1 stefan stefan963 May 31 10:19 Everything_module.la* lrwxrwxrwx1 stefan stefan 26 May 31 10:19 Everything_module.so - Everything_module.so.0.0.0* lrwxrwxrwx1 stefan stefan 26 May 31 10:19 Everything_module.so.0 - Everything_module.so.0.0.0* -rwxr-xr-x1 stefan stefan 29652 May 31 10:19 Everything_module.so.0.0.0* --- test/everything/Makefile.am~2003-04-23 13:09:01.0 +0200 +++ test/everything/Makefile.am2003-05-26 12:48:54.0 +0200 @@ -55,7 +55,7 @@ orbittypelib_LTLIBRARIES = Everything_module.la Everything_module_la_LDFLAGS = \ --export-dynamic -module -no-undefined +-export-dynamic -module -no-undefined -avoid-version Everything_module_la_SOURCES = \ everything-imodule.c Everything_module_la_LIBADD = \ -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF --- ORBit2.spec.bak 2003-05-24 20:05:10.0 +0800 +++ ORBit2.spec 2003-05-31 18:20:26.0 +0800 @@ -8,17 +8,19 @@ Name: ORBit2 Version: 2.7.1 -Release: 2mdk +Release: 3mdk Summary: High-performance CORBA Object Request Broker. License: LGPL Group: Graphical desktop/GNOME URL: http://orbit-resource.sf.net/ Buildroot: %{_tmppath}/%{name}-%{version}-buildroot -Source0: ftp://ftp.gnome.org/pub/GNOME/pre-gnome2/sources/%{name}/%{name}-%{version}.tar.bz2 +Source0: ftp://ftp.gnome.org/pub/GNOME/sources/%{name}/2.7/%{name}-%{version}.tar.bz2 Source1: orbit-faq2-0.2.html.bz2 # (fc) 2.4.1-2mdk fix crash when /tmp is not readable Patch0:ORBit2-2.7.1-tmpdir.patch.bz2 +# (goetz) 2.7.1-3mdk Don't compile Everything_module as a versioned library +Patch1:ORBit2-2.7.1-everything-module.patch.bz2 BuildConflicts:ORBit-devel 0.5.10 BuildRequires: indent bison flex popt-devel = 1.5 @@ -87,6 +89,10 @@ %prep %setup -q %patch0 -p1 -b .tmpdir +%patch1 -p0 -b .libtoolflag + +# needed by patch1 +automake-1.4 bzcat %{SOURCE1} orbit-faq2-0.2.html @@ -123,7 +129,7 @@ %{_bindir}/typelib-dump %{_datadir}/idl/orbit-%{api_version} %dir %{_libdir}/orbit-%{api_version} -%{_libdir}/orbit-%{api_version}/*.so.* +%{_libdir}/orbit-%{api_version}/*.so* %files -n %{lib_name} %defattr(-,root,root,755) @@ -142,9 +148,13 @@ %{_libdir}/lib*.la %{_libdir}/pkgconfig/*.pc %{_libdir}/orbit-%{api_version}/*.la -%{_libdir}/orbit-%{api_version}/*.so %changelog +* Sat May 31 2003 Abel Cheung [EMAIL PROTECTED] - 2.7.1-3mdk +- Patch1(CVS): Fix everything_module libtool flag (thanks Goetz) +- move Everything_module.so back to main package +- fix source URL + * Sat Jun 24 2003 Stefan van der Eijk [EMAIL PROTECTED] - 2.7.1-2mdk - split off \.so$ to -devel files - remove redundant BuildRequires: pkgconfig pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] ORBit2-2.7.1-2mdk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan van der Eijk wrote: | His patch patched the .am file -- couldn't see any difference. With the | .in file it works. His patch is correct. Makefile.am is read by automake, which generates Makefile.in. Anyway, as ORBit2 would not be broken now, things can be left as it is. [..] | Just uploaded -3mdk. The only difference with the changes below is the | URL. Leave that for the next release or push out -4mdk? Probably no need to do so, as source URL is not anything vital. There are so much more important things to do. Abel - -- Abel Cheung Linux counter #256983 | http://counter.li.org GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+2I9vQVLh8cZxhv8RAptsAKDYTguQLf3/j5xK8x/w1bta5pho5QCgsbZL 3fRhvrchW67f1aScE+QEKSY= =0mxa -END PGP SIGNATURE-
Re: [Cooker] Re: [CHRPM] docbook-utils-0.6.13-3mdk
On 2003-05-28(Wed) 18:20:46 +0200, Camille Bgnis wrote: Camille, openjade and docbook-utils still try to obsolete each other, is this the desired behavior? Hmm, I'm not a wizard packager by far, Can that be because both packages: Obsoletes: sgml-tools Provides: sgml-tools Very likely. If so I suggest openjade packager (Gtz Waschk ?) removes these lines from openjade spec file. But for now, who knows why sgml-tools is obsoleted in the first place; because either one (openjade or docbook-utils) has superseded all sgml-tools functionality, or both packages shared some? If it's the latter situation, we may need extra consideration... Abel Camille. Abel Installation failed: jade = 1.2.1 is needed by (installed) docbook-style-dsssl-1.78-3mdk jade is needed by (installed) docbook-style-dsssl-1.78-3mdk jade = 1.2.1 is needed by (installed) docbook-style-dsssl-1.78-3mdk jade is needed by (installed) docbook-style-dsssl-1.78-3mdk jade = 1.2.1 is needed by (installed) perl-SGMLSpm-1.03ii-5mdk openjade = 1.3.1 is needed by (installed) jadetex-3.12-79mdk And, ofcourse nodeps installation continues to remove openjade Charles -- Delay is preferable to error. -- Thomas Jefferson - Mandrake Linux 9.2 on PurpleDragon Kernel-enterprise-2.4.21.0rc1.1mdk - -- Abel Cheung GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Linux counter #256983 | http://counter.li.org Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] ORBit2-2.7.1-2mdk
On 2003-05-27(Tue) 10:38:01 +0200, Gtz Waschk wrote: If a plugin is a versioned shared library, this is a bug. This often happens with xmms plugins, this isn't a problem unless you remove the .so symlink. So I guess this one is broken: [.] BTW ORBit2 should be fixed with the attached patch. I didn't get any news from Stefan; perhaps you are willing to help fixing this package for now, incorporating your patch? I've filed a bugzilla report for it. Abel [ORBit2 patch] -- Abel Cheung GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Linux counter #256983 | http://counter.li.org Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] docbook-utils-0.6.13-3mdk
On 2003-05-28(Wed) 09:45:54 -0400, Charles A Edwards wrote: Name: docbook-utilsRelocations: (not relocateable) Version : 0.6.13Vendor: MandrakeSoft Release : 3mdk Build Date: Still getting jade/openjade error Camille, openjade and docbook-utils still try to obsolete each other, is this the desired behavior? Abel Installation failed: jade = 1.2.1 is needed by (installed) docbook-style-dsssl-1.78-3mdk jade is needed by (installed) docbook-style-dsssl-1.78-3mdk jade = 1.2.1 is needed by (installed) docbook-style-dsssl-1.78-3mdk jade is needed by (installed) docbook-style-dsssl-1.78-3mdk jade = 1.2.1 is needed by (installed) perl-SGMLSpm-1.03ii-5mdk openjade = 1.3.1 is needed by (installed) jadetex-3.12-79mdk And, ofcourse nodeps installation continues to remove openjade Charles -- Delay is preferable to error. -- Thomas Jefferson - Mandrake Linux 9.2 on PurpleDragon Kernel-enterprise-2.4.21.0rc1.1mdk - -- Abel Cheung GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Linux counter #256983 | http://counter.li.org Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] rpm building
On 2002-04-10(Wed) 04:37:54 +0200, Guillaume Bedot wrote: Is it me or rpm interprets #%configure in a spec file ? All macros are expanded unconditionally. As Buchen said, use #configure if you don't want macros expansion. To be precise, one-line macros is fine, since the whole line (after expansion) is still inside the comment. But multi-line macros will cause error -- only the first line is commented out. Abel Guillaume. -- Now a Mandrake Club User http://www.mandrakeclub.com/user.php?op=userinfouname=gbedot -- Abel Cheung GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Linux counter #256983 | http://counter.li.org Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] ORBit2-2.7.1-2mdk
On 2003-05-27(Tue) 10:38:01 +0200, Gtz Waschk wrote: Am Dienstag, 27. Mai 2003, 10:31:00 Uhr MET, schrieb Stefan van der Eijk: I've seen some other packages with plugins. Quite some of them are .so files, but not symlinks to another file. If a plugin is a versioned shared library, this is a bug. This often happens with xmms plugins, this isn't a problem unless you remove the .so symlink. So I guess this one is broken: That's true, you have already said what I want to tell Stefan :) Since quite a few packages miscompiles modules into versioned libraries, I'd want to ask if Stefan can lift the bar a little bit for now, otherwise these packages will be errornous instantly (at least some apps will not run correctly) until patches are applied to those packages. Abel [EMAIL PROTECTED] SOURCES]$ rpm -qpl /contrib/RPMS/xmms-dsp-oddcast-effect-0.1.0-1md.i586.rpm|fgrep .so /usr/lib/xmms/Effect/liboddcastv2_xmms_effect.so.0 /usr/lib/xmms/Effect/liboddcastv2_xmms_effect.so.0.0.0 BTW ORBit2 should be fixed with the attached patch. -- What difference does it make to the dead, the orphans and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty or democracy? Mahatma Gandhi (1869 - 1948), Non-Violence in Peace and War --- test/everything/Makefile.am~ 2003-04-23 13:09:01.0 +0200 +++ test/everything/Makefile.am 2003-05-26 12:48:54.0 +0200 @@ -55,7 +55,7 @@ orbittypelib_LTLIBRARIES = Everything_module.la Everything_module_la_LDFLAGS = \ - -export-dynamic -module -no-undefined + -export-dynamic -module -no-undefined -avoid-version Everything_module_la_SOURCES = \ everything-imodule.c Everything_module_la_LIBADD = \ -- Abel Cheung GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Linux counter #256983 | http://counter.li.org Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] ORBit2-2.7.1-2mdk
On 2003-05-28(Wed) 00:05:15 +0200, Stefan van der Eijk wrote: The reality is that I don't have the resources to track down all of the packages that have these issues and fix them. I thought that I was doing the right thing (tm) for ORBit2, and now I'm happy that this discussion has taken place and that we've decided that this is the way we're going to handle this. I guess the process will be to rebuild everything ASAP, don't make changes while doing so (unless obvious). Then go back and fix the packages that are causing the issues. The 2nd part will be time consuming, require quite some expertise and some convincing of a number of people So you already know it will be time consuming and require expertise. That's what we lack for now. Testing all functions in those programs to find out which is broken and which is not -- I really don't think it is very feasible, unless some people volunteers to dedicate their spare time to it. Especially when you want to know when, how and why it is broken, write everything down, and wait for others to confirm. That's why I'm suggesting a lighter barrier, which would leave all (or almost all) such packages intact for now. Warnings can be issued to maintainers, who fixes them when they have time. After that, we can have more strict barrier without worrying which package is broken. For now, if it is still decided it's better to break those packages first and search for faults later, I wouldn't insist the opposite, and will help finding bugs. That's up to everybody to decide. Btw, when the .so problems are fixed, will the scripts warn about that, and tell people to move those .so files back from -devel package to normal package? Abel regards, Stefan Abel [EMAIL PROTECTED] SOURCES]$ rpm -qpl /contrib/RPMS/xmms-dsp-oddcast-effect-0.1.0-1md.i586.rpm|fgrep .so /usr/lib/xmms/Effect/liboddcastv2_xmms_effect.so.0 /usr/lib/xmms/Effect/liboddcastv2_xmms_effect.so.0.0.0 BTW ORBit2 should be fixed with the attached patch. -- What difference does it make to the dead, the orphans and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty or democracy? Mahatma Gandhi (1869 - 1948), Non-Violence in Peace and War --- test/everything/Makefile.am~2003-04-23 13:09:01.0 +0200 +++ test/everything/Makefile.am 2003-05-26 12:48:54.0 +0200 @@ -55,7 +55,7 @@ orbittypelib_LTLIBRARIES = Everything_module.la Everything_module_la_LDFLAGS = \ - -export-dynamic -module -no-undefined + -export-dynamic -module -no-undefined -avoid-version Everything_module_la_SOURCES = \ everything-imodule.c Everything_module_la_LIBADD = \ -- Abel Cheung GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Linux counter #256983 | http://counter.li.org Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [Contrib-Rpm] perl-Crypt-OpenSSL-DSA-0.11-2mdk
On 2003-05-28(Wed) 02:05:53 +0200, Olivier Thauvin wrote: distlint (from distriblint package) is design for that !! Happy checking ! [1] = main [2] = contrib Some things sounds very wrong here: * perl-HTML-Clean-0.8-5mdk.noarch (perl-HTML-Clean-0.8-5mdk.src.rpm) [1] DEPO: req in other level wml-2.0.9-5mdk.i586 [2] perl-HTML-Clean: Requires: perl(HTML::Clean) Provides: perl(HTML::Clean) == 0.8 wml: Provides: perl(HTML::Clean) == 0.7 * htdig-web-3.2.0-0.7mdk.i586 (htdig-3.2.0-0.7mdk.src.rpm) [1] DEPO: req in other level thttpd-2.20c-2mdk.i586 [2] htdig-web requires webserver, not thttpd. * mailman-2.1.2-2mdk.i586 (mailman-2.1.2-2mdk.src.rpm) [1] DEPO: req in other level thttpd-2.20c-2mdk.i586 [2] Same issue as htdig-web above. * gimp-data-extras-1.2.0-5mdk.src () [1] DEPO: req in other level libgimp14-devel-1.3.14-2mdk.i586 [2] gimp-data-extras wants gimp 1.2.x, while libgimp14-devel comes from gimp 1.3.x. * perl-GTK-0.7008-29mdk.src () [1] DEPO: req in other level libgtkglarea2.0-devel-1.99.0-2mdk.i586 [2] perl-GTK uses GTK+ 1.x, while libgtkglarea2.0 is GTK+ 2.x stuff. * printer-drivers-1.0-104mdk.src () [1] DEPO: req in other level libgimp14-devel-1.3.14-2mdk.i586 [2] DEPO: req in other level libgimp14-devel-1.3.14-2mdk.i586 [2] Sounds like what it wants is libgimp1.2-devel. * pygnome-1.4.4-3mdk.src () [1] DEPO: req in other level libgtkglarea2.0-devel-1.99.0-2mdk.i586 [2] Same issue as perl-GTK. pygnome uses GTK+ 1.x, and libgtkglarea2.0 isn't. * sane-frontends-1.0.10-1mdk.src () [1] DEPO: req in other level libgimp14-devel-1.3.14-2mdk.i586 [2] sane-frontends requires gimp-libgimp, but what it really needs is gimp-libgimp from gimp 1.2.x. gimp 1.3.x also provides gimp-libgimp -- BAD. * xsane-0.90-3mdk.src () [1] DEPO: req in other level libgimp14-devel-1.3.14-2mdk.i586 [2] Same for sane-frontends above. * xtraceroute-0.9.1-10mdk.src () [1] DEPO: req in other level libgtkglarea2.0-devel-1.99.0-2mdk.i586 [2] This sounds like even more strange to me. xtraceroute wants libgtkgl.so.5, which uses GTK+ 1.x. libgtkglarea2.0-devel doesn't provide it at all... All these mis-dependencies seems to suggest that it's checking contrib FIRST for missing dep before checking main... is it? Abel -- Linux pour Mac !? Enfin le moyen de transformer une pomme en vritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/ -- Abel Cheung GPG Key: (0xC67186FF) | http://deaddog.org/gpg.asc Linux counter #256983 | http://counter.li.org Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF pgp0.pgp Description: PGP signature
Re: [Cooker] mini-todo
On 2003-04-01(Tue) 18:56:39 -0500, Austin wrote: On 2003.04.01 17:39 Levi Ramsey wrote: 1. Package gtkmm2. I've done that for a while, packaged up to libgnomeuimm, but not uploaded. So right now it's severely outdated (1.3.x). But you can try to take it as reference though. Do you need it? Abel I've had that on a TODO for a while... last I asked gc about it, he said it wasn't really a priority.. I have several packages I'm waiting to do becuase of this missing. Austin -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc pgp0.pgp Description: PGP signature
Re: [Cooker] Re: Re: Re: Requires Provides on -devel packages (Continued)
On 2003-03-25(Tue) 20:12:42 -0500, David Walser wrote: [...] %{_sbindir}/*[!webspy] #have to manually add these two to the list, don't ask me *why*, but if not, it won't be included %{_sbindir}/tcpnice %{_sbindir}/sshow %{_mandir}/man8/*[!webspy] Doesn't that mean anything that doesn't end in the letters w, e, b, s, p, or y? Yes, and that means the file list needs fixing. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc pgp0.pgp Description: PGP signature
Re: [Cooker] [Bug 2882] [gnome-network] Gnome RPM not working
On 2003-03-10(Mon) 02:38:34 -0400, Jean-Michel Dault wrote: Don't bother with gnome-ppp. Use wvdial, it works just fine and it is very easy to configure. That's what I ended up using when I was stuck with a modem. Only problem is, wvdial is not installed by default (not even in rpmsrate), and has no menu entry. So it won't help new users to get connected, and it's hard to get technical support when you've just reformatted your only machine and you can't connect to the net =( I'd say, there's no (or almost no) equivalent thing as kppp under GNOME. My guess is, almost all GNOME core developers have permanent connection, and they never looked back and see the need of a modem dialer :-/ Actually I'd suggest gnome-network be removed from cooker, it's just a bunch of dead code :-) Abel Jean-Michel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc pgp0.pgp Description: PGP signature
Re: [Cooker] [Bug 2882] [gnome-network] Gnome RPM not working
On 2003-03-10(Mon) 01:16:31 -0500, jmdault wrote: --- Additional Comments From [EMAIL PROTECTED] 2003-03-10 07:16 --- After some research, I discovered gnome-ppp doesn't provide the password, but instead relies on the existence of an already-configured password in /etc/pap-secrets. [...] gnome-ppp sucks ;-) Of course, gnome-network has been abandoned during the GNOME 1.0 days! Only until very recently that the code has been resurrected from death, but still not usable yet. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc pgp0.pgp Description: PGP signature
Re: [Cooker] Trying to compile a gnome applet in 9.1
On 2003-02-23(Sun) 22:19:13 -0800, James Sparenberg wrote: And it says I need applet-widget.h Can't find this as part of any package in the cooker... According to this from gnome.org http://mail.gnome.org/archives/gnome-devel-list/2002-September/msg9.html applet-widget.h should be part of libpanel or gnome-panel... both of Don't think so. applet-widget.h is supposed to belong to gnome-core 1.4.x, and it was killed from CVS for more than 1 year, even before GNOME 2.0 is released. You will have better luck searching for it after installing gnome-core. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc pgp0.pgp Description: PGP signature
Re: [Cooker] pcre 4.0
On 2003-02-23(Sun) 21:14:55 +0100, Guido Draheim wrote: I have been hitting a bug in libpcre when trying to use it in utf8 mode. It is rather simply, not clearing the offsetvalue for return due to being not compiled in utf8 mode. This leads to two observetions: [..] anyone wants to say it is too late to update ;-)=) It's very likely too late, since many packages will need recompiling if libpcre is updated. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc pgp0.pgp Description: PGP signature
Re: [Cooker] KDE packaging makes no sense
On 2003-02-21(Fri) 18:35:41 -0500, Maks Orlovich wrote: Skipping the whole modularity problem -- about which I'd rather not comment -- don't we have a pretty horrid dependency loop here? If I got it right: galaxy-kde requires kdelibs and kdebase kdebase requires kdelibs and galaxy-kde kdelibs requires galaxy-kde and through it kdebase Everybody, please give up insisting on this point. The KDE dependency has been argued here for many times in cooker. People come and go, argueing over and over on this topic, without achieving anything. If the time is spent on doing other things, cooker could have become a little better. So please spend your energy on something you CAN do, and kill this thread. Is it OK for everybody? Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] spec-helper-0.8-1mdk
On 2003-02-15(Sat) 14:09:11 +0100, Frederic Lepied wrote: Stefan van der Eijk [EMAIL PROTECTED] writes: If you were to add BuildRequires: gettext to the affected GNOME packages, would the problems then also be solved? But apparently this is a hack, and the real fix should go to Korean translations. Are the translators notified on this problem? Abel --=-=-= Name: spec-helper Relocations: (not relocateable) Version : 0.8 Vendor: MandrakeSoft Release : 1mdk Build Date: Fri Feb 14 09:35:19 2003 --=-=-= * Fri Feb 14 2003 Frederic Lepied [EMAIL PROTECTED] 0.8-1mdk - added fix-po from Pablo to fix korean translation of GNOME -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg92885/pgp0.pgp Description: PGP signature
[Cooker] Update balsa to 2.0.8?
Hi, Can we see balsa 2.0.8 in cooker? I know feature freeze is close, so I'm not saying this based on the new feature, but on it's license (if this is important): Linking against OpenSSL library is explicitely allowed (README,INSTALL) Regards, Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg92886/pgp0.pgp Description: PGP signature
[Cooker] Re: [Contrib-Rpm] csound-4.23.4.2-2mdk
On 2003-02-13(Thu) 07:45:27 +0100, Austin Acton wrote: [Contrib-RPM] Name: csound Relocations: (not relocateable) Version : 4.23.4.2 Vendor: MandrakeSoft Release : 2mdk Build Date: Thu Feb 13 06:36:26 2003 Size: 1231382 License: MIT Does this version of csound use MIT license? AFAIK some version of csound (is it canonical version or...) specifies that it *only* allows non-commercial usage/distribution. Once upon a point, I was trying to create a csound package too, but was immediately shelved because of its license. My memory can be wrong here, but it still worths checking. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg91999/pgp0.pgp Description: PGP signature
Re: [Cooker] Linux Audio RPMs
On 2003-02-13(Thu) 00:39:55 -0500, Austin Acton wrote: Top priority, highly requested and on Thac's site = [] lilypond [EMAIL PROTECTED] (1.7.12 has issues compiling) Can I participate too? I have a lilypond 1.6.7 almost ready (compiles successfully, just need to tidy up the spec), sitting in my machine... Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg92000/pgp0.pgp Description: PGP signature
Re: [Cooker] Missing fontconfig-devel
On 2003-01-24(Fri) 15:45:01 -0800, George Mitchell wrote: I am trying look over the latest version of Xfree but my system requires XFree-devel which in turn requires fontconfig-devel which is not currently available on the mirrors. Anyone know what is going on with this package? [root@mobile root]# urpmf --provides fontconfig-devel libfontconfig1-devel:libfontconfig-devel[== 2.1-5mdk] libfontconfig1-devel:fontconfig-devel[== 2.1-5mdk] -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg88015/pgp0.pgp Description: PGP signature
Re: [Cooker] Old packages not removed from the mirrors
On 2003-01-23(Thu) 18:35:36 -0800, Quel Qun wrote: Hi, New rpm are coming through but the old ones are not deleted (at least from uninett) so it's only a matter of time before they run out of space. As an Mandrake employee (I think it's either warly or gc) said, Mandrake has absolutely no control over the mirrors Abel -- Quel Qun [EMAIL PROTECTED] -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg87778/pgp0.pgp Description: PGP signature
Re: [Cooker] gnome-theme-manager stalls
On 2003-01-22(Wed) 17:35:34 +0100, Frederic Crozat wrote: On Wed, 22 Jan 2003 11:14:50 -0500, Tim Lee wrote: Are you, by any chance, having a high security level ? I don't think so. In /etc/sysconfig/msec, SECURE_LEVEL is set at 2. What file or directory would affect FAM like that? And what permissions should it be set at? the main problem is when msec is set to 4 or 5, portmap isn't accessible and fam doesn't like that at all :(( I've got the same hanging of gnome-theme-manager observed, even though I confirmed portmap/xinetd works flawlessly, without any iptables rule blocking, and without msec. Filed bugzilla #993. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg87476/pgp0.pgp Description: PGP signature
Re: [Cooker] [Bug 795] [XFree86] Cursor shadow is annoying
On 2003-01-20(Mon) 11:11:35 +0100, Chmouel Boudjnah wrote: [Bug 795] [EMAIL PROTECTED] writes: --- Additional Comments From [EMAIL PROTECTED] 2003-01-18 23:42 --- Still not fixed in Beta 2. this is a feature request not a 'fix to be done' !! XFree86 only has shadow cursors shipped by default, AFAIK. Besides, if non-shadowed version of cursor is used in Mandrake, I'm afraid hundreds of complaint will pop up instead of this one. :) Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg86845/pgp0.pgp Description: PGP signature
Re: [Cooker] [Bug 795] [XFree86] Cursor shadow is annoying
On 2003-01-20(Mon) 11:39:43 +0100, Pascal Terjan wrote: XFree86 only has shadow cursors shipped by default, AFAIK. Besides, if non-shadowed version of cursor is used in Mandrake, I'm afraid hundreds of complaint will pop up instead of this one. :) BTW Is this a problem here or as the white cursor some strange vertical lines inside it and its shadow ? Yup, I see such a vertical line too, which is only found in whiteglass but not redglass. Worth investigation. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg86898/pgp0.pgp Description: PGP signature
Re: [Cooker] [Bug 795] [XFree86] Cursor shadow is annoying
On 2003-01-20(Mon) 16:06:17 +0100, Benjamin Pflugmann wrote: I can see it, too. AFAICT, it's the border of the shadow. Both parts, the cursor itself and the shadow have their own transparency. Therefore, the left part of the cursor (without the shadow) is more transparent then the right part (where cursor and shadow overlay): Hold it over some colored, plain part of the screen and you will see what I mean - the left part lets through a fraction more of the color than the right part. And the transition line between those two parts appears like a line. Aha. However, the redglass cursor doesn't contain this artifact Regarding the grandparent post: X ships with a cursor set without shadows called handhelds (see /usr/lib/X11/icons). As has been already mentioned several times on this list, you can change the default by changing default/index.theme accordingly. The handheld cursor is so small, I can't recognise if it has shadow or not :) For another matter, the preferred place for changing index.theme is in ~/.icons/index.theme instead, much better than modifying system wide setting. Xcursor(3x) manpage has documented the search paths of cursors. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg86919/pgp0.pgp Description: PGP signature
Re: [Cooker] New release of the skeleton spec-file
On 2003-01-19(Sun) 21:00:36 -0500, Austin Acton wrote: I don't see any advantage of packaging the three icons as one archive. I use the following... [] I don't see how that's any worse than one tarball. While it is longer, I don't think clarity should take a back-seat to brevity. Same as %buildroot vs $RPM_BUILD_ROOT, different people may have different practice. Also, the skeleton should definitely include lib-stuff. %define libname lib%name%major and all the rest (descriptions, file-lists, depends, etc.) Not only does this clarify the lib policy, but the packager doesn't have to figure out the depends/provides for the libs which was VERY confusing for me at first, and is the same 90% of the time. How about making another skeleton spec which contains the libname stuff? BTW, it's time to introduce the %mklibname macros... Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg86810/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [Contrib-Rpm] Geramik-0.17-2mdk
On 2003-01-16(Thu) 09:14:32 +0100, Thierry Vignaud wrote: i have read the above thread and i agree on the stupid scripts destruction but i strongly disagree with these stupid requires as i did use geramik theme even if some think it's just not another gtk theme So you should know that these stupid requires are used to mimic what David wants, but not what *I* want. you see, we're in a free software world, and freedom means that if i want to use that particular theme, there's no political reason to deny me this right. You have to convince David instead, not me. whisper I regret _so_ much I have been immersed in this thread. /whisper -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg86322/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [Contrib-Rpm] Geramik-0.17-2mdk
On 2003-01-16(Thu) 09:14:25 +, Adam Williamson wrote: So you should know that these stupid requires are used to mimic what David wants, but not what *I* want. That's simply not true, though. David said that Geramik shouldn't be *used* by people who use GNOME, which is perfectly true - it's kind of silly (no offence Thierry, but it is!) He never said it shouldn't be installed on a machine which has GNOME on it. Linux is MULTIUSER, remember. It should be possible to install Geramik on a machine used by people who use GNOME and people who use KDE, for use only by the people who use KDE. I must admit I have forgotten this case: a multiuser machine, where some use KDE and others use GNOME. But my argument (it invades users who use default theme in GNOME) still holds true. Everything boils down to the scriptlets: %post if [ $1 != 2 ]; then if [ ! -f /etc/gtk/gtkrc ]; then ln -s %{_datadir}/themes/Geramik/gtk/gtkrc /etc/gtk/gtkrc fi if [ ! -f /etc/gtk/gtkrc-2.0 ]; then ln -s %{_datadir}/themes/Geramik/gtk-2.0/gtkrc-2.0 /etc/gtk-2.0/gtkrc fi fi %preun if [ $1 == 0 ]; then if grep %{name} /etc/gtk/gtkrc /dev/null 21 ;then rm -f /etc/gtk/gtkrc fi if grep %{name} /etc/gtk-2.0/gtkrc /dev/null 21 ;then rm -f /etc/gtk-2.0/gtkrc fi fi If one says that: since sysadmins installed Geramik on those systems, and sysadmins are supposed to be in control, users who use default theme in GNOME-only environment shouldn't complain about their default theme changed, as sysadmins are always correct. Then I'll give up. Hope GTK2_RC_FILE can be a solution. I'll wait and see. -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg86336/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [Contrib-Rpm] Geramik-0.17-2mdk
On 2003-01-14(Tue) 16:48:46 -0800, David Walser wrote: Now I see the point. Geramik is trying to do what Bluecurve did, right? Basically. More specifically, the color, font, and related settings that you configure for Keramik in KDE Control Center are what Geramik uses, rather than reading .gtkrc* files and being configured with Gnome tools. It's a Gtk+ theme for KDE users who have to use Gtk+ apps, and it keeps the look of the two consistent 100% of the time. I'm not entirely sure if Bluecurve is set up that way to be configured in one place, and always look the same no matter the toolkit, but if it doesn't do that it probably will in the future. I think I get your entire point now. So Geramik is for those who solely uses KDE as desktop, but don't touch GNOME desktop at all. They usually use KDE apps, but occasionally use GTK+ apps, and want to make those GTK+ apps look consistant with the whole Keramik theme. Isn't it? However, I see why Fred has removed your scripts, since the effect of your %post/%postun scripts has gone too far -- it affected *ALL* persons who use GTK+ software. Besides, it still remains correct if no %post/%postun scripts is used, since people who want it can still use it anytime, and nothing is lost. If they don't want it (I'd want to hear this from Laurent first, as it's really for KDE users. Crozat is the Gnome guy and he really has no business messing with it), then they should delete it from contrib, and probably additionally configure KDE to not use Keramik by default. As I have said, you've gone too far. At least you have to write the scripts in such a way that, only those who use desktop in THAT way is affected. Yes, you have to make sure that people installed KDE desktop only, and if people install GNOME desktop later, your changes have to be undone immediately and nicely. That means you need to make Geramik cope with people's change in behavoir. If the above is not achieved, Geramik will just be a normal theme, nothing more, nothing less (quoted). No, that's still wrong. I think you'll understand from my explanation what Geramik really is. If you just want a Gtk+ theme that looks like Keramik, Geramik is not what you want. Such normal themes do exist. Yes, I do understand your point now, but still think what you proposition (its intended usage) is flawed: can knife manufacturers say that knives are only for slicing food, and they prohibit people to use it differently? Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg86172/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [Contrib-Rpm] Geramik-0.17-2mdk
On 2003-01-15(Wed) 10:57:06 -0800, David Walser wrote: That means you need to make Geramik cope with people's change in behavoir. Still doesn't make sense. I'll agree with one point you've made...if there were a way to have it install itself by default, but only activate for users that are in KDE (kind of like .gtkrc-kde), that would be better. Is this possible? The simplest way I can think of is: Requires: kdebase Conflicts: gnome-desktop gnome-session This should fit your intended usage. You can try convincing Fred if your scriptlets can be added back if the above 2 lines are added as well. Your arguments still failed to convince me, so this is the most I can help. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg86239/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [Contrib-Rpm] Geramik-0.17-2mdk
On 2003-01-16(Thu) 07:11:43 +0100, Thierry Vignaud wrote: R.I.P. Deaddog [EMAIL PROTECTED] writes: Is this possible? The simplest way I can think of is: Requires: kdebase Conflicts: gnome-desktop gnome-session and if one want both kde and gnome ? and if one does not want kde but does want geramik theme for its gtk+ apps ? David said that, Geramik is only for those people who only use KDE as desktop, and just occasionally use GTK+ apps under KDE. Those who use GNOME desktop shouldn't ever use it. That's why I propose these absurd Requires/Conflicts, if he insist getting his %post/%postun scripts back. But he keep telling me I misunderstood him, while I just quoted his intended usage of Geramik. His original %post/%postun links /etc/gtk/gtkrc and /etc/gtk-2.0/gtkrc to Geramik theme. This act invades people who use default theme on GNOME desktop, and Crozat removed his scripts. You can see the earlier thread. Somehow I become tired of this thread. :) -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg86311/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] freetype2-2.1.3-4mdk
On 2003-01-14(Tue) 15:07:53 +0200, Buchan Milne wrote: Guillaume Rousse wrote: I'd like to have other people feedback on this point. If everyone agrees, the plf package could be dropped. For =9.0 yes. Yup, even multibyte TTF work well here. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg85963/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [Contrib-Rpm] Geramik-0.17-2mdk
On 2003-01-14(Tue) 05:17:05 -0800, David Walser wrote: --- Frederic Crozat [EMAIL PROTECTED] wrote: Name: Geramik Version : 0.17 * Tue Jan 14 2003 Frederic Crozat [EMAIL PROTECTED] 0.17-2mdk - Drop the gtkrc (un)installation stuff in %post/%postun, this is completely broken.. Gah!!! You destroyed it! All that post/postun stuff was heavily tested and works perfectly. All bugs reported were squashed. Expect complaints now. Would you mind explaning all of the below anyway? I think that this is not only broken, but *abusive* too. Theme is a per-user setting, why is it trying to make itself as a global theme by default? -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg85965/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [QA] cooker main changes
On 2003-01-14(Tue) 09:08:48 -0500, Brian J. Murrell wrote: On Tue, Jan 14, 2003 at 03:03:51PM +0100, Mandrakesoft packages database wrote: better tool in e2fsprogs Which tool is it that is better? I guess it is refering to /sbin/resize2fs. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg85971/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [Contrib-Rpm] Geramik-0.17-2mdk
On 2003-01-14(Tue) 06:33:17 -0800, David Walser wrote: I think that this is not only broken, but *abusive* too. Theme is a per-user setting, why is it trying to make itself as a global theme by default? The idea is if you install this you *want* that. BUT, ^^^ *THIS* idea is broken in this case. How many people will install *only* 1 theme? Generally people install many themes, and switch one by one later on if they like. If Geramik can establish itself as the default theme, why others can't? Or let them fight -- the first one installed wins? Abel if you don't, it also is very careful to not get in your way. If you set something else as default, it won't override it. If you just delete that gtkrc it puts in place (to disable this being the default) then upgrade the package, it *won't* put it back. (Here I'm talking about the old version before fcrozat ruined it. The new version may not be as careful as the old one was). -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg85973/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [Contrib-Rpm] Geramik-0.17-2mdk
On 2003-01-14(Tue) 07:11:34 -0800, David Walser wrote: --- Frederic Crozat [EMAIL PROTECTED] wrote: This is right.. Theme packages should not screw up default theme.. There is no point for discussion on that.. Geramik is not a normal theme. The only useful purpose it serves is being the default theme, alongside KDE's default Keramik theme. Looks-wise neither are all that wonderful, and noone's gonna choose to use them over something else. Their only usefulness is in their consistency, it's basically the same idea as Bluecurve. Now I see the point. Geramik is trying to do what Bluecurve did, right? If this is so, then the current changes are not enough. You have to persuade Mandrake developers to use G/Keramik to replace the default mdk theme, and adopt G/Keramik as the default instead. In additional to this, you also need to get the GNOME/KDE behavior sync'ed. To sum up, Mandrake have to follow RedHat's decision to make GNOME/KDE similar enough. If the above is not achieved, Geramik will just be a normal theme, nothing more, nothing less (quoted). Having two desktops looking similar but behave differently is worse than what we currently have, IMHO. Moreover, Gemarik is more than buggy Yes, there's only one author, I'm sure he'd appreciate help. I would think having a well-working Geramik would be a desirable thing for MDK. Yes, not only for Mandrake, but good for everybody who like K/Geramik too. Abel -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg86024/pgp0.pgp Description: PGP signature
Re: [Cooker] Meta-Packages ?
On 2003-01-13(Mon) 22:13:32 +0100, Steffen Barszus wrote: urpmi kde-desktop would installs a bunch of kde-packages urpmi mandrake-development installs gcc / gcc-c++ kernel-header and so on. urpmi mandrake-simple-desktop could provide an small kde-desktop with only one programm for each task . I'd support doing this for the devel packages, e.g. bison/flex/gcc/binutils and so on. This has been discussed for several times but nobody is in a position that can take action. GNOME has this already done, as gnome2 package. -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg85839/pgp0.pgp Description: PGP signature
Re: [Cooker] Re: [CHRPM] automake1.6-1.7.2-2mdk
On 2003-01-02(Thu) 16:48:11 -0500, Yura Gusev wrote: Stefan van der Eijk said: --=-=-= Name: automake1.6 Version : 1.7.2 URL : http://sources.redhat.com/automake/ --=-=-= Please update URL http://www.gnu.org/directory/GNU/automake.html Bugzilla can be a better place for such suggestions... so that they will not be forgotten. No? -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg84872/pgp0.pgp Description: PGP signature
Re: [Cooker] libgda2 and libgnomedb2
On 2003-01-02(Thu) 21:47:42 -0500, Quel Qun wrote: Is there any reason why the last 0.9.0 version is not used in cooker instead of the old version. It seems that only gnumeric requires libgda0, but nothing prevents libgda2 to be installed besides it. As a side note, libgnomedb2 should be required to build glade2 and provide full gnome support. As libgnomedb RPM is already in /incoming, it can be put into cooker after some polishing. Fred here? Listening? One note though. Should the RPM be renamed to meageant? -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg84880/pgp0.pgp Description: PGP signature
[Cooker] More package can be removed from cooker
Hi all, Lately some packages were nuked from cooker (was it gc or warly who did it?), so I may miss the boat. Another good candidate to be removed is GXedit, which is unmaintained since Jan 2000. I suppose nobody is using it? -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg84513/pgp0.pgp Description: PGP signature
Re: [Cooker] More package can be removed from cooker
On 2002-12-26(Thu) 07:04:45 -0500, Charles A Edwards wrote: I suppose nobody is using it? I use it almost exclusively. It is mush faster to load than gedit. Even so, since the project itself is no longer being maintained and the URL for it no longer exists (only the 1998 sf dl page) and since I can build/rebuild an rpm for it if wanted/needed, I would have no serious objection to its removal. I think cvs.mandrakesoft.com will have the spec preserved. Besides, there are various RPMs and tarballs downloadable, so rebuilding it can be easy. -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg84524/pgp0.pgp Description: PGP signature
Re: [Cooker] More package can be removed from cooker
On 2002-12-26(Thu) 15:14:20 +0100, Stefan van der Eijk wrote: How about SVGATextMode? No new release since 2000-09-02 (on: http://www.ibiblio.org/pub/Linux/utils/console/). Yup, resizecons can almost replace it, and frame buffer console is another (IMHO better) alternative. So the list grows: * GXedit * SVGATextMode Anymore? R.I.P. Deaddog wrote: [..] Another good candidate to be removed is GXedit, which is unmaintained since Jan 2000. I suppose nobody is using it? -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg84525/pgp0.pgp Description: PGP signature
Re: [Cooker] Building athlon kernel rpm from src.rpm
On 2002-12-25(Wed) 04:16:21 -0600, Lonnie Borntreger wrote: When I give the command: rpmbuild --rebuild --target=athlon kernel-2.4.20.2mdk-1-1mdk.src.rpm the process crashes after a couple of minutes... Is this the correct command? I have also tried using --target=athlon-gnu-linux with the same results :( You may need to rearrange the options, with --target first, followed by (re)build options (such as -bb, -ba, --rebuild), and finally the --with/without options. Not confirmed all combination of options, but with -ba and --target, this worked for me. Here's what I do. 1) create a file called ~/.rpmrc with the following: buildarchtranslate: athlon: athlon buildarchtranslate: i686: athlon buildarchtranslate: k6: athlon buildarchtranslate: i586: athlon buildarchtranslate: i486: athlon buildarchtranslate: i386: athlon 2) Build using: rpm --rebuild --with smp --with source --without secure --without enterprise --without BOOT --without doc kernel-2.4.20.2mdk-1-1mdk.src.rpm -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg84494/pgp0.pgp Description: PGP signature
Re: [Cooker] what's /usr/bin/autom4te-2.13?
On 2002-10-28(Mon) 16:06:55 +0100, Guillaume Cottenceau wrote: ac-wrapper: ouch, couldn't call binary (/usr/bin/autom4te-2.13). autoheader-2.5x: /usr/bin/autom4te failed with exit status: 2 I've had this problem before. Not sure what causes the problem. Try When my script wrongly detects 2.1 and actually the things try to call autom4te which is a 2.5 only thingy. [...] Not all config tools comply with the rules of the version detection script (/usr/bin/autoconf) by GC. Patches welcome :). GC, IMHO your autoconf version detecting rules are fairly complete; usually it's configure.{in,ac} that need to be patched instead :) -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg84386/pgp0.pgp Description: PGP signature
Re: [Cooker] %configure2_5x rpm macro
On 2002-12-19(Thu) 10:22:51 +0100, Gwenole Beauchesne wrote: I had this problem with gstreamer-plugins, without an explicit libtoolize call the C++ plugins wouldn't link to libstdc++. Well, what we do in libtool is simply a workaround. You have to fix gstream-plugins there too. ;-) Basically, C++ code or programs have to be linked with g++. However, if it doesn't use anything from libstdc++ you can consider linking with gcc but with an extra -lsupc++. BTW, point granted for %configure2_5x additions, will do. OK, put them into bugzilla #700 and #701, so they won't be forgotten. -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg84393/pgp0.pgp Description: PGP signature
Re: [Cooker] %configure2_5x rpm macro
On 2002-12-12(Thu) 13:18:02 +0100, G?tz Waschk wrote: I think the %configure2_5x macro should be fixed. ATM it expands to: [goetz@klama SRPMS]$ rpm --eval %configure2_5x CONFIGURE_TOP=${CONFIGURE_TOP:-.}; CFLAGS=${CFLAGS:--O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro\} ; export CFLAGS ; CXXFLAGS=${CXXFLAGS:--O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiu\mpro} ; export CXXFLAGS ; FFLAGS=${FFLAGS:--O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro\} ; export FFLAGS ; (cd $CONFIGURE_TOP; [ -f configure.in ] libtoolize --copy --force) ; [schnipp] With autoconf 2.5 the autoconf file can be named configure.ac instead of configure.in. So the libtoolize call should check also check for configure.ac Yup, though not many packages uses configure.ac solely, I think rpm maintainer (flepied?) should consider adding this bit now. Yet another problem: [...snip...] $CONFIGURE_TOP/configure --build %{_target_platform} --host %{_target_platform} --target %{_target_platform} \\\ [...snip...] Adding --host and --target will put autoconf 2.5x into cross compile mode. The result is, some packages will contain funny named binaries such as i586-mandrake-linux-foobar, and need to use ugly hacks to fix it. It's good for all to turn --host and --target off. This has been discussed in various places, I think. -- GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc msg84188/pgp0.pgp Description: PGP signature
RE: [Cooker] More intellegent logging postprocessing
On Mon, 29 Apr 2002, Borsenkow Andrej wrote: In addition to the failure caused by the config bundled inside RPM :( Oh, I forgot to ask - what is the problem with distributed config? Without detailed study it looks more or less O.K. -andrej It's this line: source remote { udp(); }; If it's not commented out, syslog-ng simply refuses to start. Even running syslog-ng -d on command line doesn't help tracing the problem. -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc
Re: [Cooker] Gnome has close to no menu items
On Sun, 28 Apr 2002, Alexander Skwar wrote: When starting Gnome 2, I've got close to no menu items in the Gnome menu. That's with a blank user I created for testing. Is this expected? Alexander Skwar Yes, I think fcrozat has posted many times on cooker list that at least a completely working Gnome 2 desktop is to be packaged before adding any mandrake customization. -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc
Re: [Cooker] Re: Why are .rpmnew files created?
On Sun, 28 Apr 2002, Brian J. Murrell wrote: On Sun, Apr 28, 2002 at 09:45:24PM +0200, Guillaume Cottenceau wrote: The user or any script or something.. In my case anyway, no. Nothing has edited these config files for which .rpmnew files are being created. Next time I do an update I will rpm -Va first and verify that none of the .rpmew files had and md5 errors during the rpm -Va. b. Probably check the access/modification time as well. I'm afraid that problem is deeper than mere md5 sum. -- Abel Cheung GPG Key: (0xC67186FF) http://deaddog.org/gpg.asc