Re: Quake 2 sources GPL'd
On Fri, Dec 21, 2001 at 11:57:21PM -0800, Thomas Bushnell, BSG wrote: Ben Collins [EMAIL PROTECTED] writes: That's not true. If it is possible to create game levels for it that are free, than it is considered free. It's not like you can't get anything but id's game data. I think it depends on whether there are any actual game levels around which are free. The distinction between contrib and main is not whether it is *possible* to create something free which the contrib software would be useful for; it's really whether there *is* such a thing. If the only practical use of the engine is to run non-free levels from id, then it belongs in contrib. If someone has levels (that at are all fun--that is, which are real games) which the engine works with, then it belongs (along with those levels) in main. So if I create a game with _no_ levels, but the tools to create them, then is it none-free? Just because the only ones available are non-free, doesn't preclude that it is possible to create your own. The engine has much more uses than just to play games (as the README in the source says, also for educational purposes). -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Sparc buildd a cross-compiler?
On Sat, Dec 22, 2001 at 05:19:27PM +0100, Mikael Hedin wrote: Hi, I noticed gsmlib has failed on sparc for a long time. The last log, http://buildd.debian.org/fetch.php?pkg=gsmlibver=1.7-1arch=sparcstamp=1006071760file=logas=raw, says in the end that g++-3.0 is a cross compiler: checking whether the C++ compiler (g++-3.0 -Wall -D_REENTRANT -O2 ) works... yes checking whether the C++ compiler (g++-3.0 -Wall -D_REENTRANT -O2 ) is a cross-compiler... yes checking whether we are using GNU C++... yes checking whether g++-3.0 accepts -g... yes configure: error: can not run test program while cross compiling make: *** [configure-stamp] Error 1 Your package better use gcc, not gcc-3.0. Using anything other than the default supported compiler gets you a bug report. Other than that, check the config.log output to see why it failed. -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Sparc buildd a cross-compiler?
On Sat, Dec 22, 2001 at 06:23:31PM +0100, Mikael Hedin wrote: Ben Collins writes: Your package better use gcc, not gcc-3.0. Using anything other than the default supported compiler gets you a bug report. But it doesn't build with g++-2.95. Then fix the build with that compiler. You wont get any support for a compiler that is not considered the default for an arch. Other than that, check the config.log output to see why it failed. Where do I find that one? Cant see it on the log page I referred to, nor on buildd.d.o. Start you own build on vore.debian.org and find it there. -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Quake 2 sources GPL'd
On Sat, Dec 22, 2001 at 06:07:02PM +, Jules Bean wrote: On Sat, Dec 22, 2001 at 11:06:11AM -0500, Ben Collins wrote: On Fri, Dec 21, 2001 at 11:57:21PM -0800, Thomas Bushnell, BSG wrote: Ben Collins [EMAIL PROTECTED] writes: That's not true. If it is possible to create game levels for it that are free, than it is considered free. It's not like you can't get anything but id's game data. I think it depends on whether there are any actual game levels around which are free. The distinction between contrib and main is not whether it is *possible* to create something free which the contrib software would be useful for; it's really whether there *is* such a thing. If the only practical use of the engine is to run non-free levels from id, then it belongs in contrib. If someone has levels (that at are all fun--that is, which are real games) which the engine works with, then it belongs (along with those levels) in main. So if I create a game with _no_ levels, but the tools to create them, then is it none-free? Just because the only ones available are non-free, doesn't preclude that it is possible to create your own. The engine has much more uses than just to play games (as the README in the source says, also for educational purposes). But the binary doesn't have educational purposes. The binary simply won't run, without some data files. I don't know if there's a freely downloadable shareware one like there was with quake1. Of course it does. You can teach basics of game development using a pre-existing engine. Teachers can use the binary to take their students from planning to creating worlds, to designing AI, etc. It has many benefits. We can even describe it as such in the description if it makes the zealots feel better. Certainly I don't see how we can, in main, distribute a binary that does nothing but give an error message and exit. I could see it as a source-only package, though. blimpo:~# gcc gcc: No input files You have to write or get code for gcc. Should we deliver a hello.c with gcc to meet those same requirements? You do realize that there are plenty of free levels out there for quake2 right? We don't have to distribute that same code just to put quake2 in main. -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Sparc buildd a cross-compiler?
On Sat, Dec 22, 2001 at 07:07:06PM +0100, Mikael Hedin wrote:
Ben Collins writes:
Start you own build on vore.debian.org and find it there.
Smart. You should be our leader ;-) Sorry for being rather stupid.
Anyway, g++-3.0 seems to be completely broken on sparc. int
main(){return(0);} gets a bus error. So I guess I'll just don't build
on sparc. Unless I get a really easy way to fix this (butit seems to
me to be something unsopported in g++-2.95):
Of course it is broken. It is _not_ supported on sparc, other than to
make it available to users. _I_ do not want anything built on sparc that
doesn't use the default compiler (except in cases such as libc6-sparc64
where we obviously have to use the 64-bit capable gcc-3.0 compiler).
It should be policy that programs are required to use the default
compiler on an arch. You create serious overhead on arch maintainence
when you ignore that.
In file included from ../gsmlib/gsm_me_ta.h:20,
from gsm_phonebook.cc:20:
../gsmlib/gsm_sms_store.h:109: parse error before `'
../gsmlib/gsm_sms_store.h:115: parse error before `int'
../gsmlib/gsm_sms_store.h:122: `gsmlib::operator *()' must have an argument
of class or enumerated type
../gsmlib/gsm_sms_store.h:122: `gsmlib::operator *()' must take either one or
two arguments
../gsmlib/gsm_sms_store.h:123: `gsmlib::operator -()' must be a nonstatic
member function
Don't discount sparc just because the code is broken. That's a bug in
itself. Fix the code, get it to compile. SPARC is one of the most tested
archs we have, so if it is broken there, you have some serious issues
anyway, and covering it by not building on sparc is not the answer.
I don't do C++, so you'll have to ask some experts.
Ben
--
.--===-=-==-=---==-=-.
/ Ben Collins--Debian GNU/Linux \
` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] '
`---=--===-=-=-=-===-==---=--=---'
Re: Sparc buildd a cross-compiler?
On Sat, Dec 22, 2001 at 06:54:10PM +, Philip Blundell wrote: In message [EMAIL PROTECTED], Ben Collins writes: Don't discount sparc just because the code is broken. That's a bug in itself. Fix the code, get it to compile. SPARC is one of the most tested archs we have, so if it is broken there, you have some serious issues anyway, and covering it by not building on sparc is not the answer. I don't do C++, so you'll have to ask some experts. G++ 2.95 is pretty broken in its own right. Just because it won't compile something doesn't necessarily mean that the source is at fault. I wouldn't regard it as unreasonable for C++ programs to require 3.0 these days. I don't think it is unreasonable in Debian to require that programs work with the default toolset available for the arch. Most of the archs do not use gcc-3.0 as the default. Keeping one toolchain in shape to compile the entire dist is enough work without having to require archs to maintain two stable toolchains. That said, there are two issues: 1) Currently on archs that use gcc-2.95 as the default, using gcc-3.0 and especially g++-3.0 is not supported by libc6. The backward compatibility is not what it should be, and wont be until glibc 2.2.5. So using it now only means you potentially leave your app open to breakage later on. 2) There are HOWTO's on creating generic C++ for gcc-2.95 and gcc-3.0, so it compiles on both. They are in the porting page, IIRC. The broken C++ has been around a long time, and works in as much as it has been tested for a _long_ time. -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Quake 2 sources GPL'd
On Sat, Dec 22, 2001 at 07:35:59PM +, Jules Bean wrote: On Sat, Dec 22, 2001 at 01:42:41PM -0500, Ben Collins wrote: gcc to meet those same requirements? You do realize that there are plenty of free levels out there for quake2 right? We don't have to distribute that same code just to put quake2 in main. And do you realise that none of those levels is *any* use *at* *all*, without the commercial game data? The code simply won't load levels, as it stands, unless it has loaded the game data. Even if that protection feature was disabled (trivial, certainly) it still wouldn't work: all such free levels require some stuff from the commercial data, the weapons, the models, the textures, etc. But it is possible, just a matter of time. And again, the educational purpose still stands. The binary has use without the non-free data. -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Quake 2 sources GPL'd
On Sat, Dec 22, 2001 at 12:40:06PM -0800, Thomas Bushnell, BSG wrote: Ben Collins [EMAIL PROTECTED] writes: So if I create a game with _no_ levels, but the tools to create them, then is it none-free? Just because the only ones available are non-free, doesn't preclude that it is possible to create your own. The engine has much more uses than just to play games (as the README in the source says, also for educational purposes). Yeah, but that's a smokescreen I think. It seems like an excellent candidate for contrib. The argument you give could be applied to *any* package in contrib: they all have *some* potential educational value, they all *might* be useful if somebody went and wrote free analags to the nonfree things they depend on, etc. I think that's rediculous. Education is not a smokescreen, and you can't argue that there will never be free data available for quake2 (or know for sure that there isn't already). The quake2 engine is a gaming engine. Lots of libraries in our current source are the same sort of things, and at one time did not have a game based on them. Did they go into contrib? No. If they had a game based on them that was non-free, would we put them in contrib? Probably not, because they are libraries as opposed to binaries. Not so with the quake2 engine. However, just because it is a binary executable engine does not make it any different than a development library in terms of game development. Advertise the thing as a gaming engine, not as a game. Call the package quake2-engine, and then once we get some, we will have cool-game Depend: quake2-engine. The fact is, that the quake2-engine does not depend on anything to perform what it was made for, and that is to be a gaming engine. The data is the game, and requires the engine. Makes sense to me. -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Quake 2 sources GPL'd
On Sun, Dec 23, 2001 at 10:48:09AM +1100, Hamish Moffatt wrote: On Sat, Dec 22, 2001 at 01:42:41PM -0500, Ben Collins wrote: blimpo:~# gcc gcc: No input files You have to write or get code for gcc. Should we deliver a hello.c with gcc to meet those same requirements? You do realize that there are You might be surprised to learn that we actually ship quite a bit of C source code in Debian suitable for use with gcc. The point is that quake2-engine is a building block. If I create a library for developing programs, does it go into contrib until someone writes a program that uses it? Certainly not. It goes into main so that it can be used. Ben -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Quake 2 sources GPL'd
On Fri, Dec 21, 2001 at 07:57:43PM -0800, Thomas Bushnell, BSG wrote: Juhapekka Tolvanen [EMAIL PROTECTED] writes: I just heard it through the www.linuxgames.com ftp://ftp.idsoftware.com/idstuff/source/quake2.zip Can we include that in Woody before too deep freeze? P.S: I don't subscribe to this list. I am smart enough to read mailing-list archives via WWW, but you can Cc: me if you want. Does this include any game levels? If it doesn't include any levels that a person can play, then it only belongs in contrib. That's not true. If it is possible to create game levels for it that are free, than it is considered free. It's not like you can't get anything but id's game data. Ben -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: How many people need locales?
On Wed, Sep 05, 2001 at 12:19:01PM +0900, Junichi Uekawa wrote: Ben Collins [EMAIL PROTECTED] immo vero scripsit This isn't a matter of not using it, it's a matter of a sane base install. Perhaps base-config could ask if the user wants locales. Know what? That question is being asked in english _anyway_. Having a few well-known questions asked in English is fine, having a sequence of questions in English is scaring a lot of people away, at least in Japan. You might be ignorant about this, but English language is not understood by everybody. Don't make assertions. I never said everyone understands it. The point is, as it stands now, you have to go through the entire install in english...not just a few questions..._all_ of them. That needs to be fixed first. -- .--===-=-==-=---==-=-. / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: How many people need locales?
On Mon, Sep 03, 2001 at 08:24:43AM +0200, Eduard Bloch wrote: #include hallo.h Santiago Vila wrote on Mon Sep 03, 2001 um 02:21:04AM: I think we can consider the volume or the number of subscribers of the debian-user mailing list, and compare it with the volume or the number of subscribers of all other language-specific debian-user-foo lists combined. Is there anybody who can do this count? Can you think of another way to estimate the proportion of users using locales? I really wish to make the locales beeint installed by default, either allways, or with some user interacton (yes/no, which locale etc.). IMO this should be included as one of the first questions in baseconfig. With an installed size of over 8megs, I don't think that is such a good idea. -- .--===-=-==-=---==-=-. / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: How many people need locales?
On Mon, Sep 03, 2001 at 10:22:12AM +0300, Ari Makela wrote: Ben Collins writes: With an installed size of over 8megs, I don't think that is such a good idea. During the configuration phase we get a rough time zone information. For example, I have $ cat /etc/timezone Europe/Helsinki From this information it's possible to genereate the needed locales, in this spesific case the fi_FI locales. So? The package, before anything is generated, still takes up 8.8megs of disk space. After generating, the installed size grows. -- .--===-=-==-=---==-=-. / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: How many people need locales?
On Mon, Sep 03, 2001 at 09:25:04AM +0200, Michael Bramer wrote: On Mon, Sep 03, 2001 at 03:16:25AM -0400, Ben Collins wrote: On Mon, Sep 03, 2001 at 08:24:43AM +0200, Eduard Bloch wrote: #include hallo.h Santiago Vila wrote on Mon Sep 03, 2001 um 02:21:04AM: I think we can consider the volume or the number of subscribers of the debian-user mailing list, and compare it with the volume or the number of subscribers of all other language-specific debian-user-foo lists combined. Is there anybody who can do this count? Can you think of another way to estimate the proportion of users using locales? I really wish to make the locales beeint installed by default, either allways, or with some user interacton (yes/no, which locale etc.). IMO this should be included as one of the first questions in baseconfig. With an installed size of over 8megs, I don't think that is such a good idea. maybe you don't use it, but a lot of user don't speak english or can't understand it. We must support locales and if a user can't speak english he pay this price. This isn't a matter of not using it, it's a matter of a sane base install. Perhaps base-config could ask if the user wants locales. Know what? That question is being asked in english _anyway_. Installing locales by default doesn't even come close to solving this problem, so there is no point in including it by default. Ben -- .--===-=-==-=---==-=-. / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: [FLAME WARNING] Linux Standards Base and Debian
On Wed, May 09, 2001 at 11:26:58AM +1000, Glenn McGrath wrote: Henrique de Moraes Holschuh wrote: Since the LSB is mainly useful for binary-only distributors, we need not get annoyed over their choice of rpm. After all, it makes more sense, since most distributors already have staff that knows how to build rpms anyway. So the LSB is just about convienience then is it (do whats easiest) ? If LSB compromise on quality then they will only ever get a subset of the community supporting it, why not try for something better than both RPM or DEB, its the only way people will willingly change. If nothing can be made that is better than both RPM and DEB then both package systems obviously have a purpose. I agree. The LSB should contrast/compare features of both and come up with a superset of both (possibly favoring ones implementation over the other). Most importantly, the metadata format needs to be standardized. That is the key component. If that is standard, then the binary format means very little (since a simple converter can be created just like alien). After that, then all package managers atleast can aim for something, instead of shooting in the dark like we do now. The LSB needs to stay away from trying to standardize a binary format (who cares if it's tar.gz, ar or cpio). They will only piss people off. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: build depends on kernel-headers
On Sat, May 05, 2001 at 06:23:39PM +1000, Anthony Towns wrote: In short, how do you do them? AFAICT, I could conceivably add either Build-Depends: kernel-headers or Build-Depends: kernel-headers-2.2.19 or Build-Depends: kernel-headers-2.2 or Build-Depends: kernel-headers-2.4 You'll notice that recent kernel-headers packages provide the major.minor if the kernel version. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: build depends on kernel-headers
On Sat, May 05, 2001 at 09:44:07PM +1000, Herbert Xu wrote: On Sat, May 05, 2001 at 10:27:53AM +0100, Philip Blundell wrote: Actually, I'm not even completely convinced that having them in the kernel-image package name is particularly beneficial. But, even if we leave that the way it is, I don't think it's impossible to arrange for kernel-headers to be named differently. Kernel-image packages need to have version numbers encoded in them so that upgrades can happen smoothly. Kernel-headers need the version numbers as you may have multiple kernel-images packages in the archive. The thing is, kernel-headers should not be used at all unless you're compile glibc, or modules. Anything else will break. False. That is the very thing I want to alleviate (people using kernel headers from the libc6-dev package). People should not be using them, but if they do, they should use a kernel-headers package, and not rely on the headers in libc6-dev which are different on all archs, and change almost every new glibc build. You are never guaranteed to get the prefered kernel headers for your program (be it a scsi level thing like cdrecord, or mount tools like util-linux). The point here is to make packages start moving to Build-Dep'ing on kernel-headers-* packages. The question is, how to allow them to do that easily. IMO, we can use alternatives. And it should be fairly easy update-alternatives --install /usr/src/kernel-headers-2.2 kernel-headers-2.2 \ /usr/src/kernel-headers-2.2.rev rev Where rev would be something like 19 (as in 2.2.19). This way each newer version would be prefered over the former. The only problem I see are the -preX releases. Someone would have to suggest how to handle that case since the priority field wont accept letters. Also, I think that packages should Build-Depends on kernel-headers-X.X. IMO, There is no reason to build-dep on anything more specific, and also no reason to build-dep on just kernel-headers (IOW, maintainers should test which kernel headers can be used). This way they can always just do: CFLAGS += -I/usr/src/kernel-headers-2.2/include And not have to worry about all the revisions, or detecting anything special. Xu, can this alternative system be added to the kernel-headers package scripts? Does anyone see a problem with this solution (that isn't already a problem with the current usage of kernel headers in libc6-dev that is)? Anyone got a solution for the -preX case, which would probably make this method rock solid? Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: build depends on kernel-headers
On Sun, May 06, 2001 at 09:46:32AM +1000, Herbert Xu wrote: The point here is to make packages start moving to Build-Dep'ing on kernel-headers-* packages. The question is, how to allow them to do that easily. Personally I think you're trying to solve a problem that will become a non-issue as people realise this and stop using kernel headers. That's wishful thinking, but I agree. I'm not sure it is possible though. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Netscape v.s. C source code
On Fri, May 04, 2001 at 02:20:15PM -0400, Steve M. Robbins wrote: WTF? It's *text*, after all. What magic spell is needed to convince navigator to put it into the main window like a foo.txt file? Setup apache to treat .h and .c as text/plain. That will tell netscape and any other web browser to just view the contents as plain text. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Q about g++-3 and template instantiation
On Thu, May 03, 2001 at 11:36:05AM -0300, Dan E. Kelley wrote: Ilya, thanks VERY MUCH. This solved my problem in a flash. My application (38 thousand lines, compared to the 6 lines of my test-file) now compiles and links properly in g++-3, and, with a preprocessor switch, in g++-2 as well. In case other folks are interested, below is how I now do it (sorry that I test for __GNUC__; this code is meant to work for many other compilers as well) ... #if defined(__GNUC__) #if __GNUC__ == 3 void std::reverse(std::vectordouble::iterator, std::vectordouble::iterator); #else template void std::reverse(std::vectordouble::iterator, std::vectordouble::iterator); #endif #endif You could probably reduce this to: #if defined __GNUC__ __GNUC__ 3 template #endif void std::reverse(std::vectordouble::iterator, std::vectordouble::iterator); Just FYI :) -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Debian job in Boston US [nowhere better to post?]
On Thu, May 03, 2001 at 03:36:07AM -0400, Grant Taylor wrote: I asked a couple of developers, and there seems to be nowhere better to post until debian-jobs is up; sorry if this is annoying. If you are willing to take a telecommuter, I am interested. I live in the southeastern part of Virginia (Gloucester to be exact). My resume is referenced below (I am a Debian developer). http://marcus.seva.net/~bmc/resume/ Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: libdb3.so and libdb-3.so
On Mon, Apr 30, 2001 at 12:27:56PM +0900, GOTO Masanori wrote: Hi, I wonder why libdb3 package includes /usr/lib/libdb3.so.3.0.2 , /usr/lib/libdb-3.so , however libdb3-dev package includes /usr/lib/libdb3.so . That .so is not a link name. It is only there so that things compiled against the upstream soname will work. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: libdb3.so and libdb-3.so
On Mon, Apr 30, 2001 at 11:51:55PM +0900, GOTO Masanori wrote: I cannot find out why `libdb-3' is used and spreaded over the gnome packages. Naming soname is sensitive issue, IMHO. As I said the *upstream* soname is libdb-3.so, and Debian's soname is libdb3.so.3. The former is not very conformant to soname schemes, the latter is. Gnome can use whatever it wants to link with it, but the soname is still libdb3.so.3. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: libdb3.so and libdb-3.so
On Tue, May 01, 2001 at 12:27:38AM +0900, GOTO Masanori wrote: At Mon, 30 Apr 2001 10:59:24 -0400, Ben Collins wrote: I cannot find out why `libdb-3' is used and spreaded over the gnome packages. Naming soname is sensitive issue, IMHO. As I said the *upstream* soname is libdb-3.so, and Debian's soname is libdb3.so.3. The former is not very conformant to soname schemes, the latter is. Gnome can use whatever it wants to link with it, but the soname is still libdb3.so.3. Thanks for your explanation, Ben. I understand. In addition, I insist that all gnome developer should use `libdb3' instead of `libdb-3'. Yes, there is no problem in binary's soname compatibility, but db-3 is not appropriate name, the reason is said above by Ben. No, it is perfectly fine for them to use -ldb-3, since the soname will still be libdb3.so.3. The link does not affect the soname, since it is hardcoded in the library no matter what they use to link to it. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: porting questions
On Fri, Apr 27, 2001 at 08:58:12PM -0700, Joshua Haberman wrote: Problem #2: even on vore in the sid chroot, my package Build-depends on many packages that are not installed, and I of course can't install them as a normal user. FYI, vore runs sid/unstable on it's main root. So you can simply build there (lots of packages installed, let me know if any are missing). Also, I am almost done finishing a build-dep request email, where you can send a signed email to schedule time in a chroot with your own build-deps setup. We'll see how that goes. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: 2.4.x Kernel, ECN And Problem Websites
On Wed, Apr 25, 2001 at 10:16:30PM +1000, Daniel Stone wrote: On Wed, Apr 25, 2001 at 01:52:09PM +0200, Wichert Akkerman wrote: Previously Daniel Stone wrote: Why enable ECN at all, if all it effectively does is break stuff? AFAIK, there's no systems out in the wild that actually use ECN to make a difference. All that's happening is that peoples' systems are being broken. Which is sub-optimal. With that attitude we would still be using 8bit systems with blackwhite monitors. It may be a minor catch-22, but ECN is currently so broken, that only power users should be using it, as the rest will just continue flooding the netfilter list with Netfilter breaks all my websites!. [OK, ECN isn't broken, the routers are, I know, but same effect. ECN breaks stuff]. So, if you're smart enough to know that you want ECN, and smart enough to understand the consequences, you should be compiling your own kernel. Uh, no, ECN is not broken at all. What is broken are all of these routers that depend on reserved bits in the TCP/IP packets. ECN itself does not break things, it merely shows other things that are broken. If we left everything to you have to be smart enough, then let's just leave out the entire linux kernel, most of the software in Debian, and go for a minimum cygnus install. Let's just ditch all non-i386 architectures. Hell, let's get rid of everything that might potentially break your system, unless you are smart enough to use it. You know, things like X that can fry a monitor, or mkfs that might trash your harddrive. No way should we be pushing ECN to the masses. It should stay in the domain of people like DaveM, until routers get fixed. If we did that, then maybe 4 people would be using it (there's not many people in the same class as davem). This needs to be pushed to the masses. If we watited for all of these vendors to fix their equipment, and all of these corporations to apply those fixes, before spreading ECN, then DaveM might be the only person who ever uses it, and nothing will get fixed. That fact that things get broken, and people complain, is one reason that things get fixed. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: 2.4.x Kernel, ECN And Problem Websites
On Wed, Apr 25, 2001 at 01:02:47AM -0500, Adam Heath wrote: On Wed, 25 Apr 2001, Ben Collins wrote: If we left everything to you have to be smart enough, then let's just leave out the entire linux kernel, most of the software in Debian, and go for a minimum cygnus install. Let's just ditch all non-i386 architectures. Hell, let's get rid of everything that might potentially break your system, unless you are smart enough to use it. You know, things like X that can fry a monitor, or mkfs that might trash your harddrive. mkfs doesn't fry harddrives, it fries data on harddrives. However, using wrong video settings can actually destroy certain monitors. Thanks Adam (the nitpicker) Heath :) FYI, there are things you can do in the kernel config that can fry a harddrive, as explained in some threads on the linux-kernel list (SCSI related commands). -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Architecture question
On Sun, Apr 22, 2001 at 08:31:55PM +0200, Wichert Akkerman wrote: Previously Taral wrote: I'm packaging acl2, which can take several hours to compile on a PPro 200. Would it be reasonable to exclude certain architectures as too slow? (acl2 is a theorem prover.) No. Argeed. Lots of packages take several hours to build, even on fairly recent systems. Let the porter decide what to exclude in this case. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Suggestion to change how bugs get closed
On Mon, Apr 23, 2001 at 03:11:41AM +0200, Adrian Bunk wrote: Hi, I think we have a new problem with the closing of bugs since there is testing: Currently, bugs get closed when a package goes into unstable. When we'll freeze testing we'll have to check whether the packages that closed the bugs made it into testing or not. This isn't very good. As a solution I suggest the following: When a package was only uploaded to stable the bugs aren't closed but tagged woody instead. When the package goes into testing the bugs get closed. Your case is wrong. What if the bug didn't exist in woody, and only in stable? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: 'export RESOLV_HOST_CONF= any file you want' local vulnerability
On Tue, Jan 09, 2001 at 01:41:41PM +0100, Christoph Baumann wrote: On Tue, Jan 09, 2001 at 11:08:56AM +, Julian Gilbey wrote: Most weird. I get this behaviour when running through a setuid root strace, but I don't get the error messages (and hence the content of /etc/shadow) when I don't use strace. I'm still running potato. I have some more oddities to add. When I set RESOLV_HOST_CONF=/etc/shadow and run fping debian.org I don't get /etc/shadow displayed. Even running it with a +s strace doesn't work. But when I use sudo fping ... I get /etc/shadow displayed (which shouldn't be such a big hole in that case). I too tried it with potato. Potato is not vulnerable. This is a woody/sid only bug (i.e. glibc 2.1.9x and greater, such as the 2.2 in woody/sid). The bug is not that it prints this info, but that it uses the env variable even when suid/sgid. This wasn't supposed to happen, and the actual fix was a missing comma in the list of secure env vars that were supposed to be cleared when a program starts up suid/sgid (including RESOLV_HOST_CONF). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Release-critical Bugreport for January 5, 2001
On Fri, Jan 05, 2001 at 05:02:40PM +, Colin Watson wrote: Branden Robinson [EMAIL PROTECTED] wrote: On Fri, Jan 05, 2001 at 06:00:08AM -0600, BugScan reporter wrote: Bug stamp-out list for Jan 5 05:13 (CST) Total number of release-critical bugs: 482 I thought aj introduced the serious severity so that important bugs wouldn't be considered release-critical anymore, but it looks like bugscan doesn't know that important bugs aren't RC. I notice that some porters are still filing can't build from source bugs as 'important'; I realize the developers-reference package hasn't been updated yet, although the version in CVS has. A lot of such 'important' bugs are going to need to be upgraded to 'serious'. Well, packages that cannot be built wont be put into testing, basically because the version isn't compiled on all archs. So it wont be released anyway. IMO, build failures on non-release archs (those not in testing) should be considered important, while build failures on release archs (those in testing) should be considered serious. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: What happened to libnss1-compat?
On Thu, Jan 04, 2001 at 11:03:15AM +0100, Michael Meskes wrote: I have a commercial binary that needs this library. Yes, I can find it in potato, but not in unstable. Is there a new package providing libnss1-compat? libnss1-compat would not compile cleanly with the latest glibc. So if you need this, either keep it around from potato, or convince someone to package it seperately. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: find/locate both segfault after today's update [unstable]
On Thu, Jan 04, 2001 at 09:35:28PM -0600, Gordon Sadler wrote: I update most every day to current unstable. Something I just noticed today no matter what options or how I call them, both find and locate are producing: locate libc6 Segmentation fault find / -name etc Segmentation fault The only thing even close to relevant AFAICT today is ... libc6 Package: libc6 Version: 2.2-9 Now I also have libc6-i686, but til now have not had problems running it. Have you tried removing libc6-i686 just to make sure it isn't causing this? Also, what kernel ar you running? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
On Wed, Jan 03, 2001 at 05:12:44AM +0200, Eray Ozkural (exa) wrote: Anyway, here is the _explanation_ for the bug report. There's a preprocessor symbol in posix threads. It's called PTHREAD_ERRORCHECK_INITIALIZER_NP. I claim that it has not been defined although it is said to be defined in the docs. Which docs? Obviously, the info manual since there is only *one* freakin' manual. Where in that manual? Any luser with a info browser that can search would find it: Sorry, but there are many docs with which to talk about system headers/libs. Let's start with the info docs, then go to the manpages (yes, pthread manpages are in the glibc-doc package too), then not to mention general POSIX threading documentation, SUSv2 and other things like the XPG, XOPEN, UNIX 98, and other specs. When you start saying docs, you need to be more specific. From File: libc.info, Node: Mutexes, Next: Condition Variables, Prev: Cleanup Handlers, Up: POSIX Threads Variables of type `pthread_mutex_t' can also be initialized statically, using the constants `PTHREAD_MUTEX_INITIALIZER' (for timed mutexes), `PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP' (for recursive mutexes), `PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP' (for fast mutexes(, and `PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP' (for error checking mutexes). WOW. Go fucking figure. YOUR BUG REPORT says PTHREAD_ERRORCHECK_INITIALIZER_NP while this info page shows PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP See the difference? See why I couldn't find it?! See why I thought you were just having a bad day, and misreading things!?! The latter IS defined in the headers. WHAT TO DO: - Get a clue - Read better -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
I've just reported what I had thought, some many many months ago, to be a problem. Of course, the maintainer has not done anything about this report for 7 months, and then he closes it like that. Not good. Oh, and just to chime in on this little bit, I did not start maintaining glibc until Aug 31, 2000 (my first changelog entry). So no, I have not been sitting on this for 7 months. Get your facts straight. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Huh, gcc 2.95.3?
On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote: Happy new year to everyone! gcc 2.95.3 appeared in Sid, but it hasn't been announced by the GCC steering committee yet. Is this some kind of early access version? It's based on the CVS branch, which is noted in the changelog if you had bothered to read it. There's no such thing as early access, this is open source you know :) Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Huh, gcc 2.95.3?
On Mon, Jan 01, 2001 at 04:47:55PM +0100, Harald Dunkel wrote: Ben Collins wrote: On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote: Happy new year to everyone! gcc 2.95.3 appeared in Sid, but it hasn't been announced by the GCC steering committee yet. Is this some kind of early access version? It's based on the CVS branch, which is noted in the changelog if you had bothered to read it. To read the changelog I have to download and install it. But I don't like to install unknown compilers on my development machines. Especially since there is no undo operation for dpkg -i. To read the changelog, you do not have to install it. There's no such thing as early access, this is open source you know :) My (personal) definition for 'Early Access Software' is that somebody has grabbed a more or less stable version with the knowledge of the maintainers before the official release date. I cannot see why this definition shouldn't be applicable to GPL software. To me Early Access is a commercial buzz word that means some special people get access before everyone else. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: finishing up the /usr/share/doc transition
On Mon, Jan 01, 2001 at 12:20:32PM -0800, Joey Hess wrote: So it will need to: 1. Remove all symlinks in /usr/doc that correspond to symlinks or directories with the same names in /usr/share/doc 2. If there are any directories with the same names in /usr/doc and /usr/share/doc, merge them. (And probably whine about it, since that's a bug.) 3. Move any remaining directories and symlinks that are in /usr/doc to /usr/share/doc 4. Move any files in /usr/doc to /usr/share/doc (shouldn't be necessary, but just in case). 5. Remove /usr/doc 6. Link /usr/doc to /usr/share/doc Exactly, except '6' should be Link /usr/doc to share/doc, so chrooted systems can be more easily maintained. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: finishing up the /usr/share/doc transition
On Mon, Jan 01, 2001 at 02:25:24PM -0800, Joey Hess wrote: Goswin Brederlow wrote: Maybe I have architecure dependent documentation that should not be in share. Er. Well policy does not allow for this at all. If you do actually have such a thing (it seems unlikely), perhaps you should bring it up on the policy list and ask for a location to put it. How can anything that's a document only work on a particular arch? If you are talking about pre-compiled examples, well uh, don't precompile them. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: finishing up the /usr/share/doc transition
On Mon, Jan 01, 2001 at 11:58:07PM +0100, Goswin Brederlow wrote: So bugs won't be noticed. Maybe a simple grep in the Contents files would be enough to find all such packages. Does lintian check for /usr/[share/]doc? Yes, lintian does complain about /usr/doc and /usr/man -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: finishing up the /usr/share/doc transition
On Mon, Jan 01, 2001 at 03:05:14PM -0800, Joey Hess wrote: # Move any remaining directories and symlinks from OLDDOC to NEWDOC. for item in `find $OLDDOC -maxdepth 1 \( -type d -or -type l \) -printf '%P\n'`; do if [ $item -a -e $NEWDOC/$item ]; then echo $item exists in $NEWDOC too; should never happen 2 exit 1 fi mv -f $OLDDOC/$item $NEWDOC done Maybe this should be something like: if cp -a $OLDDOC/$item $NEWDOC; then rm -rf $OLDDOC/$item else rm -rf $NEWDOC/$item exit 1 fi That should handle filesystem full errors a bit better. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Huh, gcc 2.95.3?
On Tue, Jan 02, 2001 at 11:42:22AM +1100, Daniel Stone wrote: On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote: Happy new year to everyone! gcc 2.95.3 appeared in Sid, but it hasn't been announced by the GCC steering committee yet. Is this some kind of early access version? It's based on the CVS branch, which is noted in the changelog if you had bothered to read it. There's no such thing as early access, this is open source you know :) Ack!(tm). Not shades of rh7, I hope? I know that people using sid (like myself) are willingly sado-masochists, but a CVS GCC? Uh, GCC 2.95.3 CVS NOT 2.96 OR 2.97! Please be careful what you say. We are talking about a stable release here, not a dripping wet development snapshot. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Huh, gcc 2.95.3?
On Tue, Jan 02, 2001 at 12:31:52PM +1100, Daniel Stone wrote: On Tue, Jan 02, 2001 at 11:42:22AM +1100, Daniel Stone wrote: On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote: Happy new year to everyone! gcc 2.95.3 appeared in Sid, but it hasn't been announced by the GCC steering committee yet. Is this some kind of early access version? It's based on the CVS branch, which is noted in the changelog if you had bothered to read it. There's no such thing as early access, this is open source you know :) Ack!(tm). Not shades of rh7, I hope? I know that people using sid (like myself) are willingly sado-masochists, but a CVS GCC? Uh, GCC 2.95.3 CVS NOT 2.96 OR 2.97! Please be careful what you say. We are talking about a stable release here, not a dripping wet development snapshot. So what was the CVS branch reference? Because the upcoming 2.95.3 release is currently only available via a CVS branch maybe? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: holding back the tide
On Fri, Dec 29, 2000 at 11:31:41PM -0500, Branden Robinson wrote: severity 80842 serious severity 80843 serious thanks gcc won't build on arm, so XFree86 won't build on arm, so XFree86 can't go into testing, so LOTS of things can't go into testing. Adam Heath, please consider helping the gcc maintainer do some DBS surgery, because it is DBS that is keeping gcc from building. Uh, gcc does not use DBS. And the gcc maintainer is hard at work with the grande scheme of things, manipulating gcc2.95 and gcc2.97 for concurrent installation. Give Matthias time, or email him directly with your concerns. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: PAM problem with Courier
On Sat, Dec 30, 2000 at 01:15:54PM +0100, Stefan Hornburg wrote: auth required /lib/security/pam_warn.so auth requisite /lib/security/pam_mysql.so host=localhost database=snailrace user=racke password=nevairbe table=users usercol=id passwordcol=crypt crypt=y This is wrong. First of all, we don't use pam_warn on Debian (if you're intent is to make this work on Debian). Secondly, never use the full path to the module. Lastly, the auth module should be requisite. So try this (note, I know nothing about the pam_mysql module, but I do know PAM): authrequiredpam_mysql.so host=localhost database=snailrace user=racke password=nevairbe table=users usercol=id passwordcol=crypt crypt=y Note, this is very bad indeed. For one, you need to make this file's permissions something like 600, so normal users cannot read it. Depending on what user the pop3 service is run under, you might also need to change the owner of the file so that the daemon can have access to it. Lastly, are you sure that pop3 is the service name used by the program? Note, this has nothing to do with the service name listed for the port it is using, so check the source for the call to pam_start(), and check the first argument passed to it. That is the service name, and the name of the file expected in /etc/pam.d/ -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: holding back the tide
On Sun, Dec 31, 2000 at 01:05:23AM +0100, Matthias Klose wrote: Adam Heath writes: Bdale hates dbs, doesn't know what it is, so I don't trust his assement of the issue. I never said glibc nor gcc use dbs. They use a system like dbs, one I feel is incorrect(each .dpatch system includes code to apply the patch, which, I feel, is code duplication). There was no alternative system, when I designed the dpatch system. The code duplication is needed, because a .dpatch is self-contained. For most cases it calls patch with the .dpatch file as the patch file. Other commands are run after applying the patch. Currently that's only the case for configure. It's tedious to regenerate the patches if you have two independent patches for a configure.in. But yes, you could extend this format to use Pre-Patch and Post-Patch commands. On top of that, a lot of patches for gcc are obtained from the gcc-patches list. Some of those are in -p0 format, some are in -p1. So it is always useful to not have to modify these. On top of that, each .dpatch includes a description of what the patch does, so that the gcc build system can parse it out and put all of the Debian changes into one file, specific to that revision/arch. Adam, don't put down a system that precedes dbs. It is tried and true to it's purpose and solves things that DBS cannot. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: List of packages that could be dropped
On Tue, Dec 26, 2000 at 07:06:30PM -0700, John Galt wrote: If it's so important, why is it orphaned? I'm thinking that if the SPARC folx can't be bothered to maintain their bootloader, perhaps the port's utilization of resources needs to be called into question... What's the point in Debian proper showing more support for SPARC than the SPARC community shows for Debian? What the fuck are you talking about!?! For one the damn thing isn't changed that often. Upstream isn't making frequent updates, and the fucking thing works. You need to find your red herrings some place else. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: List of packages that could be dropped
On Wed, Dec 27, 2000 at 04:26:57PM -0700, John Galt wrote: 195 days is a lot of time to have an important package orphaned. At 6 or so months of orphaned-ness, if a maintainer is not found, one should and IMHO must look at the very real at that point possibility of going on without it. If this necessitates further changes as in removal of an entire architecture, then I'd say that it's time to shit or get off the pot, to use the vernacular. It can't be too damned important if nobody steps up and adopts it for ~6.5 months... ATM, though, it's not a real issue, but I think that in addition to the bug horizons, there needs to be a wnpp check on a freeze: orphaned packages die during a freeze unless adoped post haste (I can't remember if this means that silo would've died during the potato freeze...). silo (0.9.9-1) unstable; urgency=low * New upstream * Took over silo's packaging -- Erick Kinnee [EMAIL PROTECTED] Mon, 4 Sep 2000 10:54:23 -0500 No one knew it was on wnpp you idiot. As for your adopt or die, bullshit. Packages are not removed unless they present too many bugs to stay in. Silo had no bugs above normal, only 6 bugs in all, 5 of them were closable as is (already fixed), and the last was wishlist. Put up or shut up (to use your unique vernacular), because if you haven't got anything useful to say, you are just pissing people off. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: List of packages that could be dropped
On Tue, Dec 26, 2000 at 03:22:21PM +0100, Christian Kurz wrote: |silo (195 days old) Has this package been removed from unstable and if yes, why? It's currently still listed in the wnpp but I could find it which apt-cache search silo. You can only remove this if you want sparc to be unbootable, which I hope is not your intention. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 03:50:41PM +0100, Federico Di Gregorio wrote: Scavenging the mail folder uncovered Wichert Akkerman's letter: Previously John Hasler wrote: Undo. dpkg will support rollback at some point, when reiserfs supports transactions. that's completely crazy. will you force anybody who wants rollback to use raiserfs? generic applications like dpkg should be indipendent of the fs used (as long as the fs provides an adeguate set of features, surely i don't ask for a full-working dpkf on vfat...) Heh. Do you have any idea how hard it is to implement rollback? Without package support, it is almost impossible without a system layer handling it (snapshot of preinstall state, so you can revert completely back to it). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 04:10:43PM +0100, Federico Di Gregorio wrote: Scavenging the mail folder uncovered Ben Collins's letter: On Sun, Dec 24, 2000 at 03:50:41PM +0100, Federico Di Gregorio wrote: Scavenging the mail folder uncovered Wichert Akkerman's letter: Previously John Hasler wrote: Undo. dpkg will support rollback at some point, when reiserfs supports transactions. that's completely crazy. will you force anybody who wants rollback to use raiserfs? generic applications like dpkg should be indipendent of the fs used (as long as the fs provides an adeguate set of features, surely i don't ask for a full-working dpkf on vfat...) Heh. Do you have any idea how hard it is to implement rollback? Without package support, it is almost impossible without a system layer handling it (snapshot of preinstall state, so you can revert completely back to it). * dpkg-repack the package (using the installed configuarion files [the only the user can modify/replace]) * copy .deb file to /var/cache/dpkg/rollback/ * install new package * dpkg --rollback remove current package (doea a downgrade) and replaces all the files from the repackaged package * dpkg --clean removes all the repackaged packages. You are missing the fact that the old package does not understand that the new package possibly setup some things (configuration settings, diversions, symlinks, removal of cruft, alternatives) that it cannot recover from. You are missing the fact that it is not as simple as replacing files. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: finishing up the /usr/share/doc transition
On Fri, Dec 22, 2000 at 01:04:26PM -0800, Joey Hess wrote: It has been more than 1 year since the technical committee decided how the /usr/share/doc transition would be accomplished[1], and in that time most packages have implementede the transition. The decision stated that Thus, potato+1 (woody) ships with a full /usr/share/doc, and a /usr/doc full of symlinks. and went on to detail how woody+1 (sarge?) will begin to phase out the symlinks and how woody+2 will finally be free of this mess. I'm looking forward to a day with a lot less postinst and postrm scripts myself, so I want to make sure we don't miss the traget of full conversion by woody's release. There are a total of 645 packages that have not been converted[2]. There are 16 weeks between December 31st and Aj's projected freeze date for woody. If 40 people could do one package a week, we would be done. Or 20 people doing two a week, or just 6 people doing one a day. In other words, it seems acheivable, especially if we file bugs now on the undone packages, which would probably wake a fair number of maintainers up.. What do you think? I think we need to reevaluate this decision based on the fact that the bug in dpkg that forced this implementation (as opposed to a clean /usr/doc symlink to share/doc) has been gone for awhile now (the potato dpkg is fixed). For those that do not remember, the bug in dpkg would have caused doc files to go missing if /usr/doc was a symlink to share/doc, once a package was upgraded from the latter to the former (docs in /usr/share/doc). That is no longer the case, so I would hope that our efforts would be better spent writing a transition script to handle the move (moving things from /usr/doc to /usr/share/doc, if needed, and removing symlinks). Note that I have a /usr/doc - share/doc symlink on all my systems right now (note, auric is also setup this way, running potato, without any errors or missing files). Can we do this and avoid further hacking around with this? Moving to /usr/share/doc in woody is possible. The tools handle it, packages that support the symlink in postinst/prerm already magically work (IOW, any policy abiding app supports it), packages that use the old /usr/doc work with it, and new packages that only use /usr/share/doc will work with it. We just need a script/program that sanely does this transition, then creates the /usr/doc - share/doc symlink. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Boost Windows Reliability!!!!!
On Sat, Dec 23, 2000 at 12:00:26PM +1100, Daniel Stone wrote: from the secret journal of Ben Collins ([EMAIL PROTECTED]): Solution: just deal with the few spam we get so as not to hinder real discussions. Ben amen. OK, if you can do that, I'm absolutely thrilled to do it, PLEASE make debian-devel spam-free. But the problem is that you CAN'T. Because there's too much of it. What are we going to do, kill everything with more than 2 exclamation marks? Come on, don't tell me you're _that_ naive. By deal with it I mean, get over it. It's only a few spam, you can hit the delete key as easily as anything else. BTW, I'm on a 28.8, and I get over 1000 emails a day from all the lists I am sub'd to. So I do see a lot of spam, even beyond Debian's lists. If I can ignore it, so can everyone else, IMNHO. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Boost Windows Reliability!!!!!
On Sat, Dec 23, 2000 at 02:21:46AM +0100, Robert van der Meulen wrote: Quoting Ben Collins ([EMAIL PROTECTED]): BTW, I'm on a 28.8, and I get over 1000 emails a day from all the lists I am sub'd to. So I do see a lot of spam, even beyond Debian's lists. If I can ignore it, so can everyone else, IMNHO. Ignoring spam has made the internet the spam-ridden place it is right now. As long as people do not do anything about it, spam will be as commonplace and as 'ignorable' as spam by snailmail. I do not like that, and lots of people don't. Apart from the annoyances, spammers almost regularly clobber up mailservers, network links, and are being _very_ intrusive. Spam is not an ignorable problem, and every spam-account i can manage to get killed, will get killed. If your opinion is that we shouldn't actively try to bring down the spam to a minimum, and just delete it - that's your opinion, but definately not mine, and not a lot of others' too ;) My opinion is that trying to block spam is a losing battle. Trying to attack it at it's roots by closing open relays, filing suit on people breaking the law, etc..is the right thing. It's like arresting drug users, as opposed to arresting the drug smugglers. You should kill the root, not the offspring. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: why apt/dpkg not using bzip2
On Wed, Sep 13, 2000 at 12:38:58AM -0700, Joey Hess wrote: Ben Collins wrote: I think aside of one diff or many diffs a list of patches done to the code and where you got them from is a good thing to have in every package. Most patches are done by the maintainer, or submitted as bug reports. Those are listed in the changelog, but even then, it doesn't help dereference the patched source to it's individual patches. This is a really easy thing to do. It's called commenting your patches. And woe upon the developer who does not. Still requires manual editing of the .diff.gz to remove them on a per/patch basis (if for example your 10k/5 file patch gets merged upstream, but the rest of your 50k of patches don't). Also, if someone else wants just that patch (backport to a different version) they have to manually go through the .diff.gz aswell. My solution still wins :) -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Tue, Sep 12, 2000 at 11:42:32AM +0200, Bernhard R. Link wrote: On Mon, 11 Sep 2000, Mark Brown wrote: This only works, if the diff's are independend or one diff is diff are on the top of each other. So I do not see the advantage of many diffs. The advantage of having multiple diffs is that distinct changes can be kept distinct. You do need a system for ensuring that the diffs are applied in the correct order and so on, but given that multiple diffs are very much nicer. It becomes very much more obvious what has been changed and how, not to mention far simpler to adjust the set of changes that have been applied. As an added bonus, the handling of upstream source that include patches is more elegant. Is it realy so much easier? I do not have experiences with maintaining patched software. But I experienced for example, that I had to made major changes to apply a patch for a 2.0.30 kernel to a debianiced 2.0.36 kernel. And with I the software I develop, there is seldom one patch that would not collide with an other. I imagine it much easier to have the orginal code and the debian code, where I can get from one to the other through one diff. Correct me, if I err, but when you have an code with two patches and want to change patch 1 to an newer version of this, wouldn't you need to change patch 2 then, too? Generally, you don't have a problem with colliding patches. Even when you do have some overlap, it's not all that difficult. After all, we are only talking 5 - 20 patches on average, not 50 - 100. Most patches are small and in the form of security fix or get rid of compiler warnings etc.. Aside from requiring CVS this looses information for anyone without access to the repository. That's a hassle when you get maintainer changes and makes the packaghe source itself much less useful than it could be. I think aside of one diff or many diffs a list of patches done to the code and where you got them from is a good thing to have in every package. Most patches are done by the maintainer, or submitted as bug reports. Those are listed in the changelog, but even then, it doesn't help dereference the patched source to it's individual patches. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: determining if we're using db.h from libc6 or libdb2?
On Tue, Sep 12, 2000 at 12:46:02AM -0700, Darren/Torin/Who Ever... wrote: Is there some set of defines such that I can determine with #ifdef that I've got a copy of glibc2 that has db.h as an include file? My plan is that if such a #ifdef is true, then I can #include db2/db.h. Keep it at db.h, since in a few days, it wont matter. Db2 is getting removed from glibc, and your only choice will be db.h or db2/db.h from libdb2 (both the same file, just db.h is the default place). -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 10, 2000 at 06:55:54PM -0700, Joey Hess wrote: Ben Collins wrote: That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. lol, whoever said our source package format was user friendly to begin with? It doesn't matter if it's user-friendly. The DBS package format is not developer-friendly. But it's maintainer friendly, and that is far more useful for us to have good packages. Debian source packages, have from time immemorial, been appropachable as normal code trees that you can edit just as you would any code tree. The DBS messes this whole concept up. Now you have to deal with patches manually, and you have to dig up some obscure commands to even get a source tree you can hack on. The fact that I can no longer pull the debian source to libc, and immediatly jump into the source code, makes debian that much less useful to me, means I'm that much likely to bother to use the source for libc, etc. Agreed. However, this is a documentation issue and nothing else. Just because you don't know how to use it, does not degenerate it's usefulness to the people who do use it. NMU's are not as important as actual MU's, and are less frequent aswell. Your choice, your loss :) The format I use has saved my countless hours and tons of headaches. FWIW, I have several times sat down to NMU one package or another (for various good reasons), discovered it used DBS, and decided my time wasn't worth it. FWIW, before I started using a DBS based source format, I sat down many times to try and upgrade my packages to new upstream source and was so frustrated with forward porting patches that it sat for weeks or even months at a time before I got enough time/energy to do so. Example: getting openldap2 ready took all of 30 minutes. This included forward porting each patch. With the old format, I would have either manually went throught the diff.gz, or run the patch and went through each .rej. My time was saved, which makes the package more up-to-date, better maintained, and needs less attention. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 10, 2000 at 07:43:07PM -0700, Joey Hess wrote: Ben Collins wrote: It doesn't matter if it's user-friendly. The DBS package format is not developer-friendly. But it's maintainer friendly, and that is far more useful for us to have good packages. I was using developer in the sense of debian developer. However, friendlyliness for users is equally important. Still, documentation. Dpkg-source isn't friendly without documentation. Nothing is. FWIW, before I started using a DBS based source format, I sat down many times to try and upgrade my packages to new upstream source and was so frustrated with forward porting patches that it sat for weeks or even months at a time before I got enough time/energy to do so. Example: getting openldap2 ready took all of 30 minutes. This included forward porting each patch. With the old format, I would have either manually went throught the diff.gz, or run the patch and went through each .rej. My time was saved, which makes the package more up-to-date, better maintained, and needs less attention. I'll bet I can get better results using cvs than are possible with DBS. Maybe you can, because that is what you prefer. I don't feel like setting up a CVS repo to do my package maintainence, since that means I tie myself down to one machine, or have to setup ssh or pserver so I can work on it from anywhere, and that assumes I have a net accessible development system. Sorry, but that's just not possible for most folks. I bet I get better results with what I have, since I use it day-to-day, and it does everything I need to do. I already have a new README.build that I am putting in all my packages, which will document how I have things setup. That takes away most of the problems. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 10, 2000 at 08:26:37PM -0700, Joey Hess wrote: Ben Collins wrote: Still, documentation. Dpkg-source isn't friendly without documentation. Nothing is. Oh look, here's a tarball. Hm, and here is a patch that seems to apply to it. Ok, I see a full source tree now and I'm on my way. vs. Oh look, here's a tarball. Hm, and here is a patch that seems to apply to it. But wait, why did that tarball include another tarball, and why did that patch include what looks like other patches inside it? Double patches? Ugh. What do I do from here? How do I apply all these patches in the right order? hmm, there's a file README.build, oh run 'debian/rules setup'. cool, that works now The only reason this isn't cleaner is because it's a hack on top of an aging source format. Making it more streamlined would require support from dpkg-source. IMO, it would look like: foo_1.0.tar.bz2 foo_1.0-3_debian.tar.gz (debian directory) foo_1.0-3_patches.tar.gz (get applied in the order they are packed) Makes more sense than what we have now, and is easier to seperate (where as now, the entire debian directory is in a diff, and would be easier to parse as a tarball of it's own). The point being, I'm not arguing that the format I or other people are using is right, but the system is more useful than what we are given to use (the diff/dsc/tar setup). You can argue about the tar in a tar all you want, I don't like it either. But the seperate patch set is a must, and don't argue well apply and remove it during the build/clean targets of debian/rules because that is ugly and asking for problems. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Mon, Sep 11, 2000 at 07:26:15PM +1100, Herbert Xu wrote: Nicolás Lichtmaier [EMAIL PROTECTED] wrote: Source packages must be for everybody, because we want everybody to go to sources, to help us, to get involved... Well put. Perhaps what we need is a utility to deDBSify packages. Then the DBS maintainers can keep using DBS to maintain their packages, but run this utility just before they upload. Perhaps we need to standardize on a source format that suits these maintainers and is still easy for everyone else to use, aswell as being well documented. Don't take away the tools that make the maintainers life easy, just to satisfy everyone else. After all, it is the maintainer who is putting in his hard work to make the package available anyway. There are lots of packages like this, and Wichert has already started discussions on it. How about the folks who hate DBS join in and make the end result suitable for everyone. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Upcoming changes with glibc and db2
Well, with glibc 2.1.93 on the way into woody, you will all need to note that db/db2 are not in glibc anymore. For now, libdb2 will be supplying the symlinks required to keep packages compiled against glibc's db/db2 from breaking, and libc6 will depend on this new libdb2 package (same as before, but with symlinks). Now, some applications will report: foo: /usr/lib/libdb.so.[23]: no version information available (required by foo) This is mostly harmless, but means the program needs to be recompiled agains the new libdb2-dev. Yes, you will have to start adding Build-Depends for libdb2-dev for applications that need it. I don't like adding extra deps to glibc, so you all will have to fix this yourselves. Be fore-warned, I will periodically check packages that have library links to libdb.so.[23] (the old glibc db libraries) and report bugs on them for recompilation. By the time woody releases, I want to remove the libdb2 dependency from libc6. It's only there for now to keep things from breaking on running systems. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
NSS db module, split from glibc
Just a heads up, the nss_db module is going away from glibc. It was split from glibc upstream, and will be packaged seperately from now on. For a short while after glibc 2.1.93 is uploaded to woody, there will not be an nss_db module, until I get that package done. If you use this module... Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC/ITP: everybuddy-cvs
On Fri, Sep 08, 2000 at 11:18:54PM +0200, J?rgen A. Erhard wrote: Ben == Ben Collins [EMAIL PROTECTED] writes: Ben On Fri, Sep 01, 2000 at 04:06:33PM +, michael d. ivey wrote: I started making personal debs of the everybuddy CVS snapshots because EB releases tend to lag pretty far behind the code in CVS. I called my package ebsnap, and made it conflict with everybuddy. I put it on my site, and that was that. Now, I've adopted everybuddy and gotten through the NM process. I'd like to add the CVS version to unstable...but I don't know what to call it. My current idea is everybuddy-cvs, and make it conflict with everybuddy, and conflict/replace ebsnap, for the people who may have downloaded ebsnap. Is that the correct way to proceed? I'll be doing the rename and the upload sometime early next week. Ben Keep it the same name. Woody is unstable right now, there are Ben a lot of packages that are pre-release just for the sake of Ben testing and working out bugs. So, IMO, keep it the same name, Ben and version it appropriately. Also might add This is a CVS Ben build at the bottom of the description. Sorry, but that is *wrong*. What happens when we release and everybuddy is still not stable? Do we pull it out if it's too unstable? Why, of course we will. Which would leave our users w/o everybuddy. Or we could pull it, and replace it with the last stable... oops, the version number will be lower. So we'd need an epoch. Very bad. I've lobbied Clint Adams for doing both a zsh 3.0 and a 3.1 package. I wouldn't want to see other packages going that unstable is the greatest, fuck the users who want bulletproof stable. I think it's obvious I feel strongly about this... If people want stable, they can use the stable distribution. We call it unstable for a reason. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: dpkg-python
On Sat, Sep 09, 2000 at 08:27:56PM +0200, Milan Zamazal wrote: Unless anybody else is interested, I plan to pick up the Python part of dpkg-scriptlib and make it a separate (and maintained:-) package. I also plan to enhance it with few lines of code I wrote for some thing--adding few classes for interfacing Sources/Packages with LDAP (yes, this should work (not only) with data produced by Ben Collin's scripts). Milan Zamazal Which scripts? Note, the objectClasses in openldap1 are seriously outdated. If you want up-to-date stuff, look on auric.debian.org in ~bcollins/pkg-ldap/ -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 07:48:54PM -0300, Nicol?s Lichtmaier wrote: Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. bzip2 also uses more memory which can be an issue with lowmemory systems. I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? Do you realize how much ram dpkg itself already takes up? Add that to bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, doing this, and you need 16megs *free* physical memory just to keep from swapping. As for 4 meg machines, the current gzip setup is almost unbearable just for that (believe me, I have an 8 meg system, and I don't want to even imagine a 4 meg system trying to handle dpkg, much less dpkg+bzip2). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 11:49:32PM -0300, Nicol?s Lichtmaier wrote: Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. bzip2 also uses more memory which can be an issue with lowmemory systems. I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? Do you realize how much ram dpkg itself already takes up? Add that to bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, doing this, and you need 16megs *free* physical memory just to keep from swapping. As for 4 meg machines, the current gzip setup is almost unbearable just for that (believe me, I have an 8 meg system, and I don't want to even imagine a 4 meg system trying to handle dpkg, much less dpkg+bzip2). Uhm.. you are right. But it could still be used for Packages.gz and for the source package. Many packages are now being packaged in bz2 upstream (eg. lftp, one of mine)... For Sources and Packages that's fine, IMO, but your assertion about source packages is a little misleading. apt-get source for gcc and glibc[1]. Check the tarballs internally. You'll notice they are .tar.bz2. This is done with little loss of space over straight .bz2. A new format and hacking is not needed for you to use this already (packages doing this need to Build-Depend on bzip2). Ben [1]: Also check openldap, shadow and pam for the same style setups. Yes, it's sort of a hack, but it's a clean hack and the system provides much more than a way to package up .bz2 tarballs. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Mon, Sep 04, 2000 at 02:25:39AM -0300, Nicol?s Lichtmaier wrote: I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? Do you realize how much ram dpkg itself already takes up? Add that to bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, doing this, and you need 16megs *free* physical memory just to keep from swapping. As for 4 meg machines, the current gzip setup is almost unbearable just for that (believe me, I have an 8 meg system, and I don't want to even imagine a 4 meg system trying to handle dpkg, much less dpkg+bzip2). Uhm.. you are right. But it could still be used for Packages.gz and for the source package. Many packages are now being packaged in bz2 upstream (eg. lftp, one of mine)... For Sources and Packages that's fine, IMO, but your assertion about source packages is a little misleading. apt-get source for gcc and glibc[1]. Check the tarballs internally. You'll notice they are .tar.bz2. This is done with little loss of space over straight .bz2. A new format and hacking is not needed for you to use this already (packages doing this need to Build-Depend on bzip2). That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. lol, whoever said our source package format was user friendly to begin with? [1]: Also check openldap, shadow and pam for the same style setups. Yes, it's sort of a hack, but it's a clean hack and the system provides much more than a way to package up .bz2 tarballs. I'll avoid that hack as much as I can... =) Your choice, your loss :) The format I use has saved my countless hours and tons of headaches. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical Bugreport for September 1, 2000
On Mon, Sep 04, 2000 at 06:07:04PM +0200, Turbo Fredriksson wrote: Quoting BugScan reporter [EMAIL PROTECTED]: Package: nscd (debian/main) Maintainer: Joel Klecker debian-glibc@lists.debian.org 58367 nscd: 'broken pipe' error causes entire box to be unusable [IGNORE] No fix or workaround available for potato (ajt) Is this fixed in woody? I have been forced to shutdown nscd totaly, but I'd like to have this function... I'm starting testing of glibc 2.1.93 right now. We'll see how it goes. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help on Debian Project - Need Me?
On Sat, Sep 02, 2000 at 07:40:43PM -0700, Kyle Lynch wrote: Hello, I'm Kyle Lynch, ive worked with Debian for a little while, it beats all the other dists :) Anyway, I'm wondering, is there any need for a website redesign or any icon needs? I have Adobe Photoshop and I am a expert at it. I use Macromedia Dreamweaver and I would LOVE to help this great project. I would love to be on a website redesign team or Icon Creation Team. Does anyone know where I can go to help on this or who I should contact? Well, IMO, anything that goes on the Debian website better be created by free software. No offense, but if I start seeing Made with Macromedia or Designed with Photoshop on the website, there will be hell to pay :) There are several criteria for the website, unspoken, but surely everyone knows this: a) It needs to be browsable by text-only browsers without going through some click here for cheezy text only site. b) Graphics need to be created in Gimp (is there any other free graphics program around worth its salt?). c) Geared towards informational and structural concerns rather than eye candy. When I go to the Debian webpage, I want answers and information, and I think most people feel the same way. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 04:51:53PM +0600, Sergey I. Golod wrote: Bas Zoetekouw wrote: Thus spake Sergey I. Golod ([EMAIL PROTECTED]): Why apt/dpkg doesn't use bzip2 for Packages file? -rw-r--r--1 root root 749427 Sep 3 00:56 Packages.bz2 -rw-r--r--1 root root 1024180 Sep 3 00:56 Packages.gz It's about 25% can be saved in download. Yeah, but I guess it would take about twice the time to unpack. Please don't do that to my poor 486 :-(( But extra size = extra traffic = extra money, that's worse. Unpack no cost at all (except you time, ofcourse). wbr, Serge. p.s. If Debian change default compression to bzip2 in future, we can save about ~20-25% in size of distribution. It especially important to reduce network traffic in updateupgrade operations. Now, we cannot save that much. Your example of compressing pure text is not a measure of this whole archive. I've tested it, and converted an entire local binary-sparc/main tree to internal bzip2 compression. It saved a grand total of 197 megs from 1.5gigs. Roughly 15% at a quick guess. This wouldn't even drop us down a single CD. We have new things in the upcoming dpkg, one of those being to support bzip2 in the package format. However, I don't see it being used in Debian's archives right away. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help on Debian Project - Need Me?
On Sun, Sep 03, 2000 at 12:54:34AM -0500, Manoj Srivastava wrote: Ben == Ben Collins [EMAIL PROTECTED] writes: Ben Well, IMO, anything that goes on the Debian website better be Ben created by free software. No offense, but if I start seeing Ben Made with Macromedia or Designed with Photoshop on the Ben website, there will be hell to pay :) Conversly, if the output is pristine HTML, I see no reason to refuse it. Have you ever seen the header of a JPEG output from PhotoShop? It's full of advert/copyright for the program that created it. A tell tale sign you can get away from without some sort of strip program, which IMO is just cheating. Anyway, we shouldn't be using pure html for out webpages (which I think we don't). I'm pretty sure our webpages are generated from a higher level language. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Sun, Sep 03, 2000 at 06:09:27PM +0600, Sergey I. Golod wrote: Ben Collins wrote: Yeah, but I guess it would take about twice the time to unpack. Please don't do that to my poor 486 :-(( But extra size = extra traffic = extra money, that's worse. Unpack no cost at all (except you time, ofcourse). wbr, Serge. p.s. If Debian change default compression to bzip2 in future, we can save about ~20-25% in size of distribution. It especially important to reduce network traffic in updateupgrade operations. Now, we cannot save that much. Your example of compressing pure text is not a measure of this whole archive. I've tested it, and converted an entire local binary-sparc/main tree to internal bzip2 compression. It saved a grand total of 197 megs from 1.5gigs. Roughly 15% at a quick guess. This wouldn't even drop us down a single CD. Yes, binaries. But you also forgot about sources. Or 15% - include binarysource? Lots of sources already use bzip2 internally, so there's a no-gain situation with some. We have new things in the upcoming dpkg, one of those being to support bzip2 in the package format. However, I don't see it being used in Debian's archives right away. Anyway, sometime Debian-community must start this job. Why? 15% b/w isn't that big of a deal unless you are mirroing the entire distribution. If that's a big deal to you in that situation, buy a CD. On top of that we start to have backward compability issues (some packages will never be able to be compressed with bzip2 to insure we can still do upgrades, etc...). Theoretically, it may sound nice, but technically, there is no gain. If we support it with the package manager, then it's a very simple script to convert all packages to bz2 internally, and CD vendors can opt to do this, and sell compact ISO's. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC/ITP: everybuddy-cvs
On Fri, Sep 01, 2000 at 04:06:33PM +, michael d. ivey wrote: I started making personal debs of the everybuddy CVS snapshots because EB releases tend to lag pretty far behind the code in CVS. I called my package ebsnap, and made it conflict with everybuddy. I put it on my site, and that was that. Now, I've adopted everybuddy and gotten through the NM process. I'd like to add the CVS version to unstable...but I don't know what to call it. My current idea is everybuddy-cvs, and make it conflict with everybuddy, and conflict/replace ebsnap, for the people who may have downloaded ebsnap. Is that the correct way to proceed? I'll be doing the rename and the upload sometime early next week. Keep it the same name. Woody is unstable right now, there are a lot of packages that are pre-release just for the sake of testing and working out bugs. So, IMO, keep it the same name, and version it appropriately. Also might add This is a CVS build at the bottom of the description. Note, you can't break much anyway. I'm about ready to upload glibc 2.1.93 (pre-2.2) to woody anyway, so if anything is going to break, it's most likely going to be my fault :) -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Learning dpkg/apt
On Fri, Aug 18, 2000 at 09:30:18PM -0600, Dwayne C . Litzenberger wrote: I want to learn the total innards of dpkg/apt. I recently filed a bug complaining about the fact that dpkg is too slow, but I want to actually _do_ something about it (other than ordering other developers around). So Can someone who knows dpkg give me a good list of the stuff I should read, or the order in which I should read the dpkg/apt source code? Source is the best documentation for a program...all hail the invention of comments :) -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Essential virtual packages
On Sat, Aug 19, 2000 at 04:16:08PM +1000, Glenn McGrath wrote: Im trying to understand a few things relating to packaging... take the kernel for example I just did a fresh install of potato, and then installed my own kernel image built by kernel-package, dselect lists my custom kernel as being the only kernel-image installed, i cant see any reference to the original kernel image. Shouldnt both be the original kernel and my custom kernel be listed as being installed? According to my understanding from the policy manual the functionality provided by the virtual package kernel-image, which in my case is supplied by both the original and custom kernel should be both required and Essential... I cant find any details on the virtual package kernel-image except its name, do virtual packages have priorities and can they be marked essential ? Kernel is not and essential package for two very specific reasons. Firstly, the user might not wish to use a packaged kernel, and rely on manually installed kernels. Secondly, it is very possible to not have a kernel installed on the local system at all, like for network based clients. As far as your situation, if you installed the same version as the original kernel, then it replaced that package. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
NMU's completely removed from kaffe in woody
(Ean, you are Cc'd just in case you aren't sub'd to -devel, please feel free to denote otherwise to avoid duplicates) Over the course of potato release, there were several NMU's done on the kaffe package to fix some RC bugs. I've listed them here for clarity and reference: 59420: kaffe_1:1.0.5e-0.3(frozen): bad register names on m68k 58434: kaffe: can't build from source 59575: jit3 not supported on sparc build 58434: can't build from source 55835: kaffe_1:1.0.5e-0.1(frozen): build error: make -j fails 55618: kaffe: shell scripts starting kaffe components contain invalid paths 55848: jdk1.1: paths screwed up ? 55961: url in copyright file doesn't work 55618: kaffe: shell scripts starting kaffe components contain invalid paths 49893: New upstream version 52911: Kaffe new version available 34385: kaffe: symlinks for appletviewer missing 36715: kaffe: javaverify alternative 36869: kjavac and kjavadoc missing 36711: kaffe: change dependencies 51416: debian kaffe is missing functionality 51230: kaffe: No exception raised when an external program is not found Some of these are rather important bug fixes. Some are not. According to the changelog in potato, the last upload Ean made was in April of 1999, followed by 5 NMU's by myself, Adam Heath and Zed Pobre. Note Adam works for Ean, and it is Ean's contention that since he asked Adam to make those NMU's on the clock (paid), that he was not ignoring the package, but delegating it to him. Now, here's the real problem. In the woody package, none of the NMU's show up. Not only are they gone, but all of the modifications that were made are gone aswell. So the fixed status of all of these bugs is now incorrect and they all need to be set back to their original severity and checked/fixed again! All of this work gone to waste, when before Jul, the maintainer had nothing to do with his own package, and others had to fix the damn thing. Even more suspicious is a new entry in the woody changelog from Dec of 1999, that never shows up potato (which has a last changelog date of March 2000). So now not only are all the NMU's ignored, but false changelog entries are made, for uploads that were never done! This is rediculous. Ean knows about these NMU's. He asked Adam to peform his, and I emailed him about the ones I did, and he responded. Why must our packages take a step back!? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: NMU's completely removed from kaffe in woody
On Fri, Aug 18, 2000 at 03:06:55PM -0500, Ean R . Schuessler wrote: Well Ben, there are two reasons that I ignored the NMUs. The first reason is that Kaffe revisions have been so long in coming that the 1.0.6 source base bears little to no resembelence to the 1.0.5 source. Maintaining the patches that were done against 1.0.5 would be difficult at best and I was more concerned with getting 1.0.6 out so that people could use it. So superficial version numbers are more important than stability? I see. Problem is that the patches I applied to this had a lot to do with the debian files (build failures because of faulty hard coded options). Which means, you should have incorporated them. This issue is about to be compounded by the fact that Transvirtual is merging all of their proprietary code into the open source base. This means that a spectrum of features (framebuffer AWT, improved JIT, much better native thread support, etc.) will be moving into the GPL source base. So, in short 1.0.6 and the release after will both represent what are effectively new pieces of software and tracking bugs let alone source patches across those releases will be a waste of everyone's time. Hey, sounds _a lot_ like 10% of the rest of Debian packages! WOW. However, that is no excuse to ignore a) valid patches and b) changelogs which denote the history of the package as it pertains to Debian. Even if you don't like it, it is still there, and should remain. Removing it in favor of your personal image is not an excuse. The second reason I chose to cut a lot of NMU changelogs was that you took it upon yourself to load them with vindictive, personal and unprofessional statements. Why you need to say things like I wish the maintainer of this software would pay attention to his packages in a changelog is completely beyond me. Vidictive? Hell, I could have said a lot worse. I don't think making a request for some attention to your package was too much to ask. I insured that a 1.0.5 release was available days after it was released, as I did with 1.0.6, yet you continue to try and paint a picture of negligence. Frankly, it seems clear to me that its personal and I don't no why. Nor do I care. No, it's clear that removing patches and changelogs that I and others took the time to NMU, was personal. I spent all last week working in Transvirtual's offices, know Tim Wilkinson personally and have an active business relationship with TVT. I use Kaffe on a daily basis, package it for my own use and currently use it on a number of handheld devices including the MIPS platform (for more info see: http://www.pocketlinux.com). Irrelevant. In short, I don't want to belittle your comments but I would ask you to conduct yourself a little more professionally. At least try to bring issues to me (or at least debian-java) before you waste devel's time with issues that have little or no basis. Professionalism is what I did. I fixed the package, and made comments for the maintainer. A simple request to do this yourself is not vindictive nor unprofessional. Me having to do your job...now that makes you unprofessional. Irregardless of how cozy you are with upstream companies, you still need to fix bugs, not just killoff valid patches and work. Again, you chose the quick and short route. Go back to when you knew what the hell was going on with your package, upgrade to a new uptream (which you claim is so different, and took so much effort) instead of doing it the right way, by acknowledging the NMU's, forward-porting the patches and maintaining stability. You did none of those. I bet you did not even try to check the patches. It's not as if they were hard to find. In the potato package they are even seperated in debian/patches/, so it would have been a piece of cake to get them. You claim you wanted to make it available so much, well guess what. The bugs you ignored are now present again, and you just kept your nifty new upstream version from more people because it FAILS to build and IS broken. I bet you didn't even try to get the source patches incorporated upstream. Roman Hodek took quite a bit of debug and test time to track down the m68k errors, and now that you blew off that, it probably wont build on there anymore. Good job Ean. You've done an excellent job of maintaining a quality package. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Broken bootable SPARC CD#1, and why this happened
I've gotten reports that the ISO for CD#1 on sparc is completely broken. Although the packages and dist files are there, the CD will not boot, since almost none of the boot1 files are on the image. Now I could blame this on Phil, who created the images, but that wouldn't be right, since he can't be expected to know what a bootable sparc image looks like, nor does he even have a sparc to test this on. I could blame myself, but the fact is the image was not created right (it needs to be done as either root, or under fakeroot, which requires the *entire* process be done in a single session, not multiple fakeroot incantations, which might be the cause here), and I could not have been expected to download 650megs over my 33.6k modem within the few hours timeframe that these things were created and distributed under. I could blame... Well, you get the point. I don't want to place blame. I just don't want to see this shit happen again. Here's what I want to see next time (2.2 r1): 1) First of all I think the CD's themselves need a sub revision. Obviously if we were to create a new CD image set just for sparc, we can't call it 2.2 r0 since there wouldn't be any way to designate it from the original broken ones. We can't call it 2.2 r1, since it really isn't, and the dist hasn't changed, just the image. So maybe the CD's need to be labeled like 2.2 r0 cdv0 (for CD Revision), and in this case we could have made 2.2 r0 cdv1 for sparc to fix this. 2) Next time we create some very important images, I think one person needs to be designated responsible for testing images prior to release. This requires one of the following: a) The person download them, burn them, and test an install or two. Verify certain points (maybe a checklist...). b) If the designated person cannot do this, they can opt to pay for images to be shipped to them (Phil, is this too much to ask a volunteer? :), then test them. We have to remember, vendors are burning these CD's almost as soon as we make them available. WE are costing them money when we fuck up, and it isn't thre fault because they expect these things to work when we make them available. 3) After each arch is tested, that arch is released, independent of the other archs. That way we don't slow up everyone else because of slow testers. 4) From here, things should be handled a lot better AFA mirroring (before being made world readable to the public), but I'll leave that to the debian-cd folks to decide how to make that better. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Broken bootable SPARC CD#1, and why this happened
On Thu, Aug 17, 2000 at 07:43:48PM +0200, J.A. Bezemer wrote: On Thu, 17 Aug 2000, Ben Collins wrote: I've gotten reports that the ISO for CD#1 on sparc is completely broken. Although the packages and dist files are there, the CD will not boot, since almost none of the boot1 files are on the image. I'd hardly call this completely broken. I guess you can still do upgrades. And I hope there are other possibilities to start the install system besides booting from the CD. [Please tell me the easiest option, or a precise location in some document, to refer to on the cdimage.d.o webpages.] Obviously, any install option that != CD would apply there. Atleast, that would be obvious to me. 1) First of all I think the CD's themselves need a sub revision. Obviously if we were to create a new CD image set just for sparc, we can't call it 2.2 r0 since there wouldn't be any way to designate it from the original broken ones. We can't call it 2.2 r1, since it really isn't, and the dist hasn't changed, just the image. So maybe the CD's need to be labeled like 2.2 r0 cdv0 (for CD Revision), and in this case we could have made 2.2 r0 cdv1 for sparc to fix this. Oh please!! Unlike some people like you to believe, there exist no revisions other than CD revisions. There are no FTP revisions. FTP changes _much_ more than the CDs due to many security fixes. An FTP revision indicates the state of the FTP archive whenever new CDs were made (or whenever some people think CDs could be made). About 90% of the time the FTP archive does not any longer match the CDs it is claiming to match. If we counted FTP revisions, 2.1 would be at revision 30 or something. So, a 2.2 r1 revision for new Sparc CDs would be the logical choice. However, I can understand that we would then want a complete series of all architectures, which isn't necessary at this point. Therefore, I'd strongly suggest we'd call it 2.2 r0.1 or maybe better 2.2 r0.5 (I hope we won't need a 0.6 then..) WTF is the difference? Nothing but a naming scheme. It's still a change, either way you do it, why do you want to nitpick the mechanism? 2) Next time we create some very important images, I think one person needs to be designated responsible for testing images prior to release. This requires one of the following: a) The person download them, burn them, and test an install or two. Verify certain points (maybe a checklist...). b) If the designated person cannot do this, they can opt to pay for images to be shipped to them (Phil, is this too much to ask a volunteer? :), then test them. We have to remember, vendors are burning these CD's almost as soon as we make them available. WE are costing them money when we fuck up, and it isn't thre fault because they expect these things to work when we make them available. I do agree, but... I think you'll have some trouble finding testers for !=i386 who can a-priori say they'll be available whenever the release manager thinks the distro is ready. And then making images takes time, testing them takes time, shipping may take even more time (count at least 4 days for any international shipping unless you want to pay really much). IMO, well worth it to avoid any future problems of this kind. Or is quality second priority, and meeting release dates first? 3) After each arch is tested, that arch is released, independent of the other archs. That way we don't slow up everyone else because of slow testers. Do you want to officially release a distro, say woody, _before_ the CD images are available, or _after_ the images are available? I've personally always opted for the latter. But that would mean the slowest tester is/feels responsible for all the delay. How to handle that? Uh, the official release CD images were not created until after the symlink change. The distribution is released not the CD images. They come after. The testing and release of those needs some time, irregardless of the distribution timeline. We can't opt for hey we released CD's the same DAY!, over dist is released, ISO's are coming soon after some testing. Quality, quality, qualitynot superficial release dates. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: How many CDs in potato?
On Tue, Aug 15, 2000 at 07:19:27PM +0300, Eray Ozkural wrote: On Tue, 15 Aug 2000 19:16:16 Peter S Galbraith wrote: Can anyone tell me how many CDs the official ISOs have for: - i386 main + main/non-US ( + contrib ?) - sources Official sets are main+contrib, which is 3cd's. This can include non-US or not (only CD1 is different in that case). Sometimes vendors provide a 4th binary CD with non-free (may or may not include non-US/non-free). The source CD's are also 3 images main+contrib. Not sure how they handle non-US and non-free. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: kernel-image with the same version
On Wed, Aug 16, 2000 at 07:43:14AM +0900, Atsuhito Kohda wrote: Hi all, I installed recently potato from scratch. Rescue disk installed kernel 2.2.17 and I rebuild kernel-image with kerne-source 2.2.17 so the version of kernel was same for both. When I installed kernel-image-2.2.17*.deb which I rebuild then /vmlinuz and /vmlinuz.old were created but both pointed to the same /boot/vmlinuz-2.2.17. This means no back-up of old kernel was retained. In my case, new kernel seemed to work fine so there was no problem, I guessed, but this might cause problems. Is this inevitable or I am missing something? Edit /etc/kernel-img.conf and add this line: reverse_symlink := yes That will make /vmlinux the actual file, and the ones in /boot will be the symlinks. That may solve your problem (try installing the kernel again to test). -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: ITP: gcc, binutils, libc, gdb for Amtel AVR microcontrollers
On Mon, Aug 14, 2000 at 11:04:15PM +0200, Hakan Ardo wrote: Hi, the entire gnu develoopnet environment is ported to the avr arcitecture and runs nicely under debian. Currently all that excists as debian packages are a few asmeblers and programmers. I intend to create the following debain packages: avr-binutils avr-gcc avr-libc avr-monitor (code monitor used by gdb) avr-gdb avr-devenviron (contains dependencies on all the packagses you need to get a full featured development evironment for the avr as well as some simple examples and a readme to get started) Is this based off the actual upstream source, or is it a fork? If the former, then I suggest coordinating with the relevant maintainers rather than duplicating source. What versions of these tools are being used? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: ITP: gcc, binutils, libc, gdb for Amtel AVR microcontrollers
binutils is part of the actual upstream source version 2.10 gcc is distributed as a patch to version 2.95.2 and gdb as a patch to 4.18, the rest is not related to actual gnu sources. Excellent. Then most likely all you need to do is get the target added to the binutils-multiarch package, and dep on that for the other tools. I'll contact the binutils maintainer to see if we can coordinate the package, as for the others it seems hard to build from the same code tree as it has to be patched... I'd email the respective maintainers. They may have some ideas about that. I assume the libc is not part of glibc at all, so that most likely needs to be its own package. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: ITP: lirc, devfsd
Similarly, I have packaged devfsd (http://www.atnf.csiro.au/~rgooch/linux/). This one still needs a couple of problems ironing out first. No offense, but I hope you realize the amount of effort that will be needed for devfsd. Since it is a key element in our 2.4.x upgrade path, the amount of policy and technical bugs will be tremendous (permissions, adding support for default compatibility devices, etc..). I just don't want to see anyone go lightly into packaging devfsd. If you aren't prepared to take on the responsiblity of what will most likely become a base and essential package, leave it for some one else to do. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: ITP: lirc, devfsd
On Sun, Apr 02, 2000 at 06:42:59PM -0800, Ethan Benson wrote: On Sun, Apr 02, 2000 at 10:09:30PM -0400, Ben Collins wrote: Similarly, I have packaged devfsd (http://www.atnf.csiro.au/~rgooch/linux/). This one still needs a couple of problems ironing out first. No offense, but I hope you realize the amount of effort that will be needed for devfsd. Since it is a key element in our 2.4.x upgrade path, the amount of policy and technical bugs will be tremendous (permissions, adding support for default compatibility devices, etc..). I just don't want to see anyone go lightly into packaging devfsd. If you aren't prepared to take on the responsiblity of what will most likely become a base and essential package, leave it for some one else to do. I hope debian is not planning on `forcing' [0] the use of devfs with 2.4, last i checked it was still a compile time option (and experimental at that) there are some of us who don't care for devfs and do not wish to use it. [0] read making it exceedingly inconvenient to forgo or disable devfs in 2.4 kernels, for example neglecting to maintain or provide a real (non-devfs) working /dev directory. No this is not an option. There will remain a real /dev for (an I presume and support this particular viewpoint, but it has not been set in stone as of yet, and wont be until potato is out of the way, and 2.4 is in woody) atleast woody, and most likely the release after that. I would hope that we can have a completely devfs system for the release after woody, simply because it is the way that everything is going, and it is the Right Way. Note that makedev can create all of the base devices with one simple command. This makes it quite simple to get rid of devfs, even in the future if we ever do decide not to provide it by default on later distributions (in fact this can probably be scripted, so that if the system boots without devfs enabled, makedev will create everything needed on the fly). However, people will want to use devfs, and therefore devfsd will be needed in order to support the transition (without it, most programs will fail to find the new device locations). I am pretty sure that devfs will be used extensively in boot-floppies. The main reasons being that the rootdisks will be smaller without having to contain hardcoded device nodes. Secondly, it is easy to parse out what the available hardware is since the device nodes are only created when a driver actually finds the device and enables it (i.e. /dev/cdroms/cdrom0 wont exist unless there is actually a cdrom device). Since the boot-floppies are self contained, it wont even need devfsd for the installation program, since all the device paths can be made to work with devfs' setup. Again, these are my opinions alone, and nothing has been decided, but devfs will come of age, and we need to support it, and that will mean some work for the devfsd maintainer, whoever that may be. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Release-critical Bugreport for March 31, 2000
On Sat, Apr 01, 2000 at 10:13:38AM -0800, esoR ocsirF wrote: Caution, IANAD. Just tring to help Package: cricket (debian/main) Maintainer: Matt Zimmerman [EMAIL PROTECTED] 56948 cricket depends on non-existant package Package: ftp.debian.org (pseudo) Maintainer: Guy Maor [EMAIL PROTECTED] 60707 cricket depends on a nonexistent package Shouldn't these be merged? No, you can only merge bugs on the same package. One is against the pacakge itself, the other is for ftp.debian.org to remove that package. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
[WARNING](sparc): (not an april fool's joke) libstdc++2.10 2.95.2-8 is broken on sparc
Please do not install this package, but wait for the next version (presumably 2.95.2-9). If you install this, apt-get will be broken, and updates will not be possible until you manually install the fixed version with dpkg. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Release-critical Bugreport for March 31, 2000
Package: gap4-doc-dvi (debian/non-free) Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 60695 gap4-doc-dvi depends on nonexistent package Package: gap4-doc-html (debian/non-free) Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 60703 gap4-doc-html depends on nonexistent package Package: gap4-doc-ps (debian/non-free) Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 60699 gap4-doc-ps depends on nonexistent package I am NMU'ing these packages as I type this email. Package: gap4-gdat (debian/non-free) Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 60708 gap4-gdat depends on nonexistent package Package: gap4-tdat (debian/non-free) Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 60701 gap4-tdat depends on nonexistent package I've forwarded these two packages to the ftp masters. Since they truly do depend on gap4 being installed, they will not have their deps met for potato. Woody on the other hand... Anyhow, they should be removed. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Release-critical Bugreport for March 31, 2000
Package: gcc (debian/main) Maintainer: Debian GCC maintainers [EMAIL PROTECTED] 58412 r-base: Can't build from source 61258 missing header files in include/asm on non-i386 architectures I'v reduced the severity of these two bugs. The first has a workaround in the bug report. Since it doesn't keep r-base from compiling (just requires it to workaround the gcc bug), then it should be ok for now. The second I don't think is really a bug. More than likely it is user misunderstanding of how fixincludes work. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Release-critical Bugreport for March 31, 2000
Package: ivtools (debian/main) Maintainer: Guenter Geiger [EMAIL PROTECTED] 57250 ivtools_0.7.9-5(frozen): build errors Changelog for 0.7.9-6 says this is fixed, so I've closed it. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Release-critical Bugreport for March 31, 2000
Package: kaffe (debian/main) Maintainer: Ean R. Schuessler [EMAIL PROTECTED] 59420 kaffe_1:1.0.5e-0.3(frozen): bad register names on m68k NMU'ing this one (again) -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Release-critical Bugreport for March 31, 2000
Package: siag-common (debian/main) Maintainer: Davide Barbieri [EMAIL PROTECTED] 61174 siag-common: deps on arch any packages too strict to allow binary only recompiles Fixed version was installed last night by the maintainer. Package: silo (debian/main) Maintainer: Davide Barbieri [EMAIL PROTECTED] 61389 silo: newer version available for better cd boot support Maintianer asked me to NMU, already done and in incoming. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Release-critical Bugreport for March 31, 2000
On Fri, Mar 31, 2000 at 08:19:39PM +0200, Adrian Bunk wrote: On Fri, 31 Mar 2000, Ben Collins wrote: Package: gap4-doc-dvi (debian/non-free) Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 60695 gap4-doc-dvi depends on nonexistent package Package: gap4-doc-html (debian/non-free) Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 60703 gap4-doc-html depends on nonexistent package Package: gap4-doc-ps (debian/non-free) Maintainer: Markus Hetzmannseder [EMAIL PROTECTED] 60699 gap4-doc-ps depends on nonexistent package I am NMU'ing these packages as I type this email. ... Hi Ben, does it really make sense to keep the documentation of a program which is no longer in potato? No it doesn't. However, that is not up to me, and there is nothing in policy or packaging that makes such a statement. Therefore, that reason alone is not enough to remove it. We have documentation packages that having nothing to do with computers at all (all though I have argued against such packages). These packages do not require gap4 to be useful (to gap4 users, but still). -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Release-critical Bugreport for March 31, 2000
On Fri, Mar 31, 2000 at 11:18:36AM -0800, Ossama Othman wrote: Hi, Package: libtool (debian/main) Maintainer: Ossama Othman [EMAIL PROTECTED] 61314 libtool build hack breaks ports I'm currently away attending a conference so it's a bit hard for me to work on this. An NMU would be greatly appreciated. Otherwise, I'll do my best to get this fixed sometime this weekend. Build in progress, will be uploaded soon. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Release-critical Bugreport for March 31, 2000
On Fri, Mar 31, 2000 at 03:20:20PM -0800, Kevin Dalley wrote: BugScan reporter [EMAIL PROTECTED] writes: Package: sane (debian/main) Maintainer: Kevin Dalley [EMAIL PROTECTED] 60923 sane: Broken with Gimp 1.0 I uploaded a possible fix to this program a few days ago. The problem is that various versions of sane and xsane were not compiled with the appropriate libgimp libraries on non-i386 platforms. Which gimp libraries should they be using? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Advice on inetd Denial of Service Bug
Unfortunately I can't think of a reasonable way of checking for this in the preinst. The shell code I posted to the bug report works okay for testing, but it'll report existing connections that are perfectly reasonable, rather than just programs listening where they shouldn't be, so it's not particularly good for sticking in a preinst and randomly killing processes. It also depends on an optional package, which ain't good. Ideas? Or should I just forget it, and let people doing an upgrade look out for themselves? How about instead of killing processes, just want the user if such a situation exists using the same check? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: (Bug horizon) Problem bugs
On Thu, Mar 30, 2000 at 11:12:27AM -0800, Chip Salzenberg wrote: According to Richard Braakman: Package: gcc (debian/main). Maintainer: Debian GCC maintainers [EMAIL PROTECTED] 58412 r-base: Can't build from source 59819 gcc_2.95.2-7(frozen): fails to compile itself on m68k 61258 missing header files in include/asm on non-i386 architectures May I assume that the latter two bugs will not delay the release of potato for i386? Package: pdl (debian/main). Maintainer: Raul Miller [EMAIL PROTECTED] 55268 [Strategy: use older version on alpha] PDL fails to compile on alpha Likewise? Couldn't be more wrong. Bugs are bugs...a package with a serious bug on a supported arch, affects that package period, no matter what arch you are talking about. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: (Bug horizon) Problem bugs
On Thu, Mar 30, 2000 at 01:02:46PM -0800, Chip Salzenberg wrote: According to Ben Collins: On Thu, Mar 30, 2000 at 11:12:27AM -0800, Chip Salzenberg wrote: May I assume that the latter two bugs will not delay the release of potato for i386? Couldn't be more wrong. Bugs are bugs...a package with a serious bug on a supported arch, affects that package period, no matter what arch you are talking about. But that makes no sense ... I'm a Debian developer, but I have no access to any m68k machines. Yet potato, which includes some of my work, can't be released ... and I can do nothing about it? Feh. I don't believe you are the only one working on the problem. Also, if you looked, you would find that there are several m68k systems you can request access to, so as to troubleshoot the problem. You could also forward the bug upstream, or make a request to the respective debian-m68k list for help. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: 0 days till bug horizon
Sorry, simple reply for the sake of testing out poor mail server. Ben
