Re: realplayer installer and frozen
On Tue, Mar 14, 2000 at 07:09:31PM -0800, Joey Hess wrote: Lars Wirzenius wrote: I agree with Branden: remove the installer from potato. The problem that I forgot to mention is that anyone who upgrades from slink to potato w/o upgrading realplayer, and had realplayer installed via the installer in slink, is going to find that the old realplayer they have installed realplayer no longer works. Library incompatabilities of some kind cause it to crash. I would definitely put new realplayer installer package in potato. At least this would be a big favor to our users. Thanks, Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+
Re: So, what's up with the XFree86 4.0 .debs?
On Sun, Mar 12, 2000 at 10:47:51PM -0500, Branden Robinson wrote: You are going to keep /usr/X11R6 for this release right? I guess that the XFree86 people might get a bit irritated if you tried to drop it. Actually, I've evilly been toying with the idea of #defining ProjectRoot to /usr for 4.0. Upstream has already moved almost entirely to the way Debian currently does things as far as filesystem layout goes. Branden, _please_ don't do it. It will be utterely confusing to find everything in a new place. As a person who does X development writing -I/usr/X11R6/include is an idiom. So as for many people. /usr itself is cluttered more then enough. X is a very complicated system and knowing what exactly is X and what is not is a great benefit - and having everything under /usr/X11R6 gives everyone that benefit. I already trained my fingers to go to /usr/X11R6/lib/X11 for a keyboard codes, some server docs, etc. Commercical packages I use assume existence of /usr/X11R6/lib/X11/app-defaults (not to mention /usr/X11R6/include and /usr/X11R6/lib). Yes, symlinking would help, but why I should go to /usr/X11R6/lib, do ls and instead of one-screen listing see an enormous number of entries from /usr/lib?? I remember that me being against something actually serves to you as an endorsements to do it, but I somehow I am still not up to the task of using reverse psychology :) Best, Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+
Re: So, what's up with the XFree86 4.0 .debs?
On Tue, Mar 14, 2000 at 08:20:48AM +1100, Hamish Moffatt wrote: On Mon, Mar 13, 2000 at 09:59:20AM -0500, Alex Yukhimets wrote: _please_ don't do it. It will be utterely confusing to find everything in a new place. As a person who does X development writing -I/usr/X11R6/include is an idiom. So as for many people. /usr itself is cluttered more then enough. You can still write -I/usr/X11R6/include, it doesn't matter if it's not used. I say go for it. /usr/X11R6 sticks out like a sore thumb. Yeah, I can write, but what is the effect of that? I often find myself in the position when I use X libraries (Xt mostly) built by myself with some changes to allow debugging of my Xt widgets. I install new libs and headers in another directory and -I/this/new/dir and -L/that/new/dir allows for compilation and linkage with new version. If libs are in /usr/lib and headers in /usr/include (default locations) then this would not work. I just don't understand why you should make my life (of the programmer) more difficult with no benefits whatsoever? (Well, some think that there is an aestetic benefit which I just can't see - if you pile up everything in /usr/lib - what's so good about it? It is like refusing to make subdirectories in your home dir and have a total mess in it.) X is a very important, I would even say unique package, - it deserves different treatment after all. There is no other software package with even close complexity and size. Luck, Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+
Re: Warnings when linking with gtk
I use the minimal Makefile: CFLAGS=-O2 -g -I/usr/lib/glib/include/ LDFLAGS=-L/usr/X11R6/lib -lX11 -lglib -lgdk -lgtk -lm and get an (apparently) working program but the warnings: ld: warning: libc.so.5, needed by /usr/lib/libc5-compat/libXi.so.6, may conflict with libc.so.6 /lib/libc.so.5: the `Getwd' function is dangerous and should not be used. /lib/libc.so.5: the `Gets' function is dangerous and should not be used. /lib/libc.so.5: warning: `Siggetmask' is obsolete; `Sigprocmask' is best Well, there are a couple of issues here. First, your linker line is a bit messed up. Not all of the necessary libraries are present and worst of all, not in correct order. While compiling with GTK I would recommend using the following: CFLAGS = Your local flags, like -O2 -g `gtk-congig --cflags` LDFLAGS= your local flags, if any (*) `gtk-config --libs` (*) (In case you want to link with some other library, in addition to GTK, like electric-fence or whatever.) Also, check that libc5-compat entries are at the very end of /etc/ld.so.conf file. Good luck. ALex Y -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linking problem
if i replace -lXpm by /usr/X11R6/lib/libXpm.so.4 the program links fine. does anybody have any idea what's going on here? ld only looks for libXpm.so, not for libXpm.so.version. In Debian, libfoo.so is part of the libfoo-dev package, not of the libfoo package, as you need the header files (which are in libfoo-dev) to compile programs using libfoo. So it looks like you don't have xpm4g-dev installed. Ray, I also had a very similar problem with -lXt, the only difference is that I used altgcc for compilation. Btw, what is the prefered way to use it? I installed xlib6g, xlib6g-dev, xlib6, altgcc, libc5-altdev packages and put in Makefile the following CC = /usr/i486-linuxlibc1/bin/gcc LDFLAGS = -L/usr/lib/libc5-compat/ LIBS = -lXt -lXext -lX11 and the line: $(CC) -o bla *.o $(LDFLAGS) $(LIBS) gives me the same error: can't load -lXt library... Thanks. Alex Y. -- _ _( )_ ( (o___ +---+ | _ 7 |Alexander Yukhimets| \()| http://pages.nyu.edu/~aqy6633/ | / \ \ +---+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re^2: Debian 2.0 release requirements
Moin Alex! AY I would like to question the need for this requirement. ??? Aren't you questioning my right to do that? :) 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. 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_. 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? (PLEASE, no flames for *this* - I also don't like very much PGP signatures as MIME attachements) 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). 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 suggest to use individual approach and have options for the user to choose whenever possible. 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
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
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
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
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: non-hub 10baseT connections
Thomas Lakofski wrote: You'd be surprised... I described a cross cable to a friend of mine, and told him that he'd have to go and get one made up or get some tools. He mailed me back 5 minutes later to tell me that he'd got it working. I asked him how, he said he'd pried the cable apart, done the cross (he'd never seen ethernet before, and yet he got it right), and then used duct tape to 'secure' the cable back in the cable end. It worked, and it still does. OK, then, which two wires need crossing? Check out ETHERNET-HOWTO for very detailed instructions. 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: Motif Software
It looks like you already have motif, right? In this case I would recommend using all packages dynamicaly linked with Motif (like ddd-dmotif, etc.) from contrib/ *and* hamm/contrib/. Since Motif is not available for libc6 (glibc2) yet, all Motif packages, even from unstable tree should be libc5- linked and therefore suitable for Debian 1.3.1. You actually can try something like xacc, nice personal accounting application (don't think it is available as Debian package). Motif linkage of vim (text editor) makes it look much nicer in X, etc. Some mail user agent programs for X use Motif. Good luck. Alex Y. P.S. If you got Motif 1.2 (not 2.0), then you are even in better luck, you could use dynamically linked Netscape. -- _ _( )_ ( (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: Moving topics from debian-private (was Re: SPI money out)
On 18 Dec 1997, Kai Henningsen wrote: Remember there are people that can't stand Emacs. Strange... :) Nothing strange. After a couple of _years_ of struggling in attempts to learn emacs (I made about 6 attempts total) I found a *great* relief in... vi (vim actually). I was able to get used to it only after 2-nd attempt. And now, when vim-5.0 supports syntax highlighting, I am more then satisfied with it. 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: ppp's ip-{up,down} and possible utilization of 'run-parts'
And there is one thing which I would qualify as a mistake in the above description: $2 is actually in the form /dev/ttyS1 than just ttyS1. Doh! I wish they wouldn't do that. I guess it's for some kinda security? ...A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/ Well, as it was already pointed out by someone, $2 is in exactly the same form as the option passed to pppd. (Un)fortunately, pppd is flexible enough to accept port in both /dev/ttyS1 and plain ttyS1 forms. As a result, $2 can also be in one of the above two forms. The solution would be to detect in ip-up (and ip-down) which one is used and convert it to ttyS1 form. 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: Moving topics from debian-private (was Re: SPI money out)
Please let noone think that just because that absurd and awful suggestion was the last thing anyone said that everyone is happy with it. Rather, the rest of us have more important things to do than to fight battles with people with broken mailers and broken ideas about how mailers ought to work. The list configuration should be left the way it is. Ian. Ian, it is not that I want to change the mailing list headers at all cost or whatever, but could you please give some explanaion why you think this way? 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: ppp's ip-{up,down} and possible utilization of 'run-parts'
FWIW I've been using run-parts in ip-up and ip-down for some time now, the scripts reconfigure stuff based on my ip address (2 ISPs) etc. and everything works like a charm. I dunno about packages placing scripts in ip-[up|down].d/ -- I'd rather put them in /usr/doc/package/examples. One question. You're obviously carrying along the `ip-up' argument list, i.e., Arg Name Example $1 Interface name ppp0 $2 The ttyttyS1 $3 The link speed 38400 $4 Local IP number12.34.56.78 $5 Peer IP number12.34.56.99 These variables are clearly being propogated to your (custom rolled) ip-up.d/* scripts. How are you propogating these values? Environment variables? We'd have to std'ize the variable names too, if so. ...A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/ Why not as the same command-line arguments? And there is one thing which I would qualify as a mistake in the above description: $2 is actually in the form /dev/ttyS1 than just ttyS1. 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: Linux on a i286
Is there a way I can get Linux to work on my old 286? There is an attempt to port Linux to 086 called ELKS. Look for it's link on LDP page (http://sunsite.unc.edu/LDP/). Last time I checked I still couldn't even boot it on my 286 though. 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: [PGP]: can someone in NYC sign me?
I'm hoping to get my PGP keys signed by a known and registered debian developer in the NYC area so as to comply with the Debian Developer's Reference Section 1.2. I'm located in Manhattan; specifically on the Lower East Side. Any takers? Please reply to me offline. Thanks. ...A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/ Dear A. P. Harris, if you don't mind coming to NYU, that's fine with me. Just one question to the public: is it OK to take a floppy with his public key, sign it without his phisical presence and than e-mail him the signed file back (encripted with his key)? 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: libc5 backports problem
One problem with doing backports of libc5 packages is that dpkg-dev in bo doesn't seem to support pristine sources; it complained that the original wasn't in the .orig subdirectory. Although dpkg-dev from hamm works fine on bo since it is not libc dependent, it's still not possible to backport on a completely-bo given this factor, unless I am missing something .. Hi. As far as I understand, you just told that you can use dpkg-dev from hamm to produce binary package on bo system. So, what is the problem now? I guess even earlier dpkg (from bo) can install them OK, right? 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: libc5 backports problem
Although dpkg-dev from hamm works fine on bo since it is not libc dependent, it's still not possible to backport on a completely-bo given this factor, unless I am missing something .. As far as I understand, you just told that you can use dpkg-dev from hamm to produce binary package on bo system. So, what is the problem now? I guess even earlier dpkg (from bo) can install them OK, right? The only prolbem is that you cannot produce these packages on a purely bo system as some have promised/hoped. For example, Tim Sailer is offering access to a bo system for backporting, but unless it has been upgraded to dpkg from hamm then pristine sources aren't supported. Well, I guess then libc5 machines dedicated to backporting should have dpkg-dev from hamm installed. And upload newer dpkg-dev to bo-unstable for consistency. 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: Re^2: fixhrefgz - tool for converting anchors to gzipped files
Moin Christoph! CL 200Mhz Pentiums are the standard fare today. And I am running CL the boa webserver for example on some low memory 486DX66s with I'm using a 486/100 and a 486SL/33. In my opinion we should avoid using the server to uncompress the files. We should find another solution. CL excellent performance. Boa serves directly from disk unless CL there is the need to gunzip something. Right, but does all WWW server offer this feature? We can't force the user to install a specific server. Why not? This could be a part of Debian documentation system. The only restriction would be to run it on unconventional port and preferably from inetd. Alex Y. CL The big issue here is that you want to change an existing CL very public API (http protocol) to include compression which CL may be a big hassle to install on many platforms and so far CL has not been an issue on the more popular platforms such as CL Win95 or other Unixes. I don't see the problem. The online help system should be designed for the Debian users. If a Windows, MAC, etc user want to use the help systen he has to install gzip as helper application. But maybe we would build a compressed file system using gzip and the loop back device? cu, Marco -- Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/ -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^4: fixhrefgz - tool for converting anchors to gzipped files
Am 29.06.97 schrieb aqy6633 # is5.nyu.edu an Marco Budde ... Moin Alex! AY Right, but does all WWW server offer this feature? We can't force the AY user to install a specific server. AY Why not? This could be a part of Debian documentation system. Because no admin would like to have to httpd on his system: one for our documentation and one for the other. Why? If the server is started from inetd it doesn't eat up any resources while not in use. And another option would just have two (or more) document roots. It is not difficult to configure httpd this way, but configuration differs for different servers. Changing web server would then be not very trivial task. AY The only restriction would be to run it on unconventional port AY and preferably from inetd. Again, why should we use a WWW server? This is always slower than read the files direct from disc. cu, Marco Yes, but as you mentioned to your e-mail to Christoph, we can't patch Netscape to convert .gz files on the fly, not mentioning that if we implement that using web server, there will be possibility to browse documents from different host. Thanks. Alex Y. -- Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/ -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: How about e2compr? Was: fixhrefgz debate
I am really irritated by such insistence on a view my box at home and nothing else matters. We are not all just hacking for fun at home. Some people actually make their living with the stuff. I completely agree with you. But this is just some kind of a Debian sickness not to think of this kind of users. I don't understand why we should pay more attention to the play at home Un*x newbies than to the people who are trying to make their living with the stuff. Please, think about it guys. Alex Y. P.S. Yes, I *am* that kind of user. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: jdk packages
Whats the difference between the jdk packages and the jdk1.1 packages? I just found both in the archive. Well, jdk packages represent jdk 1.0.2, the other -- jdk 1.1.1 Java interpreter is 2 times faster in 1.1.1 plus much expanded API, but it is new and only a few browsers support it. Though description claims that you can have both packages installed and being used, you will have to fix some scripts which come with the package (most notably /usr/bin/appletviewer-jdk) to make it happen. Installing either one will probably work without a problem. Alex Y. Michael -- Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
On Mon, 23 Jun 1997, Alex Yukhimets wrote: [snip] contrib. Try to run it on Lesstif and it won't work, because it will not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib. Yeah, but Lesstif was not meant to be *binary* compatible with real Motif, only *source code* compatible! Is this true? Then there would be no reason to create the motif-libs virtual packages! (The only use for them would be to allow drop-in replacements of the compiled shared library packages.) Yes, but... have we meant anything else? I don't know how usefull would be the virtual package, but having dummy motif (which provides run-time libs AND mwm) and motif-dev packages would be nice. Alex Y. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Debian is looking [EMAIL PROTECTED], [EMAIL PROTECTED] for a logo! Have a look at our drafts PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA athttp://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/ -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
The reason we need virtual packages is so that we can allow people who (like myself) have gone out and bought real Motif to use it on Debian. I would be glad to throw away my Motif CD, and only use Lesstif. Last time I tried compiling Nedit against lesstif, the results were almost usable, but still disappointing. I am getting a new computer (K6-200) to replace my old 486, and I plan on compiling Nedit against the latest Lesstif again. If it works, i will upload it (and we can get it out of contrib). I still plan on compiling a statically linked version against REAL Motif though (for those who want everything to work perfectly). I don't believe Lesstif is quite ready for primetime. Regardless, since there are two versions of Motif, with different Library names that are not compatable (sure, you can recompile but they are not binary compatable), we need both motif12 and motif20 virtual packages. Lesstif should be modified to provide motif12. For other people that have commercial Motif, we need to have TWO motif dummy packages. Or one that provides both virtual packages... O.K., First of all, Lesstif does *not* provide even motif12, it is NOT binary compatible with real Motif 1.2 . As for the binary compatibility of *real* motif 1.2 and 2.0, could anyone who have runtime package of Motif 1.2 installed try to install and run nedit-dmotif. Anyone??? It was claimed by OSF that thay are binary compatible, but who knows... Alex Y. Just my $0.02, -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
Option 3: We ship .texi files and produce HTML and/or info files on demand (in the postinst script). Advantages: - No work for the maintainers. - Great flexibility (the sysadmin could even produce PostScript files when needed!). This is extremely good idea. Possibility to have a hard copy of a ducumentation is a big plus! Not saying that having document source is also not that bad. My prediction is that while a few people will like option 3) very much, it will be unacceptable by a few others. (People usually don't want to compile docs when installing a firewall :-) So we should have an option not to compile *during* install. Are there any utilities to get plain text documentation from .texi ? It might take much less time then. Alex Y. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
On Sun, 22 Jun 1997, Dirk Eddelbuettel wrote: What about the motif-dummy thingie we discussed? How can I run plan having Motif and not lesstif installed? Can you make sure it doesn't Depends: on lesstif, but rather on a virtual package 'motif-libs' which lesstif, and a to-be-created-dummy package for Motif owners, would provide. Is that doable? CC'ed this to the virtual-package-list maintainer for comments. That's a good idea! AFAIK, Motif 1.x and 2.x are quite different. Shouldn't we use two different virtual package names for these major versions? (You can't use versions of a virtual package, yet.) I don't think that support for different Moitfs are needed. All known software despite of being compiled with Motif 2.0 does not use features not present in Motif 1.2 The reason for this is that big unices does not have Motif 2.0 actively shiped from the vendors yet and using Motif 2.0 features would make your application imposible to port. *When* situation changes, I don't think that anyone using Motif for i386 Linux would have Motif 1.2 (And franckly speaking, 2.0 also. By that time all vendors will be shipping 2.1 which would _hopefully_ be compiled against glibc for Linux) Alex Y. 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! -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
I don't think that support for different Moitfs are needed. All known software despite of being compiled with Motif 2.0 does not use features not present in Motif 1.2 The reason for this is that big unices does not have Motif 2.0 actively shiped from the vendors yet and using Motif 2.0 features would make your application imposible to port. *When* situation changes, I don't think that anyone using Motif for i386 Linux would have Motif 1.2 (And franckly speaking, 2.0 also. By that time all vendors will be shipping 2.1 which would _hopefully_ be compiled against glibc for Linux) Alex Y. But things linked against Motif 2.0 cannot link against and run with a Motif 1.2 library. Take for example nedit-dmotif, currently in Not true. contrib. Try to run it on Lesstif and it won't work, because it will not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib. Yeah, but Lesstif was not meant to be *binary* compatible with real Motif, only *source code* compatible! Alex Y. When I compiled nedit, I used a Motif 2.0 library. I agree with Chris that we should have both a motif12 and a motif20 virtual package. -Erik -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
dpkg-source problem ?
Hello,guys. At some point I found that when I try to execute dpkg-source -x *.dsc (for the most recent ddd in hamm) I got the error message: dpkg-source: error: diff contains unknown line `\ No newline at end of file' What could be the reason for that? And more, executing it on hello (!) package (from bo), I get: dpkg-source: extracting hello in hello-1.3 dpkg-source: failure: remove patch backup file hello-1.3/debian/substvars.dpkg-orig: No such file or directory I am using dpkg-dev 1.4.0.17 Thank you. Alex Y. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
pgpxvBvJPfRN3.pgp Description: PGP message
Re: Debian target audience
On Jun 16, Alex Yukhimets wrote I am sorry to say, but you are wrong. Even on this list there were several postings regarding this matter. There are several known problems and who knows how many unknown. You just can't afford to experiment with production system this way. Anyway, I could take some burden on myself to compile libc5 counterparts, but on my 486DX2/66 with 2k/sec connection it would take years. Well, if it really is a production machine (people yell if it goes down, etc.) shouldn't it be tracking stable instead of unstable anyways? I don't think that kind of change (libc5 - libc6) can't be made without some amount of instability and experimenting well, unless we get only perfect developpers who recompile all their packages for libc6 at the same time. :) Christian Very good point, I can't agree more. That's what we expect from the hamm release: ALL packages recompiled with libc6. The only problem that commercial software won't be recompiled (or at least upgraded -- $$ issue) by that time. And of course, that would prevent to install hamm. Which means that I would be in situation equivalent of using rex NOW. What answer would I get on the bug report against rex package? -- It was fixed long time ago, upgrade to ...3.45-5.deb from bo. And it is fine, 'cause bo and rex are based on libc5, but if I'll be using bo at the time hamm is released I wouldn't have this possibility. That's why I would really encourage Debian community to behave more like respectable commercial distribution and give customer a choice: to install libc6 hamm OR have at least some support for bo while hamm is stable. Thank you. Alex Y. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian target audience
The problem of having both libc5 and libc6 run-time libraries is minor,
the main one is that those stuck with libc5-dev cannot use other
newly-available versions of *libraries* from hamm.
How do you mean? You can install the *libraries* just fine, it's just
the development versions that fail to install.
That's exactly what I meant, sorry if it wasn't clear.
And even then, why not install lib5-altdev? Then there is no problem
whatsoever.
I am sorry to say, but you are wrong. Even on this list there were
several postings regarding this matter. There are several known
problems and who knows how many unknown. You just can't afford to
experiment with production system this way. Anyway, I could take some
burden on myself to compile libc5 counterparts, but on my 486DX2/66 with
2k/sec connection it would take years.
Alex Y.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
_
_( )_
( (o___
| _ 7 '''
\() (O O)
/ \ \ +---oOO--(_)+
|\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Debian target audience
Hello all. Some time ago there was a posting on the list stating that typical Debian user is of SysAdmin type. The guy received a lot of negative responses and as a result we have now dotfile-generator in the distribution as our statement of being friendly to novices. Good thing, but what is Debian target audience anyway? Let's get serious, office worker would rather go with Caldera (if Linux at all), ISP - with FreeBSD, newbie - with RedHat, etc. Debian is the effort of a large number of developers and primararily *for* developers. No, we don't forget newbies (dotfile-generator), office workers (Freedom Desktop), ISPs (ongoing MTA discussions) but we DID forget dvelopers. Here is why: 1) Every developer using commercially available libraries is forced to stay with libc5 developmental tree for a while. 2) Every developer (even one NOT using commercial products) is interested in having recent versions of the freely available libraries. 3) Every user (including developers) is interested in having recent versions of freely available applications (editors, debuggers, viewers, etc.) 4) It is preferable for everyone to have only one runtime library (either libc5 or libc6). Having applications using both does eat up memory and slow down system. (that's why we are having deadlines for converting libc5 packages in hamm ) 5) In the situation with libc5 - libc6 transfer developer stuck with libc5 will not be available to enjoy goddies from the 2)!!!, 3) and 4) because all new software will be compiled against libc6. I hope you agree that situation is not acceptable. My proposition, which I already stated, is to have in addition to stable and unstable something called unsupported where would all newly available packages (and versions) compiled against libc5 be placed. There were offers to make sevral systems with good network connection available for compilation libc6 and libc5 packages for the debian maintainers. (Thanks, guys) And I think this could really help. Thank you. Alex Y. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian target audience
Alex Yukhimets: Debian is the effort of a large number of developers and primararily *for* developers. I disagree. I think Debian is for anyone who wants a good Linux system, and who doesn't need much non-free software. ^^^ That was exactly my point. Why should Debian cut off those who *does* need non-free software? Especially developers. I don't agree that having both libc5 and libc6 run-time libraries in use at the same time is important enough to burden ourselves with duplicate packages. The problem of having both libc5 and libc6 run-time libraries is minor, the main one is that those stuck with libc5-dev cannot use other newly-available versions of *libraries* from hamm. Thanks. Alex Y. I don't mind if someone maintains separate libc5 packages, but it should not be the project. -- Please read http://www.iki.fi/liw/mail-to-lasu.html before mailing me. Please don't Cc: me when replying to my message on a mailing list. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Simple policy question...
Okay, so say some random person who has installed Debian wants XEmacs 19.15 because he needs some feature. This seems like a reasonable request... He could get it from the Hamm distribution, except that would mean he'd need libc6...and he doesn't want to do that, because he's heard that it will affect the stability of his system. What then can he do besides compile it himself? If the answer is only compile it himself...is there a way we can add a special update directory for 1.3, that will have later versions of programs, and people can optionally tell dselect to look there? Or am I missing a big part of the picture? Thanks, Sam That is exactly what I posted on the list a few days ago. Unfotunately there was the only response (from Brian White -- thanks). I proposed to have unsupported directory with the updates of this kind which would not officially belong to the Debian 1.3.* . The most solid ground not to switch to libc6 is not instability from the user's point of view (may be libc6 is not that bad), but from the point of view of developer who's using different kind of commercial developmental suits. Unfortunately, as far as I can see, there is no clean way to have both developmental trees (libc5 and libc6) on the same machine. And what even more unfortunate, Debian's goal does not seem to have a good transformation period system, where ALL tricky points of two libraries coexistence are resolved, but to switch EVERYTHING to libc6 as soon as possible. The only outcome of this would the loss of quite a few serious developers for Debian's community. Thank you, Alex Y. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 policy in unstable
I'm not entirely certain I see why we need to remove libc5 packages from the system for Debian 2.0. While I agree that the primary packages should really be glibc, I don't see how a few lib5 packages are going to hurt the distribution Well, they won't hurt much, but they would: - make memory usage less favourable (if you're running a mix of libc5/libc6 binaries, you'll have both in memory). - make Debian look less attractive (We wouldn't appear in the list of distributions that are fully libc6). Could you please point me to such a list? Anyways, Debian just can't compete with commercial distributions which can allow to suppose that they are self-contained. Debian is NOT. Unlike RedHat (which has, for instance its own Motif and Metro-X), we can't include ANY commercial product into the distribution. They could recomplie them and have fully libc6 distribution in a day. There is a big world outside Debian, and the only way to compete is to provide as much flexibility as possible. Yes, Debian must migrate to libc6 ASAP, but it shouldn't just cut off the conservative part of the users (they won't be back) and provide FULL choice for both environments. Thanks. Alex Y. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 policy in unstable
Of cource, there isn't such a list now (as far as I know, at least I guess that list would be empty now). Anyways, Debian just can't compete with commercial distributions which can allow to suppose that they are self-contained. Debian is NOT. Unlike RedHat (which has, for instance its own Motif and Metro-X), we can't include ANY commercial product into the distribution. So, why does that mean we cannot compete? What has self-contained to do with Motif? By self-contained I meant that *most* of the users of the particular distribution would not need to install anything from outside of it. The nature of Debian implies that ALL commercial products, even the the most popular ones (like Motif) are outside of the distribution and has to be purchased seperately. And once purchased, you can't just recompile them with new library, you kinda stuck with them and expect that distribution you've chosen (Debian) would still support you and provide you with recent versions of other free developmental software. Thanks. Alex Y. Anyway, Lars just posted a script to auto-build the whole distribution, and I really think with such scripts (presumably improved ones, but the one from Lars apparently already works) we will get a self-contained distribution rather soon. They could recomplie them and have fully libc6 distribution in a day. Wait and see what Lars will do. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
jdk1.1 - no dynamic Motif linkage package
Jim, why didn't you upload shared Motif library version of jdk1.1-runtime? I just wonder if there is any reason for that. Thanks. Alex Y. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Debian 1.3 and alien
Hi. In 1.3 release announcement Debian compatibility with rpm and Slackware packages mentioned 2 times. And one time it explicitly states that it is achieved via enclosed utility to convert mentioned packages to Debian format. (This is alien, right? :) How can we cope with the fact that Slackware support of the Bo release of alien is broken then? Thank you. Alex Y. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: just making sure we're all really this quiet
Is it me, or are the Debian lists really quiet? My secondary list server hasn't transferred a single thing from the primary server in several hours, perhaps even a day. Am I crazy, or did I break something? No you are not. During the last 24 hours I received only 2(!) debian lists-related messages. And one was actually reply on my message posted a few days ago (doesn't really count since it was replied directly to my address) and YOURS!! I tried to resubscribe to the different e-mail address several hours ago and didn't get even automatic confirmation. So I guess something really happend to the lists. Alex Y. I think I should suggest that we remove all of the editors except ae from the entire Debian project, just to rekindle our classic flame war (and verify that people are really out there!). If you've made any recent posts (within 24 hours) and haven't seen them come through, please let me know so I have something to look for. Thanks! Pete -- Peter J. Templin, Jr. Client Services Analyst Computer Communication Services tel: (717) 524-1590 Bucknell University [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
