Re: ooffice
On Thu, 28 Nov 2002, Stew Benedict wrote: Also oopadmin (openoffice setup program) is missing from my install, one of its things is font installation:) I thought the admin program was spadmin? spadmin is here indeed for spool administration, mostly printer setup. But we have printerdrake which generates OOo and StarOffice profiles very well, so why bother with spadmin? I won't provide an oopadmin wrapper script, as people that really want that will not what to do, in an unsupported manner. Bye, Gwenole.
Re: more on RPMs
Hi, Agreed. But somehow I don't see that as happening. The best alternative to an automated build system is to give you guys complete control over your archs. They have. Any port chooses what to put in the distribution, even some bits of contribs if you wish. I don't see the problem or you have to enlight me. That's what happens for ia64, x86-64, ppc. Changes are always merged back in cooker, otherwise this can't work. Also, new SRPMs are rsync'ed in the alternate arch and rpm- rebuilder'ized. Bye, Gwenole.
Re: openoffice?
On Fri, 17 May 2002, Michael Marcucio wrote: well i thought it was yellowdog because it is hosted here:) ftp://ftp.yellowdoglinux.com/pub/yellowdog/software/openoffice/ Aren't those simple repackaging of the binaries? i.e. they don't build the binaries themselves but provide Kevin's.
Re: PPC SRPMS proposal
On Wed, 24 Apr 2002, Ben Reser wrote: WHEREAS, Mandrake PPC Cooker, towards the end of the development cycle falls out of sync with Cooker x86. As a result the SRPMS for it start disappearing, unless they are identical to the released version. It's normal Cooker x86 remains with new stuff, as 8.2 x86 is released. 8.2 ppc is based on... 8.2 packages, not cooker. WHEREAS, In the process of making custom changes just for PPC that do not get rolled into x86 Mandrake may make patches to the source of various GPL programs. Patches made up in the port process should be merged in Cooker, when the stable port branch is released. THEREFOR, I propose that the following directory tree be made on the Mandrake mirrors: a) Mandrake-devel/cooker/SRPMS/ppc, would contain the SRPMS for cooker-ppc that differ from the current ones in X86, plus ones for packages that are point releases (as defined above). b) Mandrake/current/SRPMS/ppc, contains SRPMS for the current release of Mandrake PPC that differ from the SRPMS for the x86 version of the same release. This would minimize duplication on the mirrors but would make valuable SRPMS available. I believe this is already the case. [gb@no gcc]$ cat /mnt/BIG/dis/vitamin/ia64/Mandrake/SRPMS/0INDEX Mandrake Linux/Itanium 8.1 Sources == Mandrake and its logo are trademarks of MandrakeSoft S.A. Red Hat, RPM and glint are trademarks of Red Hat Software, Inc. Other trademarks are copyrighted by their respective owners. Contents of this directory -- This directory contains the source RPMs for Mandrake Linux/Itanium 8.1 that differs from the common set available for Mandrake Linux/Ix86 8.1. Package Name Version-Release DrakX 8.1-2mdk [...] Bye, Gwenole.
Re: PPC SRPMS proposal
On Thu, 25 Apr 2002, Olivier Thauvin wrote: [gb@no gcc]$ cat /mnt/BIG/dis/vitamin/ia64/Mandrake/SRPMS/0INDEX Hum, and how can we access to this tree, mirror are differents: ncftp ...andrake/Mandrake-devel ls cooker/ You are looking at Cooker, but we were talking about stable trees (e.g. bluebird). So, that should go into Mandrake/version/arch/. For example when I build a contrib package for x86, when is it port to other arch ? Never if contribs are not taken into account, which usually is the case. Main should be enough and already burns out 2 CDs completely. Bye, Gwenole.
Re: PPC SRPMS proposal
On Thu, 25 Apr 2002, Ben Reser wrote: Yes and they normally are. But if Stew is say a month behind you and he makes a patch and releases a 2.4.18-6.2mdk kernel and you're already on 12mdk there can be one heck of a lot of difference between the two. Yes, kernel is another problem. AFAIK, Stew usually send patches for kernel release N, but Juan includes them for N+2 since N+1 is usally already on the way at this time. Yes, things that worked at release N could break at release N+2. I believe kernel changes should be notified and while kernel N+2 is building on x86, SRPMs should be generated and propagated to other arches, for build checking. Uhh PPC != ia64. Yes, but the process is likewise. And what's on your private machines is not neccessarily available to the rest of the world. [breser@stream SRPMS]$ pwd /mirror/linux/mandrake/Mandrake/8.1/SRPMS [breser@stream SRPMS]$ ls -l ia64 [breser@stream ia64]$ pwd /mirror/linux/mandrake/Mandrake/8.1/ia64 [breser@stream ia64]$ ls -l SRPMS ls: SRPMS: No such file or directory Hmmm, probably that directory didn't get propagated to the primary mirror. Warly? That should be Mandrake/8.1/ia64/Mandrake/SRPMS though I'd prefer Mandrake/8.1/SRPMS/ia64/ too, on mirrors. You totally ignored my GPL point. I haven't. It's pretty silly that I've tried to come up with a solution for everyone's desire to have PPC SRPMS but at the same time tried to be reasonable about not wasting gobs of space on the mirrors That's the actual solution I explained to you.
Re: %make failed and beta2 report
On Thu, 28 Mar 2002, Olivier Thauvin wrote: 4) The most important, I am rebuilding some plf package for ppc, but the make failed if %make is invoked in spec file. The make directive work properly but I think this is a bad optmisation flag but I can't help you for that. I have just the message fg, no job running. rpm --eval %make should yield make [-jnumprocs] If --eval %thing returns %thing, that's simply because rpm doesn't know about %thing. Please check /usr/lib/rpm/ppc-mandrake-linux/macros or /usr/lib/rpm/macros for %make definition. On x86 side, the %make macro is defined in /usr/lib/rpm/i586-mandrake-linux/macros Bye, Gwenole.
Re: XFree86-4.1.0-19mdk and PPC..
On Wed, 17 Oct 2001, Ben Reser wrote:
I believe -fno-merge-constants is a x86 only thing. It's a compiler
optimization that was added and turned on by default. That flag turns
it off. If you compiler doesn't support it then it doesn't support the
optimization either so removing it will not harm anything.
Hmm, forgot to make a fix for XFree86. Constants merging is not an
x86-only thing. It's just that option got backported to gcc-2.96 and
3.0.x from gcc-3.1.
A patch is attached.
--- XFree86-4.spec~ Thu Oct 4 21:51:39 2001
+++ XFree86-4.spec Thu Oct 18 09:08:25 2001
@@ -526,6 +526,9 @@
# S3 driver
cd xc/programs/Xserver/hw/xfree86/drivers; bzcat %{SOURCE203} | tar xf -; cd -
+# Check for constants merging capabilities to disable
+NO_MERGE_CONSTANTS=$(if %{__cc} -fno-merge-constants -S -o /dev/null -xc /dev/null
+/dev/null 21; then echo -fno-merge-constants; fi)
+
cat xc/config/cf/host.def END
%if %{BuildDebugVersion}
#define XFree86Devel YES
@@ -536,7 +539,7 @@
#define DefaultGcc2AxpOpt $RPM_OPT_FLAGS
#define NeedModuleRanlib YES
-#define ModuleCFlags \$(CDEBUGFLAGS) \$(CCOPTIONS) -fno-merge-constants \
+#define ModuleCFlags \$(CDEBUGFLAGS) \$(CCOPTIONS) $NO_MERGE_CONSTANTS \
\$(THREAD_CFLAGS) \$(ALLDEFINES)
#define ModuleRanlibCmdRanlibCmd
