Re: Debian 2.0 CDs back in place on ftp1
Johnie Ingram writes: 620062720 Jun 3 13:30 CD0/Debian-i386-2.0-980603-1730Z.iso So main+contrib finally fits on 1 CD ? 335355904 Jun 3 11:16 CD1/Debian-misc-2.0-980603-1516Z.iso Could you give a brief description of what this misc CD is ? Thanks, -- Yann Dirson [EMAIL PROTECTED] | Stop making M$-Bill richer richer, alt-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian 2.0
On Tue, May 05, 1998 at 11:59:36AM +0200, Tobias Josefsson wrote: I was just wondering when Debian release 2.0 is going to be released... Does anyone know? Yes, I know. When it's ready :-) Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian 2.0
Andreas Jellinghaus [EMAIL PROTECTED] wrote: from a first look at debian 2.0 i'm disappointed. ok, everything is moved to glibc, and there are lots of new packages. but where is the enhancement ? If I recall correctly, the stated goals of this release where upgrade to glibc 2.0, and various package-specific enhancements. - with installing (n) dictionaries you are asked (n-1) time to select the default one. simlimiar thing with programs who can view graphik format (there are only 2 or 3 programs, but lot's of graphik formats). On my machines, I've dealt with the graphic format issue by eliminating the read (so it always accepts the default). Not pretty, but given the current setup the question is largely meaningless anyways. - windowmanmagers. what about nice looking default configurations ? Define nice looking? [I'm not saying you're wrong, I'm saying that I don't know how to address this one. I consider enlightenment to be nice looking, for example, but I'm also happy with 9wm.] - pam login doesn't use pam. passwd doesn't use pam. telnet doesn't use it. unless most programs are unseing pam, it's useless. Not good. [Sounds like a significant bug, too.] - the default setting isn't very useable. ok, my reference is the new student which heard of linux, and want's to install it side by side with win*. maybe it's useable for sysadmins. but sysadmins can help themself, newbies not. so a config should be fool proof ... I'm not sure what you mean here. - most programs try a whole configuration in postinst method. this is doesn't work in many cases : it's good for the sysadmin. but often a newbie has a problem, and someone sais try xxx. so he installs xxx. but he can't config xxx, first he needs to read the README's and manual, and then he can configure it. even with nice config help, he first needs to read the manuals. maybe xxx doesnt solve his problem at all. or he only needs parts. cvs is an example : many people neither have a local cvsroot, nor are they running a pserver. I think (hope) that as apt gets deployed a lot of this will thrash out. - sure, we know that dselect is not user friendly, but what is with all other places ? one example : asking do you want to make this the default windowmanager is not a good solution, nor is a new windowmanager will become (not) the default wm. the solution has two parts : a) documentation quick start - how to select your wm and b) windowmanager-config (i guess less that 15 lines of bash/dialog will do the job). yes, debian has a lot of good features. but debian has several weak points, and these seem to be exactly the same points already present in bo. this worries me. There are several weaknesses: (1) some improvements require coordinated efforts across multiple packages. (2) the release management problem we're trying to tackle is huge (and at some point we just have to punt, unfortunately). (3) Issues of taste vary from person to person. (4) To some degree, we're not a development effort, but a package management and adminstration effort. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian 2.0
Raul Miller [EMAIL PROTECTED] writes:
- pam login doesn't use pam. passwd doesn't use pam. telnet doesn't use it.
unless most programs are unseing pam, it's useless.
Oh, foo. Integration of pam was dropped as a release goal of 2.0
because it is quite simply not tenable if you want to release hamm
before 1999. You can not simply recompile core applications like
shadow and net{base,std} with pam and hope they work, especially not
a month+ into freeze.
Not good. [Sounds like a significant bug, too.]
The non-use of pam is not a significant bug and I have no idea what
makes you think it is.
--
James
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian 2.0
James Troup [EMAIL PROTECTED] wrote:
Oh, foo. Integration of pam was dropped as a release goal of 2.0
because it is quite simply not tenable if you want to release hamm
before 1999. You can not simply recompile core applications like
shadow and net{base,std} with pam and hope they work, especially not
a month+ into freeze.
I didn't realize that pam was this unstable. [As in: it's been around
for a while, and I didn't realize the decision had been made this
recently.]
Raul Miller [EMAIL PROTECTED] writes:
Not good. [Sounds like a significant bug, too.]
The non-use of pam is not a significant bug and I have no idea what
makes you think it is.
It's a bug in debian's pam support, because it is a lack of pam
support.
Seems like it would be viable to create a netbase-pam, setstd-pam,
login-pam, etc. and put them somewhere (experimental, slink/extra, ...).
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian 2.0
Raul Miller [EMAIL PROTECTED] writes:
Oh, foo. Integration of pam was dropped as a release goal of 2.0
because it is quite simply not tenable if you want to release hamm
before 1999. You can not simply recompile core applications like
shadow and net{base,std} with pam and hope they work, especially
not a month+ into freeze.
I didn't realize that pam was this unstable.
I never said it was unstable and it isn't. But we haven't used it
before and I don't care how stable it is, we should not and will not
start recompiling core applications with a previously unused (*in
Debian*) library, one month into a freeze. The decision to postpone
PAM integration till 2.1 was made a long time ago (see the list
archives).
--
James
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian 2.0
James Troup [EMAIL PROTECTED] wrote: I never said it was unstable and it isn't. But we haven't used it before and I don't care how stable it is, we should not and will not start recompiling core applications with a previously unused (*in Debian*) library, one month into a freeze. The decision to postpone PAM integration till 2.1 was made a long time ago (see the list archives). You're saying we shouldn't re-make that decision now. I guess that's fine. You're saying that when the decisions was made (a long time ago) it was the right decision. I guess that's fine, too. However, I'm surprised that so much time had passed without anyone re-examining the decision. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian 2.0 release requirements
Richard == Richard Braakman [EMAIL PROTECTED] writes: Shared libraries are linked dynamically against other libraries Linking shared libraries dynamically against other libraries simplifies the upgrading process and saves disk and memory space. All shared libraries included in the Debian distribution will be compiled that way. [...] As far as I can tell, it does not save disk and memory space. However, I am rather new at this. Feel free to correct me. You are wrong. Shared libraries are able to use copy-on-write memory space (hence the 'shared' category when you type 'free') which can radically lower RAM requirements. This is not the case on statically linked libraries. And, clearly, it saves disk space since the code resides on the disk in only one place instead of being part of the executable. (Little confused on how you could get confused on this one!) The final, and most important rationale is that bug fixes, say, in libc, can be applied in one place and all programs which statically link against the same major libc version are able to reap the benefits of that bug fix. .A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Sat, 10 Jan 1998, Adam P. Harris wrote: Richard == Richard Braakman [EMAIL PROTECTED] writes: Shared libraries are linked dynamically against other libraries Linking shared libraries dynamically against other libraries simplifies the upgrading process and saves disk and memory space. All shared libraries included in the Debian distribution will be compiled that way. [...] As far as I can tell, it does not save disk and memory space. However, I am rather new at this. Feel free to correct me. You are wrong. Shared libraries are able to use copy-on-write memory space (hence the 'shared' category when you type 'free') which can radically lower RAM requirements. This is not the case on statically linked libraries. And, clearly, it saves disk space since the code resides on the disk in only one place instead of being part of the executable. (Little confused on how you could get confused on this one!) The final, and most important rationale is that bug fixes, say, in libc, can be applied in one place and all programs which statically link against the same major libc version are able to reap the benefits of that bug fix. Please note, that we are not talking about `dynamically linked binaries' (which has been implemented a long time ago) but about `shared libraries being linked dynamically against other libraries', that is, if you, say, build the libmysql.so shared library, this requires linked against libc of course, which can be done either statically (libc code is included in libmysql.so too) or dynamically. (Is all this correct? I'm not a shared library expert.) Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- DIE ENTE BLEIBT DRAUSSEN! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
[EMAIL PROTECTED] (Alex Yukhimets) wrote on 09.01.98 in [EMAIL PROTECTED]: Moin Alex! AY I would like to question the need for this requirement. ??? Aren't you questioning my right to do that? :) No, but it hardly seems reasonable to question this requirement. AY While this can be of importance to some users, it can be quite AY annoying to others. ??? Please remember, a lot of languages need 8 bit clean programs. Non 8 bit clean programs are very bad. True. Many users need support for the language other than English. Some of that users need 8-bit clean programs AND still some additional customization. Some languages even have many optionas as to customization. (Take Russian - several possible encodings AND keyboard layouts). For some languages it is even not enough to have 8-bit clean programs. So? All this says that we need 8-bit-clean software. You can't satisfy all users anyway. In addition, I would hate to be able to switch to russian keyboard mode (by mistake) and enter some letters which look just like English ones in the editor I use for _programming_. OTOH, many people'd be upset not to be able to insert comments using those russian letters. And they'd be right. AY What it means is saying good-bye to clean AY ascii e-mail, etc. ??? Yes. I don't like when I see 8-bit charachters. In my non-internationalized configuration they look like F23 highlighted (or something like that). So? So what you really don't like is non-8-bit-clean software. That's the one that displays F23. AY What is more important, *some* utilities, AY less most notably, *shouldn't* be 8-bit clean. Why? I would like to see German Umlaute. Sure, but I would like to be able to do less binary file safely. (more is not safe for this). Guess what? I can see those umlauts in less, and I can also safely do less binary file. I get the impression that 8 bit clean doesn't mean what you think it means. Finally, the only thing I am trying to tell is that it is probaly not very wise to put as a requirement for *every* package to be 8-bit clean. (Note my point with the editor used for programming). I would Actually, I think it would be very unwise not to, and you actually gave no good reason to believe otherwise. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
You can't satisfy all users anyway. In addition, I would hate to be able to switch to russian keyboard mode (by mistake) and enter some letters which look just like English ones in the editor I use for _programming_. OTOH, many people'd be upset not to be able to insert comments using those russian letters. And they'd be right. OK. Many people would be upset not to be able, many would be upset to be able. Why do you think ignoring them should be in the policy? Sure I can recompile my favorite editor myself. But what's the point in having binary distribution then? What I'm saying is that ignoring the preferences of many users should not be the policy. Providing alternatively configured packages (where necessary) would be a solution. Yes. I don't like when I see 8-bit charachters. In my non-internationalized configuration they look like F23 highlighted (or something like that). So? So what you really don't like is non-8-bit-clean software. That's the one that displays F23. Yes, but if I sent you a message containing some russian leters you wouldn't see them the way I see anyway. The same thing for every other language. 8-bit clean e-mail message is not the one to send to international mailing list. But this is off-topic. Sure, but I would like to be able to do less binary file safely. (more is not safe for this). Guess what? I can see those umlauts in less, and I can also safely do less binary file. Great. I am already persuaded that I was wrong about less. Thanks. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Sat, 10 Jan 1998, Christian Schwarz wrote: Please note, that we are not talking about `dynamically linked binaries' (which has been implemented a long time ago) but about `shared libraries being linked dynamically against other libraries', that is, if you, say, build the libmysql.so shared library, this requires linked against libc of course, which can be done either statically (libc code is included in libmysql.so too) or dynamically. I dont know why it should be like that. AFAIK there is no need to include any libc code in the library either statically or dynamically, the program which is linked to the library will be linked to libc anyway, so there wont be any missing symbols. The dynamic linking against libc in this case helps ldso to find the correct libraries to link against the program. ( program bar linked to libfoo.so and libc.so.6, there is one libfoo.so which is linked to libc.so.5 and one which is linked to libc.so.6 ldso can choose the correct one. Greg -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
Adam P. Harris wrote: Richard == Richard Braakman [EMAIL PROTECTED] writes: [linking shared libraries against other libraries] As far as I can tell, it does not save disk and memory space. However, I am rather new at this. Feel free to correct me. You are wrong. Shared libraries are able to use copy-on-write memory space (hence the 'shared' category when you type 'free') which can radically lower RAM requirements. This is not the case on statically linked libraries. I think there is a confusion of terms here. This is not about linking shared vs. static. But it's easy to get that idea, because when ldd is run on a library that is not linked with anything else, you get: % ldd /usr/lib/libdpkg.so.0.0 statically linked But this is not true! libdpkg does not include code from any other library. Symbols like sprintf are left unresolved. Any program that is dynamically linked with libdpkg must also be dynamically linked with a libc that provides these symbols, so that they can be resolved at program startup time. This is described in ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz particularly section 5.4. If libdpkg were compiled with -lc, then the soname of the libc it was linked with (i.e. libc.so.6) would be listed in its dynamic dependencies. This means that when the dynamic linker links in libdpkg, it also links in libc.so.6. Thus, you can't accidentally combine libdpkg with the wrong libc version. (gcc adds -lc by default when compiling a program, but not when compiling a shared library.) So you see, the code is shared either way. The point of this release goal is to put explicit dependency information in the shared libraries. Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
-BEGIN PGP SIGNED MESSAGE- On Sat, 10 Jan 1998, Alex Yukhimets wrote: Yes, but if I sent you a message containing some russian leters you wouldn't see them the way I see anyway. The same thing for every other language. 8-bit clean e-mail message is not the one to send to international mailing list. But this is off-topic. Alex, this is much simpler than you think. I will give you a simple example: My keyboard has a key for the \~n letter (using TeX notation) which is used in the Spanish language. When I press that key, I *expect* to produce such character. Not obtaining that letter but some other is completely annoying for me. It is as if I pressed t and obtained y. Completely unnaceptable. Since you don't have such key in your keyboard, you have nothing to worry about, but even if you would have that key in your keyboard, and you don't want to produce such character, just don't press that key! Where is the problem? I don't see any problem at all! Great. I am already persuaded that I was wrong about less. Ok. Please, tell me another example of a program that should not allow 8-bit input (and output) by default. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNLfNvCqK7IlOjMLFAQENUgQAs9yOZLYfL0ywHs8RhO8DeZyvOFE4d7dz ffhFvUF/TLgLi3A8HkV5OmkuadLZrFLCHQgj1/42+rwlDCd6HBBnnaY78z1PWssp 8ppp5OYKkuJ0x+TqZHGdg/tihlYp1n3UrIeor6kuXQ6Fa+lO5uYaviDMg/KEhoYR LfmaYORFtpk= =oMaI -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
Alex, this is much simpler than you think. I will give you a simple example: My keyboard has a key for the \~n letter (using TeX notation) which is used in the Spanish language. When I press that key, I *expect* to produce such character. Not obtaining that letter but some other is completely annoying for me. It is as if I pressed t and obtained y. Completely unnaceptable. Since you don't have such key in your keyboard, you have nothing to worry about, but even if you would have that key in your keyboard, and you don't want to produce such character, just don't press that key! Where is the problem? I don't see any problem at all! Great. I am already persuaded that I was wrong about less. Ok. Please, tell me another example of a program that should not allow 8-bit input (and output) by default. Hi. I already gave an example in my other posts - the text editor I use for programming. When you press \~n (unintentionally I would suppose) while it is 8-bit clean you will get an error from the compiler, interpreter, etc. OR (depending on the implementation of the compiler) introduce a hidden bug. Lucky you, you can easily visually distinguish plain 'n' and \~n on the screen. I am not that lucky, since I am using cyrillic alphabet where ALL letters use non-ascii codes but _most_ of them look exactly like English ones. (Of course, I don't have special keys for them. I use some key sequence to switch between ASCII and cyrillic modes - this sequence can easily be pressed unintentionally). As a result I will be getting VERY annoying mistakes, which could be simply avoided by having only 7-bit clean editor. The fact is that I would recompile the editor myself to avoid what I just described. Thanks. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
Dale Scheetz wrote: This one is new to me...I have been waiting for the menu system to stabalize. I guess this means that it has? There have been no changes to the menu package since Oct 1997. There are several open bug reports, but these will hopefully be fixed now that Joost is less busy. It's very stable, featureful, and ready. Is there a description in the Policy Manual? See section 3.7 of the policy manual. More important is there a good example of how to impliment this and will it make it into the Programmers Manual? /usr/doc/menu/html/ describes everything you need to know. I think it's too long (800 lines) to go into the programmer's manual. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Wed, 7 Jan 1998, Dale Scheetz wrote: On Wed, 7 Jan 1998, Christian Schwarz wrote: All applications registered to menus The menu package included in the Debian distribution stores information about which applications are installed on the system and provides this data for X11 window managers or text-based menu programs like pdmenu. With that, the user always has up-to-date application menus, no matter which packages are installed or which menu program is used. This one is new to me...I have been waiting for the menu system to stabalize. I guess this means that it has? Is there a description in the Policy Manual? More important is there a good example of how to impliment this and will it make it into the Programmers Manual? It's already policy. Check out section 3.7 of policy 2.3.0.1. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
Attention all package maintainers: Just a note that the testing group would like to have an idea of how to test the individual packages (before we were only seeing if it would install). All we are asking for is a checklist (and a script if you want), which in the most general sense says: this program should do this, that program should do that. Please send them to my email, with the subject Checklist request (so I can sort them out). If you've missed the previous messages about this, just drop me a line and I'll give you the full details and an example. Thanks, Brandon - Brandon Mitchell [EMAIL PROTECTED] We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Wed, 7 Jan 1998, Alex Yukhimets wrote: it is nice property of less (as opposed to more) that it filters out all non-ascii charachters (changes them to some ^... printable sequencies). As a result, it is not possible to trash the console by doing less some binary file or, more important - if something bad happened and you created a file(s) with some non-ascii charachters, ls will trash the console while ls | less will show you everything and let you delete it. I think that LESSCHARSET=latin1 as default wouldn't trash your console and it would show most of what it should show ... -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Thu, Jan 08, 1998 at 01:21:41AM +0100, Christian Schwarz wrote: On Wed, 7 Jan 1998, Christian Schwarz wrote: All applications registered to menus It's already policy. Check out section 3.7 of policy 2.3.0.1. Could applications be spelt out a bit more? Clearly menu entries are only useful for interactive tools. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Wed, 7 Jan 1998 [EMAIL PROTECTED] wrote: Just a note that the testing group would like to have an idea of how to test the individual packages (before we were only seeing if it would install). All we are asking for is a checklist (and a script if you want), which in the most general sense says: this program should do this, that program should do that. Please send them to my email, with the subject Checklist request (so I can sort them out). If you've missed the previous messages about this, just drop me a line and I'll give you the full details and an example. If such scripts are written, I suggest they are run from debian/rules at package build time. (some packages already do this (some perl modules for example)) This way, testers will be able to focus their attention on things that can NOT be done automatically... -- - Vincent RENARDIAS [EMAIL PROTECTED],pipo.com,debian.org} - - Debian/GNU Linux: Pipo:WAW: - - http://www.fr.debian.orghttp://www.pipo.com http://www.waw.com - --- - La fonctionnalite Son Visuel vous delivre des avertissements visuels. - - [Message durant l'installation de Windows95] :wq -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
Shared libraries are linked dynamically against other libraries Linking shared libraries dynamically against other libraries simplifies the upgrading process and saves disk and memory space. All shared libraries included in the Debian distribution will be compiled that way. See H.J. Lu's `ELF: From The Programmer's Perspective' for details. I don't think the rationale is correct. H.J. Lu's paper makes it clear that the point of linking a library this way is to tell the dynamic linker which other libraries are used by this library. It does not change the way the library is compiled. Linking shared libraries against the libraries they use has three advantages: - It allows the dynamic linker to give warnings when incompatible libraries are mixed. - When compiling a program, the linker can automatically link in the extra libraries that are used by the libraries that were specified on the command line. (Thus, you can link with tk without explicitly adding -ldl and -lm). - It gives dpkg-shlibdeps enough information to generate the correct dependency information for a package that contains shared libraries. As far as I can tell, it does not save disk and memory space. However, I am rather new at this. Feel free to correct me. All binaries in ELF format (no a.out binaries) Though, ELF has been Debian's default binary format for few releases now, a.out development packages have still been provided. As a.out binaries have become rare lately, the development tools for this binary format has been dropped. However, run-time support for a.out binaries is still available. If we have no a.out development tools, how will we compile the runtime support for a.out? The runtime support packages would have to go into contrib. Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Thu, 8 Jan 1998, Vincent Renardias wrote: On Wed, 7 Jan 1998 [EMAIL PROTECTED] wrote: Just a note that the testing group would like to have an idea of how to test the individual packages (before we were only seeing if it would install). All we are asking for is a checklist (and a script if you want), which in the most general sense says: this program should do this, that program should do that. Please send them to my email, with the subject Checklist request (so I can sort them out). If you've missed the previous messages about this, just drop me a line and I'll give you the full details and an example. If such scripts are written, I suggest they are run from debian/rules at package build time. (some packages already do this (some perl modules for example)) This way, testers will be able to focus their attention on things that can NOT be done automatically... A request similar to this was already made, and decided against. I don't expect the maintainer the build the package on multiple setups, which is what we are testing. Also, if there is not easy access to the scripts, they will not be used by the testers (we don't have the time to download the sources and binaries for all these packages). The testers are urged, but not required, to consider the scripts as templates, or rough ideas, of how to set up their own scripts (therefore we get some individual test). Final note, the scripts are _optional_. It took a bit of convincing to get me to agree with that part of the idea. But I think there can be benifits over the checklist only aproach. I'm hoping this will be easier to understand once I get things organized and start posting periodic updates and put up the web site. If you have any other questions, feel free to ask, Brandon - Brandon Mitchell [EMAIL PROTECTED] We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Thu, 8 Jan 1998, Gergely Madarasz wrote: On Wed, 7 Jan 1998, Alex Yukhimets wrote: it is nice property of less (as opposed to more) that it filters out all non-ascii charachters (changes them to some ^... printable sequencies). As a result, it is not possible to trash the console by doing less some binary file or, more important - if something bad happened and you created a file(s) with some non-ascii charachters, ls will trash the console while ls | less will show you everything and let you delete it. I think that LESSCHARSET=latin1 as default wouldn't trash your console and it would show most of what it should show ... AFAIK, less already is 8-bit aware, no changes needed. So Alex, don't worry about that. -- Enrique Zanardi[EMAIL PROTECTED] Dpto. Fisica Fundamental y Experimental Univ. de La Laguna -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
-BEGIN PGP SIGNED MESSAGE-
On Wed, 7 Jan 1998, Alex Yukhimets wrote:
it is nice property of less (as opposed to more) that it filters
out all non-ascii charachters (changes them to some ^... printable
sequencies). As a result, it is not possible to trash the console by
doing less some binary file or, more important - if something
bad happened and you created a file(s) with some non-ascii charachters,
ls will trash the console while ls | less will show you everything
and let you delete it.
I think there is a misunderstanding here:
non-ascii is not the same as non-printable.
At least in iso-8859-1, characters from 160 to 255 *are* printable, and
should *not* be escaped in any way, or else nobody will be able to see
\begin{TeX}
Espa\~na
\end{TeX}
properly (i.e. España in iso-8859-1).
These characters are also printable with the default font, but obviously
you will not see the letter (TeX \~n) or accented letters, but IBM-PC
graphics instead.
You may trash the console by printing characters from 128 to 159, but in
general these are *not* printable, so I don't think anything bad will
happen if we are 8-bit clean at least *for characters between 160 and 255*.
Thanks.
p.s. I don't remember ever having trashed the console by using less.
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
iQCVAgUBNLS++CqK7IlOjMLFAQFa7AQAkhicyTKplgnqR9bkF1UhciWQohzP7N4r
RwyZZAtoApAsmTjaEGZIkNKqfPAtd8hjaWjz4iiWt+oFizdVP8XMoE2TLAHjH99K
RNEeVQIBrcw1vACo/7UsLqd0vRqghUwZujx8OKSjmaYiqmo9OLObUolsxAkq877p
lV9iNgJTSfI=
=MPjr
-END PGP SIGNATURE-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
Alex Yukhimets writes: if something bad happened and you created a file(s) with some non-ascii charachters, ls will trash the console while ls | less will show you everything and let you delete it. ?? Why on earth do you need less for that ? Doesn't LANG=C /bin/ls -b do the right job for that ? -- Yann Dirson [EMAIL PROTECTED] | Stop making M$-Bill richer richer, alt-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check http://www.debian.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
In article [EMAIL PROTECTED], Yann Dirson [EMAIL PROTECTED] wrote: Alex Yukhimets writes: if something bad happened and you created a file(s) with some non-ascii charachters, ls will trash the console while ls | less will show you everything and let you delete it. ?? Why on earth do you need less for that ? Doesn't LANG=C /bin/ls -b do the right job for that ? Besides, you can configure less so that it uses the latin-1 character set which is a superset of ASCII. Almost all terminals (certainly the Linux console, xterm and rxvt) support that by default. Characters not in that set will be shown as escaped control characters. It's nice to be able to see Á Å Ï ïáî etc by default. Mike. -- Miquel van Smoorenburg | The dyslexic, agnostic, insomniac lay in his bed [EMAIL PROTECTED] | awake all night wondering if there is a doG -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
Support of 8-bit characters by default Some programs need special configuration options to work 8-bit clean. This is very important for a lot of non-English users who need to input umlauts, accented characters, etc. All Debian packages will be configured to be 8-bit clean by default. Hi. I would like to question the need for this requirement. While this can be of importance to some users, it can be quite annoying to others. What it means is saying good-bye to clean ascii e-mail, etc. What is more important, *some* utilities, less most notably, *shouldn't* be 8-bit clean. I think we should put a little bit more thought into this decision. Not *all* packages should be 8-bit clean in any case, and for some others, I would still prefer to have some options. Thanks. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Wed, Jan 07, 1998 at 06:27:48PM -0500, Alex Yukhimets wrote: Support of 8-bit characters by default Some programs need special configuration options to work 8-bit clean. This is very important for a lot of non-English users who need to input umlauts, accented characters, etc. All Debian packages will be configured to be 8-bit clean by default. Hi. I would like to question the need for this requirement. While this can be of importance to some users, it can be quite annoying to others. What it means is saying good-bye to clean ascii e-mail, etc. What is more important, *some* utilities, less most notably, *shouldn't* be 8-bit clean. I don't understand that. Could you explain that? Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / Whenever you meet yourself you're in a time loop / / http://home.pages.de/~joey/ or in front of a mirror / -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
Support of 8-bit characters by default Some programs need special configuration options to work 8-bit clean. This is very important for a lot of non-English users who need to input umlauts, accented characters, etc. All Debian packages will be configured to be 8-bit clean by default. Hi. I would like to question the need for this requirement. While this can be of importance to some users, it can be quite annoying to others. What it means is saying good-bye to clean ascii e-mail, etc. What is more important, *some* utilities, less most notably, *shouldn't* be 8-bit clean. I don't understand that. Could you explain that? Sure. it is nice property of less (as opposed to more) that it filters out all non-ascii charachters (changes them to some ^... printable sequencies). As a result, it is not possible to trash the console by doing less some binary file or, more important - if something bad happened and you created a file(s) with some non-ascii charachters, ls will trash the console while ls | less will show you everything and let you delete it. Thanks. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Wed, 7 Jan 1998, Christian Schwarz wrote: All applications registered to menus The menu package included in the Debian distribution stores information about which applications are installed on the system and provides this data for X11 window managers or text-based menu programs like pdmenu. With that, the user always has up-to-date application menus, no matter which packages are installed or which menu program is used. This one is new to me...I have been waiting for the menu system to stabalize. I guess this means that it has? Is there a description in the Policy Manual? More important is there a good example of how to impliment this and will it make it into the Programmers Manual? Thanks, Dwarf -- _-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debian 2.0 - any dates?
Boris D. Beletsky [EMAIL PROTECTED] writes: Gee, I dunno, maybe it's, at least in part, for the developers who still haven't upgraded their packages to libc6, despite it being available since April. It will be available in the next few days, Like Jed was going to be done this weekend several weeks ago? come on, you are not waiting for me and not for others who didn't convert the packages to libc6, all the essentials are converted. Oh really? What about such inessentials and trivialities such as our default MTA? And if there was a deadline for me to convert my packages I would of made it. Ah of course; it's our fault for not setting a deadline. Silly me. I don't have a problem with people who don't have time to deal with their packages properly; I do however have a problem with those same people asking questions like What are we waiting for? -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debian 2.0 - any dates?
On Thu, Jan 01, 1998 at 05:10:09PM +, James Troup wrote: Oh really? What about such inessentials and trivialities such as our default MTA? Well... Please take a look at ftp://ftp.infodrom.north.de/pub/people/soenke/debian-beta/ and test the smail inside. And if there was a deadline for me to convert my packages I would of made it. Ah of course; it's our fault for not setting a deadline. Silly me. I don't think a deadline is that good. Make a list of things-to-do before release and increase the power maintainers have into these packages. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / /Erfahrung ist eine nützliche Sache / / Leider macht man sie immer erst kurz nachdem man sie brauchte / pgp0mfc3P4rtz.pgp Description: PGP signature
Re: debian 2.0 - any dates?
Martin Schulze [EMAIL PROTECTED] writes: Oh really? What about such inessentials and trivialities such as our default MTA? Well... Please take a look at ftp://ftp.infodrom.north.de/pub/people/soenke/debian-beta/ and test the smail inside. Wouldn't that be better tested if it were uploaded to unstable? -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debian 2.0 - any dates?
On Thu, Jan 01, 1998 at 05:58:30PM +, James Troup wrote: Oh really? What about such inessentials and trivialities such as our default MTA? Well... Please take a look at ftp://ftp.infodrom.north.de/pub/people/soenke/debian-beta/ and test the smail inside. Wouldn't that be better tested if it were uploaded to unstable? Don't tell me. :-) Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / /Erfahrung ist eine nützliche Sache / / Leider macht man sie immer erst kurz nachdem man sie brauchte / pgp7n8hrScjQC.pgp Description: PGP signature
Re: debian 2.0 - any dates?
Am 31.12.97 schrieb borik # isracom.net.il ... Moin Boris! BDB Do we have any dates for Debian 2.0 BDB release/code-freze/dead-line/anything? No. BDB If not, shouldn't we schedule one already. What are we waiting for? Are really good question. We should hurry a litte bit. cu, Marco -- Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debian 2.0 - any dates?
What's going on is that we will have an alpha-testable system by the weekend with any luck, and we can then set deadlines. Bruce -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debian 2.0 - any dates?
Boris D. Beletsky [EMAIL PROTECTED] writes: If not, shouldn't we schedule one already. What are we waiting for? Gee, I dunno, maybe it's, at least in part, for the developers who still haven't upgraded their packages to libc6, despite it being available since April. -- James - xinted anyone? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debian 2.0 - any dates?
On 31 Dec 1997, James Troup wrote: Troup Boris D. Beletsky [EMAIL PROTECTED] writes: Troup Troup If not, shouldn't we schedule one already. What are we Troup waiting for? Troup Troup Gee, I dunno, maybe it's, at least in part, for the developers Troup who still haven't upgraded their packages to libc6, despite it Troup being available since April. It will be available in the next few days, come on, you are not waiting for me and not for others who didn't convert the packages to libc6, all the essentials are converted. I am asking for the real reason. And if there was a deadline for me to convert my packages I would of made it. thks, borik __ Boris D. Beletsky [EMAIL PROTECTED] Network Administrator [EMAIL PROTECTED] Berger Financial Research, [EMAIL PROTECTED] IBM Building Home: +972 2 6411880 Tel-Aviv IsraelWork: +972 3 6944218 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
