Menu
▾
▴
u4x-developer
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(40) |
Jun
(78) |
Jul
(7) |
Aug
(109) |
Sep
(28) |
Oct
|
Nov
(4) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(75) |
Feb
(20) |
Mar
(9) |
Apr
(6) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Vanessa L. <re...@se...> - 2002-09-12 20:31:40
|
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">
.stbtm {
BACKGROUND-COLOR:#cecbde; BORDER-BOTTOM: #665b8e 1px solid; BORDER-LEFT: #ffffff 1px solid; BORDER-RIGHT: #665b8e 1px solid; BORDER-TOP: #ffffff 1px solid; COLOR: #000000; FONT-SIZE: 12pt; HEIGHT: 26px; WIDTH: 120px; clip: rect( )}
.stedit {
background-color:#484C68; white-space: nowrap; border: #000000; BORDER-BOTTOM: #ffffff 1px solid; BORDER-LEFT: #ffffff 1px solid; BORDER-RIGHT: #ffffff 1px solid; BORDER-TOP: #ffffff 1px solid; FONT-SIZE: 10pt; color: #CCCCCC; font-weight: bold}
</style>
</head>
<BODY leftMargin=0 onload="" topMargin=0 marginheight="0" marginwidth="0" bgcolor="#FFFFFF">
<table width="778" border="0" cellspacing="0" cellpadding="0">
<tr>
<td height="233" width="21"> </td>
<td height="233" colspan="3" width="757">
<table width="621" border="0" cellspacing="0" cellpadding="0" align="left">
<tr>
<td width="373" height="64">
<table width="373" border="0" cellspacing="0" cellpadding="0" background="http://image99.seekercenter.net/skbmp/letter_bg.jpg" height="327">
<tr>
<td><p>
<font face=Arial size=2>
</font> <font face=Arial size=2><font face="Verdana, Arial, Helvetica, sans-serif" color="#000000">Hello,<br>
<br>
I have visited <a href='http://u4x.sourceforge.net'>u4x.sourceforge.net</a> and noticed that your website is not listed on some search engines.
I am sure that through our service the number of people who visit your website will definitely increase. <a target=_blank href="http://www.seekercenter.net/index.php">SeekerCenter</a>
is a unique technology that instantly submits your website
to over 500,000 search engines and directories
-- a really low-cost and effective way to advertise your site.
For more details please go to <a target=_blank href="http://www.seekercenter.net/index.php">SeekerCenter.net</a>.<br>
<br>
Give your website maximum exposure today!<BR>
Looking forward to hearing from you.<br>
<BR>
<table border=0 width=100%><TR><TD width=50%>
<font face="Verdana, Arial, Helvetica, sans-serif" size=2 color="#000000">Best
Regards,<br>
Vanessa Lintner<br>
Sales & Marketing <br>
<a target=_blank href="http://www.seekercenter.net/index.php">www.SeekerCenter.net</a></font></font></font>
<TD><td width=50%>
<div align="center" valign=middle>
<form target=_blank action=http://www.seekercenter.net method=POST>
<input type="submit" name="Submit" value="Signup Now!!!" class="stbtm">
</form>
</div>
</TD>
</TR>
</table>
</td>
</tr>
</table>
</td>
<td width="242" height="64" valign="bottom">
<table width="257" border="0" cellspacing="0" cellpadding="0">
<tr>
<td colspan="3" height="2"></td>
</tr>
<tr>
<td colspan="3" height="3">
<p><img src="http://image99.seekercenter.net/skbmp/letter_top01.jpg" width="326" height="15"></p>
</td>
</tr>
<tr>
<td colspan="3"><img src="http://image99.seekercenter.net/skbmp/letter_right01.jpg" width="31" height="185"><A target=_blank Href ="http://u4x.sourceforge.net"><IMG Src =http://image99.seekercenter.net/skdef/idx.jpg Border=0 width="256" height="184"></A><img src="http://image99.seekercenter.net/skbmp/letter_left01.jpg" width="14" height="185"></td>
</tr>
<tr>
<td colspan="3" height="80" background="http://image99.seekercenter.net/skbmp/letter_bottom01.jpg">
<table width="326" border="0" cellspacing="0" cellpadding="0" height="80">
<tr>
<td width="36" height="43"> </td>
<td width="157" height="43"> </td>
<td width="134" height="43"> </td>
</tr>
<tr>
<td width="36" height="2"> </td>
<td width="157" height="2"> </td>
<td width="134" height="2"> </td>
</tr>
</table>
</td>
</tr>
<tr> </tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
|
|
From: Jonathan T. <jo...@tw...> - 2002-08-02 03:41:19
|
Just out of curiousity, has there been a message sent to this list in the last many months? .. further still, anyone involved in this still alive? -jt |
|
From: Dean S. <dr...@ro...> - 2001-05-01 00:11:10
|
Packaging the kernel doesnt worry me as much as it probably should. If worse comes to worse, we can always look at how the other distribs do it and find the right solution for us. That is, assuming the kernel builds ;-) Dean |
|
From: Paul M. <pm...@mv...> - 2001-04-30 04:28:15
|
On Sat, Apr 28, 2001 at 05:57:23PM -0400, Dean Scott wrote: > >The kernel is a touchy subject. I have not had the time to do extensive > >testing on it, but I do have a stack of bug reports to sift through and > fix. > >There's also updated MOSIX stuff that needs to go in, as well as George's > >new version of the rtsched which plays nicely with Nigel's preemption > patch. > >Most of the instabilities should be worked out in short order, with the > weekend > >approaching I'll have some time to go through it and test things. >=20 > OK cool, I look forward to seeing a nice fixed up kernel. >=20 This brings up the issue of packaging. We're going to have to play around with some spec files for a bit and try to find a good clean method of doing it. We should also look at using the kinstall script (I already have this in an rpm, plus an autoconf/automake tre.. don't ask..) so I can push it to CVS later. The script should definately make packaging a little more consis= tent and clean. > >Okay, apparently my memory is playing tricks on me. What do we have to do > RPM? >=20 > We need to customize it to our macros and do a few other minor things. I > should be able to take care of it myself >=20 Oh, that's right. Have fun with it. > >Yeah, I don't think I'll get to this for awhile, there's too much to do = on > the > >kernel. You might just want to borrow someone elses for the time being, = at > >least for a sane testing ground. >=20 > Hrm, is there a lot of work to be done still on them? Anything I could he= lp > with? >=20 That's a good question, I have to take a look at what's done, as I don't remember. I'll get back to you on IRC later. (Remind me incase I forget). > Also, do we want to ship any archs besides i586 with our alpha release? I > might be able to get athlon packages compiled, I'll have to talk with a > friend of mine (unless scott gets a new connection soon) >=20 Good question, I wouldn't worry about it honestly, considering the amount of work we'll be doing to the system after the alpha is out. Regards, --=20 Paul Mundt <pm...@mv...> MontaVista Software, Inc. |
|
From: Dean S. <dr...@ro...> - 2001-04-28 21:55:37
|
>----- Original Message ----- >From: "Paul Mundt" <pm...@mv...> >To: <u4x...@li...> >Sent: Saturday, April 28, 2001 3:06 PM >Subject: Re: [U4X-Developer] Status Report >On Fri, Apr 27, 2001 at 08:56:17PM -0400, Paul Mundt wrote: >> Packages that need to be done - >> alsa utils > >Just a note on the ALSA stuff, since I merged the drivers into the kernel, >we only need to package the libs and utils. Right - thats all I was planning on packaging in the first place ;-) >> kernel (lethal? is this even close to being ready to go?) >The kernel is a touchy subject. I have not had the time to do extensive >testing on it, but I do have a stack of bug reports to sift through and fix. >There's also updated MOSIX stuff that needs to go in, as well as George's >new version of the rtsched which plays nicely with Nigel's preemption patch. >Most of the instabilities should be worked out in short order, with the weekend >approaching I'll have some time to go through it and test things. OK cool, I look forward to seeing a nice fixed up kernel. >> vim (the specfile just needs a bit of hacking, shouldnt take long) > >Which version are you packaging? 6.0ac is current. I think I was working on 6.0z or some such, although I doubt it will take much work to change versions. > >> rpm (needs some minor hacking to suit our needs, then it should be good >> to go. this hasnt been done yet) > >Okay, apparently my memory is playing tricks on me. What do we have to do RPM? We need to customize it to our macros and do a few other minor things. I should be able to take care of it myself > >> reiserfstools (ive been holding off on doing these as they seem to >> change frequently) > >Go with the latest. Then submit package updates every couple revisions (or >for serious bug fixes). Don't worry about minor changes. OK >> inits (/me pokes lethal several times with a razor sharp stick) > >Yeah, I don't think I'll get to this for awhile, there's too much to do on the >kernel. You might just want to borrow someone elses for the time being, at >least for a sane testing ground. Hrm, is there a lot of work to be done still on them? Anything I could help with? Also, do we want to ship any archs besides i586 with our alpha release? I might be able to get athlon packages compiled, I'll have to talk with a friend of mine (unless scott gets a new connection soon) Dean Scott |
|
From: Paul M. <pm...@mv...> - 2001-04-28 19:03:39
|
On Fri, Apr 27, 2001 at 08:56:17PM -0400, Dean Scott wrote: > Packages that need to be done - > alsa utils Just a note on the ALSA stuff, since I merged the drivers into the kernel, we only need to package the libs and utils. > kernel (lethal? is this even close to being ready to go?) The kernel is a touchy subject. I have not had the time to do extensive testing on it, but I do have a stack of bug reports to sift through and fix. There's also updated MOSIX stuff that needs to go in, as well as George's new version of the rtsched which plays nicely with Nigel's preemption patch. Most of the instabilities should be worked out in short order, with the wee= kend approaching I'll have some time to go through it and test things. > vim (the specfile just needs a bit of hacking, shouldnt take long) Which version are you packaging? 6.0ac is current. > rpm (needs some minor hacking to suit our needs, then it should be good > to go. this hasnt been done yet) Okay, apparently my memory is playing tricks on me. What do we have to do R= PM? > reiserfstools (ive been holding off on doing these as they seem to > change frequently) Go with the latest. Then submit package updates every couple revisions (or for serious bug fixes). Don't worry about minor changes. > inits (/me pokes lethal several times with a razor sharp stick) Yeah, I don't think I'll get to this for awhile, there's too much to do on = the kernel. You might just want to borrow someone elses for the time being, at least for a sane testing ground. --=20 Paul Mundt <pm...@mv...> MontaVista Software, Inc. |
|
From: Dean S. <dr...@ro...> - 2001-04-28 04:20:07
|
On 28 Apr 2001 00:18:59 -0400, Dean Scott wrote: > On 27 Apr 2001 20:56:17 -0400, Dean Scott wrote: > > XFree86 (this is looking really good, ive got XFree86 4.0.99.3 with DRI > > sync patches and ATI XV and DGA patches, its almost done, i hope to have > > testing rpms tomorrow) > > Hrm, well, actually, I have rpms tonight! They're on the ftp, please > test them out and let me know if they work ok for you. NOTE: Since > Lethal has not yet given me the inits, these RPMS do not initialize xfs > themselves and you will have to either preserve your old xfs startup > script manually or manually initialize xfs. Happy testing! Also, they are a bit large right now because they are unstripped. They will become smaller as I implement some targeted stripping (the whole package cannot be stripped because if the drivers are stripped they will not load) Dean |
|
From: Dean S. <dr...@ro...> - 2001-04-28 04:17:14
|
On 27 Apr 2001 20:56:17 -0400, Dean Scott wrote: > XFree86 (this is looking really good, ive got XFree86 4.0.99.3 with DRI > sync patches and ATI XV and DGA patches, its almost done, i hope to have > testing rpms tomorrow) Hrm, well, actually, I have rpms tonight! They're on the ftp, please test them out and let me know if they work ok for you. NOTE: Since Lethal has not yet given me the inits, these RPMS do not initialize xfs themselves and you will have to either preserve your old xfs startup script manually or manually initialize xfs. Happy testing! Dean |
|
From: Dean S. <dr...@ro...> - 2001-04-28 00:54:32
|
Hey guys, there hasn't been any list traffic in eons so heres whats left for the first alpha release: Packages that need to be done - alsa utils kernel (lethal? is this even close to being ready to go?) XFree86 (this is looking really good, ive got XFree86 4.0.99.3 with DRI sync patches and ATI XV and DGA patches, its almost done, i hope to have testing rpms tomorrow) gcc (needs a minor trivial fixup, ill post new rpms rsn) vim (the specfile just needs a bit of hacking, shouldnt take long) bc (i got a specfile for it yesterday, should be done rsn) parted (same as bc) rpm (needs some minor hacking to suit our needs, then it should be good to go. this hasnt been done yet) reiserfstools (ive been holding off on doing these as they seem to change frequently) shadowpwd sysklogd inits (/me pokes lethal several times with a razor sharp stick) directfb (we only need this if we decide to use this instead of libfbx) Is there anything else we need for the initial release? I've got some other packages on my list, but they dont seem essential for release (although they would be nice). For a desktop you should be able to use the rh7.1 ximian packages (I think, i would interested to know what dep problems people have so they can be resolved). Hrm, thats just about everything thats on my mind, feel free to comment/scream/flame, and I'm sure lethal/mjs would love to chime in Also, has anyone found/willing to offer a server for the u4x dns? Dean |
|
From: Dean S. <dr...@ro...> - 2001-03-05 01:24:58
|
> At this point we'll also start taking additional feature requests > (minor ones for 0.2.x and major ones for 0.3.0). I figured I'd go on record as saying it: freetype 2 support! :-) There is some excellent documentation on their site (freetype.sourceforge.net) as well as in their ft2demos package for code examples. SDL seems to have a ttf extension that uses freetype in the loki CVS. Dean |
|
From: Paul M. <le...@ch...> - 2001-03-05 01:01:29
|
libfbx 0.2.0 is finally here and ready for testing. This is a little late, but it's better late than never. Although there are far too many changes to list (or remember) the most notable changes are: - Modular hardware optimizations - Additional architecture optimizations - Additional libfbx-gui work - API restructuring - Better font support - <insert additional features here> For a more complete list, see the ChangeLog. This release can be grabbed at the usual place: ftp://ftp.u4x.org/pub/u4x/projects/libfbx/ At this point we'll also start taking additional feature requests (minor ones for 0.2.x and major ones for 0.3.0). Regards, --=20 ,----------------------------------------------------, | Paul Mundt | Email: le...@ch... | | Head Developer | URL: http://www.u4x.org | | Head of Security | URL: http://www.stampede.org | `----------------------------------------------------' |
|
From: Paul M. <le...@ch...> - 2001-03-04 21:44:58
|
On Sun, Mar 04, 2001 at 12:56:01PM -0500, Dean Scott wrote: > > ALSA is split up into 3 components, alsa-driver, alsa-lib, and alsa-uti= ls. > > alsa-driver is a bunch of modules that is built for your specific kernel > > and shoved in /lib/modules/`uname -r`/misc/ (not at all compliant with = the > > new modutils, but that can be fixed). alsa-lib is basically all the lame > > userspace library stuff that applications like to link against and go > > through. and alsa-utils is, as the name suggests, various utilities. Su= ch > > as alsamixer/alsactl/etc. >=20 > So, I should package lib and utils? >=20 Yeah, not sure about driver, it'll likely need packaging as well, but it'll need to be packaged against our default kernel. > > The only reason it's confusing when SuSE does it, is because they use a > > braindead naming scheme. They also truncate the filename making it even > > more fun to search the repository in search of what you want. As long as > > we use simple and to the point directory names, don't screw with the fi= le > > names, and have a nice INDEX in the top level directory that lists all = of > > the files, with a brief description of them (possibly extracted via rpm, > > this could be done in a script and croned) then we shouldn't have any > > issues with it. My main problem with sticking everything into one > > directory is that it makes it an absolute total mess to find what you're > > looking for (outside of the installer) and it's about as useless to look > > at as the SourceForge UI. >=20 > It's a bit messy, but it's alphabetized, which makes it easy if you know > what you're looking for. >=20 Alphabetized is good and useless if you don't know the name of what you're looking for. This is the whole purpose of directories, so you can more intelligently organize the stuff. Putting everything in a single directory is severely brain damaged. Regards, --=20 ,----------------------------------------------------, | Paul Mundt | Email: le...@ch... | | Head Developer | URL: http://www.u4x.org | | Head of Security | URL: http://www.stampede.org | `----------------------------------------------------' |
|
From: Dean S. <dr...@ro...> - 2001-03-04 17:55:09
|
oops, heres the patch |
|
From: Dean S. <dr...@ro...> - 2001-03-04 17:54:23
|
On 04 Mar 2001 12:32:57 -0500, Paul Mundt wrote: > On Sun, Mar 04, 2001 at 12:07:28PM -0500, Dean Scott wrote: > > >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. > > > Text coloring and proper positioning was one of the issues I ran into when > I was originally hacking up lilo for this stuff. I've never seen SuSE's > patch though, I can take a look at it later if necessary. It's attached. > > > >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. > > > ALSA is split up into 3 components, alsa-driver, alsa-lib, and alsa-utils. > alsa-driver is a bunch of modules that is built for your specific kernel > and shoved in /lib/modules/`uname -r`/misc/ (not at all compliant with the > new modutils, but that can be fixed). alsa-lib is basically all the lame > userspace library stuff that applications like to link against and go > through. and alsa-utils is, as the name suggests, various utilities. Such > as alsamixer/alsactl/etc. So, I should package lib and utils? > > See about getting your list of packages written up in a form we can shove > on the website so we can add packages as we need to and have them marked > as 'todo' or 'done' or whatever. Yeah, maybe we can hook it into the bug tracker or something > > > 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. > > > The only reason it's confusing when SuSE does it, is because they use a > braindead naming scheme. They also truncate the filename making it even > more fun to search the repository in search of what you want. As long as > we use simple and to the point directory names, don't screw with the file > names, and have a nice INDEX in the top level directory that lists all of > the files, with a brief description of them (possibly extracted via rpm, > this could be done in a script and croned) then we shouldn't have any > issues with it. My main problem with sticking everything into one > directory is that it makes it an absolute total mess to find what you're > looking for (outside of the installer) and it's about as useless to look > at as the SourceForge UI. It's a bit messy, but it's alphabetized, which makes it easy if you know what you're looking for. > > > >> - 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. > > > Yeah, it's already high on my todo list, will start hammering on it some > more as time allows. Feel free to do your own patch though and shove it > on the ftp, always good to have variety. That's alright ;-) Dean |
|
From: Paul M. <le...@ch...> - 2001-03-04 17:32:38
|
On Sun, Mar 04, 2001 at 12:07:28PM -0500, Dean Scott wrote: > >We should probably nuke our ancient dying version from CVS and import > the > >current one to hack upon for 0.2, ideas? >=20 > 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. >=20 Text coloring and proper positioning was one of the issues I ran into when I was originally hacking up lilo for this stuff. I've never seen SuSE's patch though, I can take a look at it later if necessary. > >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. >=20 > 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. >=20 ALSA is split up into 3 components, alsa-driver, alsa-lib, and alsa-utils. alsa-driver is a bunch of modules that is built for your specific kernel and shoved in /lib/modules/`uname -r`/misc/ (not at all compliant with the new modutils, but that can be fixed). alsa-lib is basically all the lame userspace library stuff that applications like to link against and go through. and alsa-utils is, as the name suggests, various utilities. Such as alsamixer/alsactl/etc. See about getting your list of packages written up in a form we can shove on the website so we can add packages as we need to and have them marked as 'todo' or 'done' or whatever. > 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.=20 >=20 The only reason it's confusing when SuSE does it, is because they use a braindead naming scheme. They also truncate the filename making it even more fun to search the repository in search of what you want. As long as we use simple and to the point directory names, don't screw with the file names, and have a nice INDEX in the top level directory that lists all of the files, with a brief description of them (possibly extracted via rpm, this could be done in a script and croned) then we shouldn't have any issues with it. My main problem with sticking everything into one directory is that it makes it an absolute total mess to find what you're looking for (outside of the installer) and it's about as useless to look at as the SourceForge UI. > >> - kernel (i know paul has been pounding on it, worst case is that i > put > >> together a kernel with various patches and ship that) > >>=20 > >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. >=20 > If you have time to do this, great. If not, I can fold in useful patches > and we can ship that. >=20 Yeah, it's already high on my todo list, will start hammering on it some more as time allows. Feel free to do your own patch though and shove it on the ftp, always good to have variety. Regards, --=20 ,----------------------------------------------------, | Paul Mundt | Email: le...@ch... | | Head Developer | URL: http://www.u4x.org | | Head of Security | URL: http://www.stampede.org | `----------------------------------------------------' |
|
From: Dean S. <dr...@ro...> - 2001-03-04 17:05:54
|
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 |
|
From: Paul M. <le...@ch...> - 2001-03-04 07:12:26
|
On Sun, Mar 04, 2001 at 01:01:17AM -0500, Dean Scott wrote: > I'm trying to make a TODO list for the 0.1 release. Here's what I've got > so far: >=20 > 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) >=20 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 wi= th, but running off and doing our own thing and breaking compatibility with existing applications that use the typical group layout isn't really someth= ing 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. > To Be Rebuilt: > - Everything currently packaged to make use of new spec files and > cryptographically signed >=20 We also need everything to go with our standard spec file template (since t= his 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 sp= ec file, or some such thing). > 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? > - 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). 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. 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. > 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. > - 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. > - kernel (i know paul has been pounding on it, worst case is that i put > together a kernel with various patches and ship that) >=20 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. Regards, --=20 ,----------------------------------------------------, | Paul Mundt | Email: le...@ch... | | Head Developer | URL: http://www.u4x.org | | Head of Security | URL: http://www.stampede.org | `----------------------------------------------------' |
|
From: Dean S. <dr...@ro...> - 2001-03-04 05:59:38
|
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: - Proper i8n support via the %find-lang macro; this is a minor issue and can be done later, as fixing bugs in 0.1 is far more important at this stage - 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) To Be Rebuilt: - Everything currently packaged to make use of new spec files and cryptographically signed Yet to be packaged: - libjpeg (have a spec file, am working on it) - lilo (have a spec file, a boot image, coming soon) - vim (have a barebones spec file, will try to get to it this week) - 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) - 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 (possibly; i will have to look into this further and see if i can find fonts under acceptable licenses or something; theres always the fetchmsttfonts script in the XFree86 packages), libfbx (this can be packaged whenever we feel like it, the spec file is excellent and will take mebbe 5 secs of modification) (Note: the above list is mostly stuff I would like to see in 0.1; some of it can wait for 0.2 if needed) - what else?? (Note: any gtk/gnome stuff will most likely have to wait for 0.2 or just a later part of 0.1; i want to get this out and test it first. if you want to use gtk/gnome with this release, the rh7 helix packages should work fine, although they may require a bit of --nodeps --force loving. there's not much point in building gnome packages with our limited resources atm, as gnome 1.4 official will hit the street soon enough) 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 ;-) ) - inits (paul said these would only take a few hours of hacking?) - kernel (i know paul has been pounding on it, worst case is that i put together a kernel with various patches and ship that) Suggestions, rants, flames, cries of terror, tears of joy, etc are appreciated Dean |
|
From: Nick L. <ta...@br...> - 2001-02-21 19:55:10
|
On Sat, Feb 17, 2001 at 02:15:22PM -0500, Paul Mundt wrote: > It has come to my attention that the current font setup under > libfbx just plain sucks. In fact, sucking would be a good thing > in comparison. We need to do a few of the following before it > will be even remotely useful: > > - Include a lame default font in a header > + This can be small > + It gives us a fallback for systems > not equipped with our list of supported > fonts. > - Provide support for other types of fonts > + We can dynamically load a wide variety > of different fonts. > > The only problem with supporting multiple types of fonts, is > the lame overhead (and code size) that we add into libfbx just > for supporting them. I'm scared to mention this .. as the overhead would be huse.. but we really should look seriously into supporting TTF (true-type) because everyone and their pet monkey's uncle uses em. -- -) Nick Linder -) Professional Computer Geek -) ta...@br... -) http://www.brokengod.org |
|
From: Mike B. <nit...@sl...> - 2001-02-19 07:43:02
|
Paul Mundt wrote: > > It has come to my attention that the current font setup under > libfbx just plain sucks. In fact, sucking would be a good thing > in comparison. We need to do a few of the following before it > will be even remotely useful: > > - Include a lame default font in a header > + This can be small > + It gives us a fallback for systems > not equipped with our list of supported > fonts. > - Provide support for other types of fonts > + We can dynamically load a wide variety > of different fonts. > > The only problem with supporting multiple types of fonts, is > the lame overhead (and code size) that we add into libfbx just > for supporting them. > > Right now, libfbx-font.c is roughly 13kB. Reallistically, we > don't want to exceed 25kB on all of our font support in > total (not including the font in a header, of course). So.. > I'm open to suggestions that people have on what we should look > at supporting. > > Any other points anyone want to make on this issue? Bitmapped fonts would be nice. Look at allegro for examples. -- Michael Bourgeous E-mail: nit...@sl..., nit...@u4... Reply-to: nit...@so... "Too many people are thinking of security instead of opportunity. They seem more afraid of life than death." -- James F. Byrnes |
|
From: Paul M. <le...@ch...> - 2001-02-19 07:16:36
|
It has come to my attention that the current font setup under libfbx just plain sucks. In fact, sucking would be a good thing in comparison. We need to do a few of the following before it will be even remotely useful: - Include a lame default font in a header + This can be small + It gives us a fallback for systems not equipped with our list of supported fonts. - Provide support for other types of fonts + We can dynamically load a wide variety of different fonts. =09 The only problem with supporting multiple types of fonts, is the lame overhead (and code size) that we add into libfbx just for supporting them. Right now, libfbx-font.c is roughly 13kB. Reallistically, we don't want to exceed 25kB on all of our font support in total (not including the font in a header, of course). So.. I'm open to suggestions that people have on what we should look at supporting. Any other points anyone want to make on this issue? Regards, --=20 ,----------------------------------------------------, | Paul Mundt | Email: le...@ch... | | Head Developer | URL: http://www.u4x.org | | Head of Security | URL: http://www.stampede.org | `----------------------------------------------------' |
|
From: Nick L. <ta...@br...> - 2001-02-11 06:07:56
|
On Sat, Feb 10, 2001 at 11:35:44AM -0700, Mike Bourgeous wrote: > > OS/2? Umm... Why? Linux is better man. Course it is. I just think OS/2 was a very cute thing when it was happenin'. Integrated voice support, decent UI, M$-Application support. My first love is to linux, of course. But I have a lot of respect for OS/2 Warp 4 as its very solid. -- -) Nick Linder -) Professional Computer Geek -) ta...@br... -) http://www.brokengod.org |
|
From: Mike B. <nit...@sl...> - 2001-02-10 18:41:12
|
Nick Linder wrote: > > This is probably an extremely useless reply but YEAH WOO OS/2 SUPPORT! heh.. > I'm an OS/2 fan. :P > Also if anyone needs OS/2 stuff they can gimme a shout on IRC. OS/2? Umm... Why? Linux is better man. -- Michael Bourgeous E-mail: nit...@sl..., nit...@u4... Reply-to: nit...@so... "Too many people are thinking of security instead of opportunity. They seem more afraid of life than death." -- James F. Byrnes |
|
From: Mike B. <nit...@sl...> - 2001-02-10 18:40:14
|
Paul Mundt wrote: > 2) We could go the uber-fascist route (no, not the FSF way) > and look into doing a really small microkernel with nothing > but the bare necessities. > 3) We could bring up the second system in a VM and interface > with it as much as possible. What I was thinking is that we could use both the microkernel and VM ideas in one, and make a micro-OS, kinda like what exists on some (all?) main frames, and load the different OS's in different VM's, and then save each VM state to disk on a vision type partition or something... That way, the OS only has to be booted once, and then vision will interface with the micro-OS to request a swap of the VM. This also gives us the advantage that system booting will be nearly instantaneous, except when an OS requires a restart. In that case, the Vision micro-OS would intercept the OS's reboot request, and just restart the VM in a manner safe for Vision. -- Michael Bourgeous E-mail: nit...@sl..., nit...@u4... Reply-to: nit...@so... "Too many people are thinking of security instead of opportunity. They seem more afraid of life than death." -- James F. Byrnes |
|
From: Mike B. <nit...@sl...> - 2001-02-10 18:29:18
|
Rob Salmond wrote: > > Just a small idea I had while browsing libfbx-surface.c. There seems to > be no support yet for creating an offscreen surface in video memory which is > of course copied faster to the screen buffer. If support for that were > added routines could be included in vision for loading commonly used > graphics ( gui widgets, etc ) into video memory to enhance performance. A > rather simple idea which would also leave more room in system memory for ... > the system. I was going to work on this eventually, but since it requires a virtual screen size greater than the physical screen size, it's impossible with vesafb, and the extent to which it can be accomplished varies based on how much RAM the video card has. But then, since vesafb doesn't have acceleration anyway, we can count that out. We'll have to calculate how much off-screen space we can have, and then reset the framebuffer for the new virtual size. I was thinking that rather than add support for video bitmaps, it would be easier to just make fb_screen have a virtual y size that's as large as it can be. Then, I could write an fb_video_blit that will take source x, source y, dest x, dest y, width, and height as parameters, and would only be available in accelerated drivers. The programmer would then just make a simple check to decide whether to use video or system memory for these things. This will also make it easier to do page flipping, and that could get fun. libfbx might be useful for games by then. -- Michael Bourgeous E-mail: nit...@sl..., nit...@u4... Reply-to: nit...@so... "Too many people are thinking of security instead of opportunity. They seem more afraid of life than death." -- James F. Byrnes |
