Re: [U4X-Developer] TODO List for 0.1 (psychosis) Release

[Dean S. <dr...@ro...>]

Paul Mundt wrote:
>> I'm trying to make a TODO list for the 0.1 release. Here's what I've
got
>> so far:
>> 
>> To be done to the spec files:
>> - Different groups than the RH ones. The RedHat groups are absolutely
>> terrible; they will make using the install/gnorpm/other packaging
utils
>> diffucult. I'm hacking up a proposal for our groups atm, which may
end
>> up being Mandrake's as I think their model looks fairly good (I need
to
>> study it further however; there will be an upcoming mail to the list
>> regarding the RPM groups)
>> 
>My main concern here is how this'll effect automagic categorizing on
things
>like rpmfind. The default groups may not necessarily be the best to
work with,
>but running off and doing our own thing and breaking compatibility with
>existing applications that use the typical group layout isn't really
something
>I want to bother with either.

>Maybe I'm missing something, if so, feel free to clue me in. I look
forward
>to reading your proposal.

This shouldn't affect rpmfind AFAIK, since just about every RPM based
distro seems to use their own grouping structure.

>> To Be Rebuilt:
>> - Everything currently packaged to make use of new spec files and
>> cryptographically signed
>> 
>We also need everything to go with our standard spec file template
(since this
>is an ideal and doesn't actually exist, I'll write one up. In the
meantime try
>to model as much as possible after the current incarnation of the
libfbx spec
>file, or some such thing).

Yeah, thats what I've been doing in the last few days - making
everything use the proper macros, spacing etc. Once I finish it in the
next few days, Chris said he would audit them and put everything in the
proper order, check for old cruft, etc

>> Yet to be packaged:
>> - lilo (have a spec file, a boot image, coming soon)
>>
>We should probably nuke our ancient dying version from CVS and import
the
>current one to hack upon for 0.2, ideas?

Yeah - I'm not quite sure which version of lilo we're going to go with.
ATM, I'm running lilo 21.7 with SuSe's graphical boot patch. This patch
is nicer than the redhat one, but seems to have issues with text
selection. I'll have to fight with it a bit and get back to you.

>> - egcs (we need to include a compiler capable of building the kernel;
>> egcs 1.1.2 is the officially reccomended version; we may ship it as
kgcc
>> similar to the way redhat did)
>>
>kgcc works for me.

>> - others - libtiff, pppd, NVIDIA drivers (i was hoping for the 0.9.7
>> release to be out soon, but I'm doubting that will happen), mpg123
(ive
>> got a spec file; it should be relatively easy), reiserfstools (if
indeed
>> we do plan on shipping reiserfs), parted, cvs, hdparm, ttf fonts
>>
>Yes, the reiserfs tools will need packaging, as will the XFS tools (the
XFS
>tools can be fetched from SGI's CVS, see http://oss.sgi.com).

Alright, I'll try to take care of those soon

>Also, things like the Ogg Vorbis stuff will need packaging, and the
ALSA
>stuff if it hasn't been done already. Stuff like broadcast 2000
wouldn't
>hurt either.

ok, I'll have to look into bc2000. the other stuff you've asked for was
already on my paper list, i just didnt copy it over. As to alsa, I'm not
very familiar with it, which do I package? Just alsa-0.9b.tar.gz or
whatever? Also, I may package up xine and some of the gatos tools.

>We will need to decide on a layout for our stuff (similar to how SuSE
does
>theirs, with the base packages, development packages, x packages, etc,
etc.)
>so we can search intelligently through the stuff from the installer.

Well, this is the main reason for me wanting to have logical groups in
the spec files. It makes sorting through them much much easier. I'm
hesitant to actually put the RPMS into different folders however; I've
found the way SuSe does it to be confusing at times, and having one
giant dir is fairly easy to find stuff in quickly. 

>> Yet to be given to me:
>> - installer (this isnt much of a priority for the 0.1 release; we can
>> always just hack on the shell script a bit ;-) )
>>
>The shell script sounds like the best solution to me for one, outcast
should
>be ready in about two months as a rough estimate. So the script should
be
>able to hold us over till then.

ok, we'll have to hack it a bit to make it fully functional, but that
should only take a few mins.

>> - inits (paul said these would only take a few hours of hacking?)
>>
>Yep, I've got an old copy of the ones I was originally hacking on
before my
>drive went out.. I'll hack this into submission and document them and
all
>that crap, will get them to you in the next few days.

great

>> - kernel (i know paul has been pounding on it, worst case is that i
put
>> together a kernel with various patches and ship that)
>> 
>Yeah, the stuff in CVS is a wee bit on the busted and out of date side.
This
>is definately one of the things we're going to need to work on, as we
don't
>have a whole lot to work with at the moment.

If you have time to do this, great. If not, I can fold in useful patches
and we can ship that.


Dean