[cooker-amd64] Re: Re: Re: MDK 9.2 for AMD64 packages list

[Duncan]

J.P. Pasnak posted
<47355.24.72.13.147.1070065773.squirrel@warped.warpedsystems.sk.ca>,
excerpted below,  on Fri, 28 Nov 2003 18:29:33 -0600:

[Stephan van der Eijk wrote:]

>> I've got slbd (http://qa.mandrakesoft.com/twiki/bin/view/Main/SlBd) on
>> an amd64 and it's compiling cooker / contrib / plf. It's (the process is
>> fully automated) uploading the contrib and plf packages, Gwenole is
>> taking care of cooker. Since amd64 is a bit different from i586 (aren't
>> all ports?) some stuff won't compile & work out of the box right away. I
>> hope that by making the packages that *do* compile out of the box
>> available, the software will get more exposure and more bugs will be
>> fixed. For the sake of making things clear: the packages this process
>> uploads have not had any form of amd64 specific QA, they are provided
>> "as-is". Use at your own risk...
>>
>> PS: I can also make *unofficial* cooker main packages that this amd64
>> host has built available, if there is enough interest.
>>
> 
> Well, I'm interested :)

That's probably the contrib and plf amd64 mirrors I came across yesterday.
Thanks Stephan!

Issues so far..
 
1) Missing hdlists!  I was getting really frustrated trying to load them
into urpmi.  Cooker Main has a fairly decent hdlist, but the choices for
contribs are synthesis files that have fairly current dates but are
missing packages (putty was the one I was checking) with earlier dates,
and hdlists from the i586 section that of course make urpmi want to
install i586 packages!

PLF is similar.. the hdlist it found makes urpmi want to update i586
packages instead of amd64 packages.

2) Take a look at the dosbox post.  The package installs fine, and the
binary runs, but once running, the mount command, pretty much necessary to
get anything worthwhile done with dosbox as that's the way you add dirs
from your host file system, doesn't seem to do anything.  No errors, no
nothing.  Same with the mem command, which is supposed to return free
memory.  I didn't try the mkdir and similar built-ins, but exit DID seem
to work right!  <g>

3)  I tried recompiling a couple of the plf codec src.rpms, including the
win32, xanim, and real codec packages.   It appears these for the most
part don't compile anything, just copy over the existing binary codecs as
appropriate.  They seemed to be exclusive-arched for the most part as a
result, limited to the archs for which binary codecs were included. 
Naturally, amd64 wasn't included in most, so yes, I can see that these
will either require more work to port or may not be available at all in
64-bit only 32 bit.

4)  I've successfully compiled and am running several src.rpms.  Should I
report those that still require --target x86_64 instead of automatically
taking amd64, or is that being automatically taken care of in the build
process and additional reports at that level will only be more noise.

5)  At least some of the kde stuff, including kmplayer, which I found it
on, needs lib paths adjusted.  As is, the packages have a single lib-qt
path, which needs to be split into the lib-qt-libs binaries path
(lib/qt/lib64 or some such) and headers path (still lib/qt/lib, no 64).  I
solved this locally with a couple symlinks, but that's not really
satisfactory for a Mdk-wide solution.  I haven't checked to see how the
kde packages in main handle it, but do these need reported?  The two I've
tried do rebuild fine with the symlinks and --target x86_64 used.

6)  Report issues 4 and 5 (and others) here or in the regular cooker group?

7) With a dual Opteron (242) system now up and running I'd eventually like
to pitch in and help with this sort of task as well.  However, I've a VERY
long way to get up to speed on this, so unfortunately, I'm not likely to
be much help as anything but a bug spotter right now.  I did go browsing
thru the rpm macros files a bit the last few days, and am getting a bit
better at reading spec files, so at least I can follow the conversations
about it now a bit better..  Still, it'll probably be post 10.0 that I'm
of any real use, and that'll be after all the heavy lifting and main
conversion has been done by the likes of you (which.. thanks again..).

Again, thanks for the post.  I've been trying to get into this, but some
days it feels like I'm just spinning my wheels.. no traction at all.  So,
thanks for the direct post, and thanks for the help in porting the
packages, and thanks in advance for the help and patience from you and
others it will require if I'm to ever become a full package contributor,
which is my current goal.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin