Re: xforms0.86 package insanity
Scott == Scott Hanson [EMAIL PROTECTED] writes: Scott Talk about quick service... I found the packages in Scott Incoming this morning :) *grin* Well, it wasn't terribly difficult -- but I'm extremely glad for debhelper :) -- Brought to you by the letters X and D and the number 10. Nerd. Loser. Jerk. Moron. Worm. Scum. Idiot. Fool. -- Pkunk, SCII Ben Gertzfield http://www.imsa.edu/~wilwonka/ Finger me for my public PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
a 64 bit variable, it's good for another 4000 years. Uhhh -- no. If it went from 32 bits to *33* bits, that would get us 4000 years. This gets us more like 16 billion billion years (american billions - 16 x 10^18 is what I mean, but it's off the top of my head...) Don't you think you're overstating this just a bit? What about programs that store time_t's in ints? Or write them out to some kind of storage? Well, NetBSD already has a 64 bit off_t... I think the way most people expect the transition to happen is that *int* will become 64 bit, and things will just deal. Since lots of other things that assume 32 bit ints now are already starting to break (ip addresses won't fit any more, off_t's won't fit, pointers *never* fit on the alpha...) I think that system code will be fine, and legacy code will be the problem that it already is. Note also that for most applications that can't be recompiled, being really clever with the 32-bit ctime in the shared libc will cover a fair number of sins... but I hope not to catch anyone actually doing that :-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
ncursese
Hi, I wonder if you could update the debian ncurses package to the latest version : 4.1 available from ftp.clark.net /pub/dickey/ncurses. Taper doesn't work with the debian release of ncurses and I'm getting many people writing asking why they can't type messages into dialog boxes etc.. Unfortunately, most of these users don't know how to retrieve ncurses themsevles, compile and install. -- Cheers, Yusuf ___ From Yusuf Nagree [EMAIL PROTECTED] Author Maintainer of Taper Latest Stable version 6.8.3 28 DEC 1997 Web Page: www.multiline.com.au/~yusuf Mailing list: [EMAIL PROTECTED] Locations: http://www.multiline.com.au/~yusuf ftp://sunsite.unc.edu:/pub/Linux/system/backup ftp://tsx-11.mit.edu:/pub/linux/sources/sbin ___ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Deselect problems.
I have never given dselect a fair shakedown, because every time I have tried it I have immediately gotten in trouble. Yesterday and today I have decided to carry out the process to its conclusion. I've gotten in trouble again. I wonder if other people are beyond these problems; I am amazed not to see more questions on the net, after the experience I am having. I'd like to comment. Dselect goes berzerk when I chose to allow it to remove packages. It isn't apparently following my advice. I spent three to four hours trying to get all the way through the list, but when trying to override suggestions I have gotten into trouble a few times---dselect doesn't want to believe my overrides, and goes right back and tries to do the same thing all over again. Dselect botched up the various perl packages so badly that dselect itself couldn't run properly. I had to reinstall all those packages by hand before the login script would work. Files I hadn't at all specified were deleted. I can't offer much in the way of constructive criticism. When running through the selection process, both gs-aladdin and the kernel source and headers come up again and again. If overridden once, they pop up again whenever there is a doubt. Selecting packages becomes a dizzying process. Gs-aladdin isn't recognized, apparently, as an alternative to gs: it was twice removed, and twice reinstalled, together with gv. The kernel source and kernel headers thing is especially troubling. Numerous times, the same knot comes up, even when I attempt to override. When I successfully override the suggestion to install kernel headers and kernel source, dselect can't accept it. Can't developers accept that some users---I'm reasonably sure I'm not the only one---want to do kernel compiles and headers the standard way? Can't you make it a nice enhancement (for those who chose it) rather than building those kludges into the system so insidiously that it becomes double the trouble to try to do things that standard way (yes I have read that FAQ's). Everything having happened so suddenly, how can I find out what packages were merrily removed by dpkg, short of these occasional surprises that are now punctuating my life? It would be more than courteous to remind the use what was removed after it's all happened; it would be better still if the removal was interactive. Progress reports would be nice for other actions as well. I have had trouble compiling a number of things on my system, and with the proliferation/fragmentation of libraries (in a vacuum of documentation or indications of what goes with what) I haven't been sure what I really need to have on the system, or what I need to keep up to date. The debian packaging system is extremely helpful inthis way, but it is offset by this fragmentation that has become almost ridiculously hard to keep up with. Perhaps dselect or it's ilk could check for a standard development setup, what might be wrong, what might be right with it. Or, for example, networking. A checkup, looking for obvious problems, depending on what the user wants or needs. I think that such tools are probably going to be more useful somewhere down the line, when the dust has settled a bit. I'm now in my third (and last) try. I've about run out of time. Alan -- Our loyalties are to the species and the Alan E. Davis planet. We speak for Earth. Our[EMAIL PROTECTED] obligation to survive is owed not just to Marianas High School ourselves but also to that Cosmos, ancient AAA196, Box 10001 and vast, from which we spring.Saipan, MP 96950 Northern Mariana Islands ---Carl SaganGMT+10 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
ytalk up for adoption
I've been maintaining 'ytalk'. I don't actually use it any more, and it's the only X-based thing I maintain except xtrkcad, which is a binary-only package that I don't have to futz with much. Therefore, I'd like to stop maintaining ytalk... Anyone want it? There are a couple of open bugs, but I'm really not motivated to put any more time into it. Bdale -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
On Sun, Jan 04, 1998 at 02:43:21PM +1000, [EMAIL PROTECTED] wrote:
Dselect goes berzerk when I chose to allow it to remove packages. It isn't
apparently following my advice. I spent three to four hours trying to get
all the way through the list, but when trying to override suggestions I
have gotten into trouble a few times---dselect doesn't want to believe my
overrides, and goes right back and tries to do the same thing all over
again.
If dselect, doesn't let you move on easily, then they're probably
not suggestions, they're recommendations. You have to hit Q to ignore
recommendations. Or they might be dependencies; if that's the case,
things WILL break when you tell it to remove them anyway. (In fact,
dselect won't actually be able to remove them -- dpkg won't do it).
Dselect botched up the various perl packages so badly that dselect itself
couldn't run properly. I had to reinstall all those packages by hand before
the login script would work. Files I hadn't at all specified were deleted.
Are you sure you haven't forced anything?
Can't developers accept that some users---I'm reasonably sure I'm not
the only one---want to do kernel compiles and headers the standard way?
Can't you make it a nice enhancement (for those who chose it) rather than
building those kludges into the system so insidiously that it becomes double
the trouble to try to do things that standard way (yes I have read that
FAQ's).
There is absolutely no necessity to have a kernel-source or
kernel-headers package on your system (that I'm aware of). You can
certainly dump your own copy of the Linux source tree into
/usr/src/linux, compile it (with or without kernel-package/make-kpkg)
and install it. dpkg/dselect won't care. I never use the source
packages because I don't like the way they're already patched
with some non-standard things in some cases.
(Actually, the latest libc6{-dev} does require you to install
kernel-headers. Are you running that?)
If you're complaining about the lack of symlinks from
/usr/include/linux to /usr/src/linux/include, can you supply
three really good reasons why you need them? Any good kernel-specific
software knows that it has to look in /usr/src/linux/include
for the headers, not /usr/include/linux. The kernel itself
ignores /usr/include/linux. I know ftape for example
(which compiles as a module and is therefore kernel specific)
knows to look in /usr/src/linux/include.
Perhaps dselect or it's ilk could check for a standard development setup,
what might be wrong, what might be right with it. Or, for example,
networking. A checkup, looking for obvious problems, depending on what the
user wants or needs. I think that such tools are probably going to be more
useful somewhere down the line, when the dust has settled a bit.
Debian 2.0 might have some pre-defined installation types, but after
the system is installed, dpkg will ensure that all the dependencies
are met, ie that any piece of software installed has all the other
pieces of software it needs also installed. But if you force anything
with dpkg and dselect, you're on your own.
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] .
I'll take ftplib
Hi. I noticed that one of the packages for which I reported a link shared libraries against other libraries bug was orphaned. Because I rather like the package (ftplib), I decided to pick up maintenance and bring it up to date with current policy. There is also a new upstream version with significant changes to the package layout. The first thing I ran into was that there does not seem to be a Keeper of the sonames for this library. The upstream source simply creates an ftplib.so file without a version number. I will contact the author about that, but what should I do in the meantime? The previous package (ftplib 2-3) installs the shared library as libftp.so.1.0 and makes a link from libftp.so.1, but it does not seem to give it an soname while linking it. What is the effect of that? Is it anything I need to worry about for backward compatibility? (I'm assuming that the author will want to start numbering at 2 or 3, because there are interface incompatibilities between ftplib-v1 and ftplib-v2, and the current version is ftplib-v3). Thanks, Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re^2: dhelp 0.2 - a online help system
Am 03.01.98 schrieb schwarz # monet.m.isar.de ... Moin Christian! CS We are aware of this problem. The different menu systems (menu, dwww, CS dhelp, etc.) all have their advantages and disadvantages so I guess they CS will all stay around for a while. If you know a disadvantage of dhelp please send me an email. I'm really interessed in good ideas. CS The solution is to provide a unique interface where all packages can CS register their documentation files. This interface programm will than CS support the different menu systems, depending on which are installed. This But is that necessary? We could write a simple .dhelp to .dwww converter or dwww can use the /var/lib/dhelp/dbase database. That's no problem. I think, we should use this help system in Debian 2.0. Some other distributions already use such systems (for example SuSE). I've added dhelp support in debstd last night. It's really no problem to add dhelp support to your packages. CS I'm currently working on a draft for this interface. It looks like we're CS going to implement that together with a new Documentation Policy for CS Debian 2.1. Why should we develop another system? We have a working system: dhelp. If we need new features, I can add them. 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] .
Pre-processor Manifest Constant
Does the gcc preprocessor have any such constructs as manifest constants? The coherent C compiler used several such items to insert date/time into the compiler output, among others. These seem to be either pre-declared values, or function calls that actually interigate the system and leave output for the preprocessor to deal with. I am pretty sure that the term manifest constant is not used in Linux, but I'm not informed enought to know what other term might be used. Any pointers to the docs would be greatfully accepted. Waiting is, 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: Pre-processor Manifest Constant
I think you can find what you want in the cpp info file, node Standard Predefined. It lists macros like __DATE__ and __TIME__. gcc itself also defines __FUNCTION__ and __PRETTY_FUNCTION__, which behave more like string constants and can not be used in preprocessor directives. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ytalk up for adoption
On Sat, Jan 03, 1998 at 10:34:09PM -0700, Bdale Garbee wrote: I've been maintaining 'ytalk'. I don't actually use it any more, and it's the only X-based thing I maintain except xtrkcad, which is a binary-only package that I don't have to futz with much. Therefore, I'd like to stop maintaining ytalk... Anyone want it? There are a couple of open bugs, but I'm really not motivated to put any more time into it. I'll take it. As soon as I can find a scanner to scan my ID card to get an account on master.. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Pre-processor Manifest Constant
On Sun, 4 Jan 1998, Richard Braakman wrote: I think you can find what you want in the cpp info file, node Standard Predefined. It lists macros like __DATE__ and __TIME__. gcc itself also defines __FUNCTION__ and __PRETTY_FUNCTION__, which behave more like string constants and can not be used in preprocessor directives. Thanks, that's exactly what I needed to know! Much appreciated, 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: killall is removed from procps
Joey Hess wrote: BTW, could you make a procps-dev package with a libproc.a, and libproc's .h files in it? I need this for a package I would like to make called w.bassman, it's a different version of 'w', that links with libproc, and needs whattime.h to build. This would be the libproc-dev package. That's it's current name: Package: libproc-dev Architecture: any Section: devel Priority: optional Unless there is an overwhelming consensus to change it, I'll keep the name the same. - Craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
adopting xspread
I am willing to adopt the orphaned package xspread. I have converted its debian/rules to use the debhelper scripts and compiled the package against libc6. I will upload tomorrow unless there are objections. -- Douglas Bates[EMAIL PROTECTED] Statistics Department608/262-2598 University of Wisconsin - Madisonhttp://www.stat.wisc.edu/~bates/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: need libc5 non-maintainer upgrade
On Sat, 3 Jan 1998, Chris Fearnley wrote: 'Christian Schwarz wrote:' On Fri, 2 Jan 1998, Chris Fearnley wrote: '[EMAIL PROTECTED] wrote:' Actually, I'm not sure there is a problem with libc5-altdev. There definitely is a dependency clash between libc5 and libc6, which David Engel thinks we should patch by producing an upgrade for libc5. This will have to be installed before hamm. It's not yet clear to me that we can make this automatic with pre-depends or not. I don't think we should make it automatic. But it should be documented in the libc5 - libc6 transition FAQ. If it is possible, we should make it automatic, since most users don't read any documentation before trying it first. And try and error really fails here... In general, you would be correct. But pre-depends (or even depends) in libc6 on libc5 (which would be required to make it automatic) would force everyone who intalls hamm to also install libc5 in perpetuity. Which IMHO is equally bad. So I suggest the tradeoff: document the transition for those who want libc5 development support. But don't require it. Unless someone sees a clean solution? Sorry, but I don't get your point. Package: libc6 Version: 2.0.6-2 Pre-Depends: ldso (= 1.8.10-1) Conflicts: libc5 (5.4.33-7), libpthread0 (0.7-10) Package: libc5 Version: 5.4.38-0.1 Pre-Depends: ldso (=1.7.14-2) Depends: libc6 (=2.0.4-1) Conflicts: libc5-dev, wg15-locale, locales (2.0.4-1) libc5 only depends on libc6. Where is the pre-depends problem? AFAIR, the major problem is during an upgrade of bash. bash pre-depends on libreadlineg2, which conflicts with old versions of libreadline2. Thus, you'll have to upgrade libreadline2 _first_. However, this moves the libreadline* files from /lib into /lib/libc5-compat . Subsequent calls to bash will break unless you run `ldconfig'. Thus, there is no problem if you upgrade each of these packages _one at a time_. Running dpkg on all these packages at once _fails_ since libreadline2 is not configured immediately after unpacking. Now, if we could set the `Immediate-Configure: Yes' in the libreadline2 package, dpkg would just make it right, I think. Doesn't this solve all of our problems? 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: Re^2: dhelp 0.2 - a online help system
On 4 Jan 1998, Marco Budde wrote: Am 03.01.98 schrieb schwarz # monet.m.isar.de ... Moin Christian! CS We are aware of this problem. The different menu systems (menu, dwww, CS dhelp, etc.) all have their advantages and disadvantages so I guess they CS will all stay around for a while. If you know a disadvantage of dhelp please send me an email. I'm really interessed in good ideas. CS The solution is to provide a unique interface where all packages can CS register their documentation files. This interface programm will than CS support the different menu systems, depending on which are installed. This But is that necessary? We could write a simple .dhelp to .dwww converter or dwww can use the /var/lib/dhelp/dbase database. That's no problem. I think, we should use this help system in Debian 2.0. Some other distributions already use such systems (for example SuSE). You should probably not refer to SUSE here. They are know for their quick and _dirty_ solutions ;-) I've added dhelp support in debstd last night. It's really no problem to add dhelp support to your packages. Please don't get me wrong. I have nothing against packages supporting dhelp. However, dhelp is not our official system by now (nor is dwww) so we can't force everyone to use it by policy. CS I'm currently working on a draft for this interface. It looks like we're CS going to implement that together with a new Documentation Policy for CS Debian 2.1. Why should we develop another system? We have a working system: dhelp. If we need new features, I can add them. We need another system anyways to convert between different documentation formats on demand. Since every online documentation has to be registered to that system, we shouldn't we do the menu registration through the same system? Everything else looks like doing the same work a few times... I promise that we'll start discussing and implement the new doc-policy and all this when hamm is out of the door. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Debian has a logo![EMAIL PROTECTED], [EMAIL PROTECTED] Check out the logo PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA pages at http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 3 Jan 1998, Michael Alan Dorman wrote: Christian Schwarz [EMAIL PROTECTED] writes: By changing the dependencies you changed the source package before, or? Technically, no. The dependencies are build by dpkg-shlibdeps, so for all intents and purposes, the *only* difference between the old package and the new was the things totally external to the package and sources that were installed at the time. Oh, I see. But if I recall correctly, the old package was already uploaded to master (but stuck in incoming). And then the new package (with same source package--but different binary package) has been uploaded using the same version. This is bad since dselect/dpkg will not know that something changed. Anyways, we are not talking about that situation. This is past now. But we should talk about some guidelines that we can include in our documentation (this should go into the Developer's Reference I think) to avoid these troubles next time. How about this: ``Whenever the source package is changed WRT to the last uploaded version, its version number has to be incremented. In addition, if the source package is not changed but the binary package changed (because it has been recompiled in another environment), the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package.'' Any comments are welcome. 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] .
