Re: Example of really nasty DD behavior
On Sun, Nov 16, 2003 at 03:38:30PM +0100, Josip Rodin wrote: > > I'm sorry that you feel disappointed, but the other developer didn't seem to > do anything "really nasty", he was merely much more expeditious than you > were. He could have posted his ITP sooner, too (unless in the unlikely event > he actually made the package in a few minutes) Depending on how you define few, this is actually the case. It was less than an hour work for libxklavier and gswitchit combined, anyway. Regards, Filip -- "My opinions may have changed, but not the fact that I am right" -- fortune cookie database
Re: Example of really nasty DD behavior
On Sat, Nov 15, 2003 at 11:55:46PM +0100, Duck wrote: > Filip Van Raemdonck <[EMAIL PROTECTED]> wrote : > > > > libxklavier & gswitchit packages are uploaded and waiting to be added by > > ftp-master. > > This nasty behavior shows that being an officiel Debian developer > does not mean quality. What's actually nasty about this? And what does any of it have to do with quality, or lack of it? > You did work on your own without any notice. > May i remeber you the use of IPTs and RFPs ? May I remember you it's retitling an RFP into ITP you responded to? Which was meant to avoid anyone else going through useless effort while the packages are waiting for ftp-master intervenience. > These are tools to inform people about works to be done and work in > progress in order to avoid duplicate work. > As u did not fill any ITP nor informed anybody on this RFP, u did make > me loose my time preparing for doing this packaging. Uh-huh. So where was yours to avoid others' duplicate work? > I did contact him, but you didn't. Because I hadn't yet does not mean I wouldn't. And it isn't a strict requirement, anyway. > Another thing, someone had already packaged this program (see web site); > he is not a Debian developer and has not enought time to become one. I checked the NM queue and noticed he was not in there. Nor did he indicate any wish to become one in his earlier messages to the BTS, instead these messages rather suggest that he does not (which is apparently true) due to lack of expressing such interest. And when I checked the url yesterday it was unreachable. Seems to work fine now, though. > he could have made this package to be prepared and then propose > it into Debian. He reported creating them on the 5th of august. Ample time to propose them into Debian since then, wouldn't you think? > You could have some respect for his work, even if he is not a DD. Who says I don't? I did not check his work, because I could not reach the site, but that does not mean I disrespect it. On Sun, Nov 16, 2003 at 02:14:48PM +0100, Duck wrote: > > As Martin Pitt said, I think it's wise contacting related persons, look at > the program, and then, when you relly want to package it, write an ITP. > I won't post hundreds of ITPs in advance to be sure to get the packages i > like and then reopen them when i don't those. I think it's wise to see if one is capable of building packages, then ITP. As you state, there are too many ITPs which are never fullfilled. Since in this case it was an old RFP, I immediately uploaded the packages as well. > And i don't think i'd like to work with a guy who is unable to communicate. Pity. One of these weeks I was about to contact you to see if you were in need of a sponsor of arkhart, following up to <[EMAIL PROTECTED]> Which is a message you sent to debian-mentors 3 months ago, while you only sent ITPs for arkhart 10 days ago. Seems you are a little late yourself? *Shrug* Well, the offer stands. I'm currently working out things with someone else to sponsor an RFAd package, but when that's worked out I'll sponsor you, if you wish. Regards, Filip -- "From a security perspective, Bluetooth is a disaster waiting to happen." -- Martin Reynolds
Re: Upcoming bug mass-filing re. non-free TrueType fonts in main
On Fri, Aug 02, 2002 at 01:16:14PM -0300, Ben Armstrong wrote: > > [1] I have been told that the OpenOffice fonts are not free and were > pulled from CVS a short while ago. This puts ttf-openoffice > into question and any other package that contains a font included > in ttf-openoffice. I need confirmation of this before I can file > bugs. Are you sure? They were originally released with OO, and because of that should be regarded as free unless the original release was a mistake. But when I RFPed them, they were cvs removed because of X server errors - not license issues. Although I can't even find them anymore now through the CVS web view. Not even in Attic. Although I also can't find anything in the OO bugzilla or the list archives about license problems. Oh well. As a coincidence, I wrote down a number of URLs for font sites from an old magazine I threw away a few weeks ago and went hunting for free (as in speech) fonts. I've found some, but it was even harder than I thought it would've been. Expect an ITP soon. I've also found one particular font author who had a good number of `freeware' ones, which allowed just about anything except modification. I've contacted him, and his initial reply was positive. I'll see how things evolve. Regards, Filip -- "If I have seen farther than others, it is because I was standing on the shoulders of giants." -- Sir Isaac Newton pgpo5YCr523Pm.pgp Description: PGP signature
Pingus, and ClanLib (Re: maintainer for cervisia is MIA)
On Tue, Jan 08, 2002 at 01:20:56PM +0100, Tille, Andreas wrote: > > (Remark: It doesn't matter which ClanLib versions > you use to compile other games against. There are just Lintian and > packaging issues. Filip, did you had a look at my packages???) The packages I have ready are based on your 0.5.1-0.1 packages. I saw you took them to make a -3, but haven't had time to do anything with it yet (see below) > We should try to get all those games compiling with 0.5.2 and let them > stabilize with this version (at least CVS of all three Games - Pingus, > Trophy and Race seem to use this). Someone should check ClanBomber and > perhaps others. ClanBomber has been checked by its maintainer. It was fine aside from one issue: the build asked a question and thus required manual intervention to answer. I haven't tried building ClanBomber myself and I'm not sure if this is a problem with the ClanBomber build system or with the ClanLib packages. > Filip is waiting for some response about that and he intents to make > ClanLib 0.5.2 official packages. That is the idea, but I'm a little occupied with professional and private obligations since about a week or three. If someone ask me to NMU, I'll probably say go for it - unless I can free some time by then. Regards, Filip -- If Windows is the answer, I want the problems back! pgpt3x5QLtt0d.pgp Description: PGP signature
Re: [RFC] Developer documentation packages.
On Thu, Sep 13, 2001 at 04:48:12PM +0200, Francesco P. Lovergine wrote: > > It could be nice if all you send me a collection of ebooks you think > is a must for a developer. Only HTML/PDF/PS/TXT formats. ^^^ Why is that? I find PDF/PS formats to be totally useless to me very often. Reason? If it's packaged by an American developer, it will be in letter papersize 99% of the time. (are there other parts of the world that use letter?) Not only is this totally useless if I want to print a few pages out of this, but also I feel "disoriented" (I can't think of a better way to describe it) when viewing a document on screen in this different aspect ratio. IMHO it would be better to provide HTML and text formats, together with the source format from where on the preferred document format can be generated. Regards, Filip -- It's as BAD as you think, and they ARE out to get you. pgpNOi8DsylyC.pgp Description: PGP signature
Re: build dependency alternatives sequencing
On Tue, Sep 11, 2001 at 09:07:20PM +0900, Junichi Uekawa wrote: > Filip Van Raemdonck <[EMAIL PROTECTED]> immo vero scripsit > > > > There are a couple of other oddball cases, like > > > > > > svgalibg1-dev | svgalib-dummyg1 > > > > > > where svgalib isn't relevant for all architectures. > > > > This is exactly one of the situations where the problem I described above > > would occur. While moving the dependencies around would probably help in > > nearly all cases [1], this would also really only be masking up the buildd > > problems. > > Note that this doesn't really mean, > "Build this source with svgalibg1-dev if this is available in > this architecture, and if not build with svgalib-dummyg1". > > > It can mean "Try to install svgalibg1-dev, but if it was not possible > to obtain it, try to install svgalib-dummyg1" No, it shouldn't mean that. > i.e. a broken mirror, or a broken package (with impossible > dependency?) can cause a "there should be SVGA support > but it doesn't in this particular build that the autobuilder has > built". > > Which obviously doesn't sound like the right meaning. Of course that's not the right meaning. The check for availability of a package shouldn't depend on the fact if the package itself is actually there, but if the package is in the Packages file. That way if the mirror is broken but it should've had svgalibg1-dev, it will bail out and not just take svgalib-dummyg1 instead. Note that if you go down the path of "this package should've been there, but it isn't installable right now so I'll just take the alternative", you could easily break packages which depend on the availability of the feature that was in a previous, correctly built version of your package. Regards, Filip -- "If I have trouble installing Linux, something is wrong. Very wrong." -- Linus Torvalds pgpK6PZwMbAJq.pgp Description: PGP signature
Re: build dependency alternatives sequencing
Hello, On Sun, Sep 09, 2001 at 11:16:50AM -0600, Bdale Garbee wrote: > > However, the sbuild tool that > most Debian autobuilders are using will only try the first alternative without > manual intervention. The tool probably can and should be augmented to handle > the full Build-Depends syntax, but while doing so would increase our build > percentages slightly, it would also mask what may be some underlying problems. While I agree with the masking problems comment, there's at least one situation where it really should be enhanced IMHO. That's the case where the dependency it picks (the first one, in the current situation) simply is not available. I don't think there's any reasonable excuse for bailing out in that situation. > There are a couple of other oddball cases, like > > svgalibg1-dev | svgalib-dummyg1 > > where svgalib isn't relevant for all architectures. This is exactly one of the situations where the problem I described above would occur. While moving the dependencies around would probably help in nearly all cases [1], this would also really only be masking up the buildd problems. Regards, Filip [1] only exception I can think of is someone who maintains a package that can use svgalib and who doesn't have access to i386 easily to build himself - and granted, that's not very likely a case to happen. -- War does not prove who is right, it proves who is left. pgpBkfPPLGuV2.pgp Description: PGP signature
Re: Chrony mailing list needs a home
On Fri, May 04, 2001 at 09:48:54PM -0500, John Hasler wrote: > Joey Hess writes: > > Well I guess you could use sourceforge. > > I assume that the author has his reasons for not wanting to use > Sourceforge. I believe sunsite.auc.dk does provide services to opensource projects as well, you may want to take a look at that. regards, Filip -- When you are having a bad day, and it seems like everybody is trying to tick you off, remember that it takes 42 muscles to produce a frown, but only 4 muscles to work the trigger of a good sniper rifle. -- John Galt pgpYzil3u8MIz.pgp Description: PGP signature
Re: looking for missing mail
Hello, The gap has been filled in... thanks to everyone. Regards, Filip -- War does not prove who is right, it proves who is left. pgpCgyOwW683v.pgp Description: PGP signature
looking for missing mail
Hi, Due to dissappearance of my mail provider I have missed the mail from this list from friday til sunday (until I resubscribed with another address). I'd be very thankfull if someone could send me a file with the missing mails. For mutt users I can even tell how to do this; in the index view type in T ~d 27/04/2001-29/04/2001 ;C somefile ;t then the `somefile' can be mailed over to me. Thanks, Filip -- "well, I use Linux instead of Windows. that's why I cant use that program." "but isnt it a PC?" "Yes." "then it isnt a mac. you can use it" "No, I cant. I use Linux." .. it goes on to "linux is an OS. not a program." "OS?" pgpR1KP5uATgw.pgp Description: PGP signature
Re: UPS setup problems (apcuspd and genpower)
On Fri, Mar 31, 2000 at 02:04:58PM +0200, Agustín Martín Domingo wrote: > "Thomas R. Shemanske" wrote: > > > > At *no* time are any messages printed to the terminal windows (to > > indicate power failure, warning logouts imminent, power resumed, etc). > > So I am rather confused. apcupsd collects valid data but > > /usr/sbin/powersc doesn't act on it. > > > > Do not know about apcupsd. I am using apcd to monitor my APC > Back-UPS650. Remember that if you try it you will need the other cable, > (the smart one, I think is the 0025) > > > I have also tried genpower (/sbin/genpowerd /dev/ttyS0 apc-pnp) (which > > is the correct type for the APC Cable 940-0095A. The /etc/upsstatus > > *always* says OK even if the plug is pulled. > > I suppose your model is a 650PnP since that behavior is different from > mine. From what I have read you need to switch the unit from smart to > simple mode to be able to use the simple monitoring mode genpower > handles, and genpower do not do that. I think the software delivered > with the unit is required for that. > > If your model is a 650SI, it is a smart only UPS, and genpower is not an > appropiate choice. That is the model I have and it took me a lot of time > until I discovered that. However, it detected power failure, but did not > switch off the UPS after a time. > That seems to be the common problem. Mine is a smart-ups 420 (european model), with a 0024c cable. I ran slink at the time I got it. I tried the few ups monitor tools available in slink, but these didn't shut down the system (they did detect power failure). I tried the newer versions (and greater choice) from potato, compiled from package source, but the same there. Since these weren't packages run on their regular system, I didn't file bugs. I got the powerchute tools from the apc site, and that works really fine. I probably should give the debian (not closed source) packages another try I guess, now that I am running potato anyway, but considering these messages, I hardly think it is worth the effort. Regards, Filip PS. my cable type shouldn't be a problem, at least apcupsd says it can work with it.
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
On Mon, Mar 20, 2000 at 02:38:12PM -0600, Steve Greenland wrote: > On 20-Mar-00, 01:46 (CST), Nicolás Lichtmaier <[EMAIL PROTECTED]> wrote: > > Using the Space and the Backspace keys for up and down movement is absurd, > > it's even stupid. Backspace is back-space. Those keybindings where thought > > for keyboards without arrows, and those keyboards no longer exists... > > While I agree with most of what you wrote, you're wrong on this one. > There's a *lot* of history of using the space bar to "do the next thing" > in Unix console programs (more/less, most news readers and existing mail > readers). And there's no reason *not* to use them -- what else would you > bind to the space key? You're right: the defaults should cater to the > new user, but there's no reason to deliberatly aggravate the experienced > user. > In fact, this has at least worked for a long time (and probably still works - but I don't do any helpdesk anymore so I don't have to use those programs) with a few internet related windows programs as well, as there are: netscape (not strictly windows, I know), for both navigator and messenger, interest exploder^H ^H^Hwhatever, outlook express. And who are we to correct Micro$oft? :-) Regards, Filip
Re: Danger Will Robinson! Danger!
On Mon, Mar 13, 2000 at 12:50:22PM +0200, Ari Makela wrote: > > The point might be that Slink can be updated to use 2.2 kernels and > other sofware which are not included. After all, quality software > compiles usually quite effortlessy with ./configure, make and make > install. > > All said, as an unix user I'm very programming and server orientated > and I rather buy malt whiskey than newest available hardware. Someone > with an Athlon or a very new video card might disagree with me. > And if they have this new hardware, does it mean they should not be able to run Debian then? If that's the case, better start rewriting some documentation... Filip
Re: nasty slink -> potato upgrade problem
On Sat, Mar 11, 2000 at 08:10:07PM -0500, Daniel Burrows wrote: > On Sat, Mar 11, 2000 at 08:32:07PM -0400, Nicolás Lichtmaier was heard to say: > > > > Trouble ahead? > > > Please run "apt-get install apt" before doing the dist-upgrade. Old apt > > > don't manage well the perl transition. This will be documented in the > > > Release Notes. > > > > Why don't we make the new perls conflict the old apt? > > I know I suggested something similar earlier, but would this really work? > You'd have to restart the apt frontend in order to get the needed effect, > even if it correctly upgraded itself. Not sure, but wouldn't it be possible somehow to fork & exec (and exit the parent program - not to forget)?
Re: Uninstallable Packages
Joseph Carter wrote: > On Tue, Oct 05, 1999 at 10:13:51PM +1000, Anthony Towns wrote: > > > > Depends: libgl1 ; which doesn't exist > > This exists in CVS. libGL.so.1 is what is used by the latest versions of > GLX and Mesa. I think the problem was coming up with a sane way to make > alternatives work for the purpose since libgl1 is almost certainly a > virtual package provided by Mesa, GLX, and probably commercial offerings > as well. > > Compound this with Mesa and GLX merging and you've got something close to > a nightmare. IMO there's yet another issue to consider (which brings another complication with it): there may be people who will want both mesa and glx, if they own a Riva or Matrox + Voodoo* add-on board. As long as Mesa keeps using the name libMesa* it can probably coexists with GLX (exept perhaps for include files?), but I've heard that they will change to libGL* as well. If they are planning on merging with GLX, the problem of multiple video cards (and drivers) will be theirs I guess.
Re: moving mutt to standard priority
Marco d'Itri wrote: > >vi: vim > >I am not arguring this should be the recommended editor, just the > recommended > >version of vi. I do not think that any package should be the recommended > I agree... Why does it have a lower priority in alternatives than nvi? Just so that the 'Standard' installation isn't bloated by 10 different versions of *every* editor out there?
Re: building kernel 2.0.x under potato
-BEGIN PGP SIGNED MESSAGE-
On Sat, 25 Sep 1999, Herbert Xu wrote:
> > >
> > > make bzImage HOSTCC=/usr/bin/egcs
> >
> > Indeed it does. I was too busy looking for a way to do it in the
> > environment... Can one use this with make-kpkg as well?
>
> Probably not, perhaps you can make a patch...
> --
Ok then.
I actually had to start learning perl for this but I guess it had to
happen once anyway, so...
You probably want to set the HOSTCC and CC variables in make-kpkg itself,
not in debian/rules (as I've done). That way they are passed on to every
target through ${MAKE} (and this is probably why setting on the
commandline works, while environment variables don't). I 've set them to
sane (?) defaults if CC and HOSTCC are not exported in the environment.
Also, dpkg --print-architecture (used in debian/rules) depends on gcc or
$CC, OTOH it produces an error if the word count of $CC > 1, so I passed
on $HOSTCC to it (which *should* be just the name of the compiler -maybe
you could add a check?).
Regards.
- -----------
Filip Van Raemdonck
[EMAIL PROTECTED]
member of the fibo-systeam
http://fibo.hogent.be | http://fibolite.hogent.be
- ---
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
iQCVAwUBN+/WbwErWvg4U8B1AQHQRAQArQhuiWHP9i5nfPW0pw7YZvexFjdJU/P0
+cBA5EjGQcadFbvCGx+xz1PFGDws72xCRLS/rUAt5wrma9ERUqtFzH/X36PR7p4q
HwjSHArD1rWoDxiuwExuLxJH9Jb3DIKcQJw+DU3EmTi+BCMezFkrAFF2G39mAnCq
uAWkn00MPmA=
=ssfc
-END PGP SIGNATURE-
--- make-kpkg Thu Aug 19 09:02:29 1999
+++ make-kpkg.bak Mon Sep 27 21:38:58 1999
@@ -663,6 +663,21 @@
elsif ($bzimage) {
$command .= " IMAGE_TYPE=bzImage ";
}
+
+ my $hostcc = $ENV{'HOSTCC'};
+ $hostcc .= " ";
+ if ($hostcc eq " ") { $hostcc = "gcc"; };
+
+ my $cc = $ENV{'CC'};
+ $cc .= " ";
+ if ($cc eq ' ') { $cc = $cross_compile; $cc .= "gcc "; };
+
+ $cc .= "-D__KERNEL__ -I";
+ chop($cc .= `pwd`);
+ $cc .= "/include";
+
+ $command .= " CC=\"$cc\" HOSTCC=\"$hostcc\"";
+
$command .= " $Targets";
exec $command;
}
--- rules Sat Sep 25 16:07:05 1999
+++ rules.bak Mon Sep 27 21:32:37 1999
@@ -67,7 +67,7 @@
KERNEL_CROSS:=$(CROSS_COMPILE)-
endif
else
- architecture:=$(shell dpkg --print-architecture)
+ architecture:=$(shell CC=$(HOSTCC) dpkg --print-architecture)
endif
KERNEL_ARCH:=$(architecture)
Re: building kernel 2.0.x under potato
> > make bzImage HOSTCC=/usr/bin/egcs Indeed it does. I was too busy looking for a way to do it in the environment... Can one use this with make-kpkg as well? --- Filip Van Raemdonck [EMAIL PROTECTED] member of the fibo-systeam http://fibo.hogent.be | http://fibolite.hogent.be ---
Re: building kernel 2.0.x under potato
Herbert Xu wrote: > > Of course not, if you want to change the compiler for stuff like dependencies, > you need to set HOSTCC. But for the problem at hand, which is compiling the > actual kernel with gcc272, CC works just fine. Doesn't work either: lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ export HOSTCC=/usr/bin/egcc lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ echo $HOSTCC $CC /usr/bin/egcc /usr/bin/egcc lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzimage make: *** No rule to make target `bzimage'. Stop. lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzImage gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep scripts/mkdep.c make: gcc: Command not found make: *** [scripts/mkdep] Error 127 Filip Van Raemdonck
Re: building kernel 2.0.x under potato
Herbert Xu wrote:
>
> You can easily override this on the command line or in the environment.
>
well...
Script started on Sat Sep 25 08:28:41 1999
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ ls -l /usr/bin/{,e}gcc
ls: /usr/bin/gcc: No such file or directory
-rwxr-xr-x 1 root root66924 Apr 7 12:35 /usr/bin/egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ alias
alias ls='ls --color -a'
alias mv='mv -i'
alias psa='ps a'
alias sl='ls'
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ gcc
bash: gcc: command not found
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ echo $CC
egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep
scripts/mkdep.c
make: gcc: Command not found
make: *** [scripts/mkdep] Error 127
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ export CC=/usr/bin/egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ echo $CC
/usr/bin/egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep
scripts/mkdep.c
make: gcc: Command not found
make: *** [scripts/mkdep] Error 127
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ alias gcc=egcc
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep
scripts/mkdep.c
make: gcc: Command not found
make: *** [scripts/mkdep] Error 127
lucretia:/usr/src/kernel-source-2.2.12-2.2.12$ exit
Script done on Sat Sep 25 08:29:51 1999
Doesn't seem to work for me then...
Regards.
Filip Van Raemdonck
Re: Packages available: xracer
> http://users.compagnet.be/mechanix/debian/ > Oops, that should be http://users.compaqnet.be/mechanix/debian/ Also, the upload is done now.
Packages available: xracer
Hi, following my ITP I have made some packages for xracer. They are available from http://users.compagnet.be/mechanix/debian/ (I'm uploading right now) I'm waiting for my application as a developer to be processed; in the meanwhile maybe someone could sponsor them? There are a few issues however (Stephen, this is where you get involved) * I've build this against both mesa as well as the glx driver. The latter however is not officially part of the distribution yet and as such the xracer-gl .deb has will have an unmet dependency. So I've put up those with it, though they don't belong to the package. * It probably won't work with a .deb built from the latest glx cvs tree, as this uses mesa3.1, which is currently incompatible with xracer. (I'm wondering - if glx makes it into potato, should it use mesa3.1, while the mesa package itself is 3.0, and 3.1 is beta?) * Also I don't know if it works with 3dfx boards - the xracer-mesagl .deb was built against generic mesa, but I hope that does the trick. * On a side note (from a previous xracer thread): shouldn't the glx and mesa packages be able to exist next to each other, instead of glx conflicting with/replacing mesa and symlinking around? After all, there may be people out there who own BOTH a riva or matrox card AND a voodoo one, and want to use them both. Thanks. ----------- Filip Van Raemdonck [EMAIL PROTECTED] member of the fibo-systeam http://fibo.hogent.be | http://fibolite.hogent.be ---
Re: building kernel 2.0.x under potato
(I originally meant this for the mailing list, but it seems I forgot to set the cc:, therefore I'm doing it now.) Herbert Xu wrote: > > On Wed, Sep 22, 1999 at 10:27:32PM +0200, Filip Van Raemdonck wrote: > > Kernel compilation ignores the CC variable. The compiler is hardcoded to > > 'gcc' in the toplevel Makefile. > > I'm surprised that nobody ever seemed to notice this before (as the use > > of different compilers for kernel compilation has come up quite some > > times on this list before). > > You better look again, it's certainly *not* hardcoded. In /usr/src/kernel-source-2.2.1/Makefile (the most recent slink source .deb available): on line 18 HOSTCC =gcc and on line 25 CC =$(CROSS_COMPILE)gcc -D__KERNEL__ -I$(HPATH) This goes for other (debian|upstream) versions as well. BTW, is any 2.0.38 package planned? Regards. ----------- Filip Van Raemdonck [EMAIL PROTECTED] member of the fibo-systeam http://fibo.hogent.be | http://fibolite.hogent.be ---
Re: Too many kernels in unstable
Peter S Galbraith wrote: > Perhaps the last two kernels of the stable tree(s) is good. > We have more kernels now because 2.0.X didn't die after 2.2.X was > released. Doesn't that argue that 2.2.X wasn't ready? This could also be caused by the fact that someone, though he might be tempted to upgrade his kernel (e.g. to 2.0.38), does not want to upgrade all the other required programs (modutils, pppd, etc. etc.) This may be true especially for server systems - I'd be very hesitating to upgrade anything which isn't broken as is. Question is off course if you'd be willing to reboot your server to upgrade it's kernel anyway (though the latest to 2.0 kernels are probably worth it- if you can afford to be down for a few minutes). Also, I think there should always be a 2.0 series kernel available, just because they're usually smaller - it will be of good use on a low end system (i[3|4]86, < 8 mb ram). ------- Filip Van Raemdonck [EMAIL PROTECTED] member of the fibo-systeam http://fibo.hogent.be | http://fibolite.hogent.be ---
Re: ITP: xracer
Joe Drew wrote: > > On Sun, Sep 12, 1999 at 05:21:42PM -0700, Joseph Carter wrote: > > > Yes, Mesa exists in main, which is good, but the Glide-compiled packages > > > don't, which means no hardware acceleration. > > > Is there any chance of getting glx in potato? > > > > So build against Mesa and GLX... Let me worry about Glide-enabled Mesa > > when I get the necessary license issues dealt with. > > I've actually built it against glide-enabled Mesa, but it *should* work > for any Mesa compatible with the version of mesag3 in Potato currently. > (Which includes, if my concept of Mesa, glx, etc is not totally off, the > glx modules for TNT2 and g200, neither of which I own.) Before I get > someone to upload this, though, I do want to test it on a couple boxes > with different types of Mesa. E-mail me if you'd like to test out xracer > and you've got a g200 or tnt[2] and the glx acceleration stuff installed. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] Hmm, well actually I already posted an ITP on september 1st. Only wnpp didn't pick it up. See http://www.debian.org/Lists-Archives/debian-devel-9909/msg3.html for it. Also it was me who submitted the --disable-GL patch upstream for the purpose of packaging it, so I'd really like to keep it. Only thing is I'm not officially a developer yet (waiting to get the application done, as many are... ;-) I already had preliminary packages available at the time of my ITP, but haven't put them somewhere since the last three upstream versions seem to be broken. --- Filip Van Raemdonck [EMAIL PROTECTED] member of the fibo-systeam http://fibo.hogent.be | http://fibolite.hogent.be ---
