Re: Getting Slink compatible with Linux-2.2.0
On Tue, 26 Jan 1999, Jason Gunthorpe wrote: On Tue, 26 Jan 1999, Gergely Madarasz wrote: But is that specific problem Debian/slink related..? That is, does it work correctly with potato? No, it does not work correctly with potato either. It seems to be a general incompatibility with 2.2 2.2 did something bizzar to how the packet filter code needs to work, nothing that used that mechanism will work anymore. Anyone made sure that libpcap works? I used tcpdump on 2.1.8x kernels iirc. It just needs the packet socket configure option in the kernel. And I just asked a friend to test it on a 2.2pre kernel, it still works. -- 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://mlf.linux.rulez.org/
Re: Uploaded util-linux 2.9g-6 (source i386) to master
Quoting Jason Gunthorpe ([EMAIL PROTECTED]): We also need working DHCP and BOOTP support in Slink otherwise those people cannot use 2.2 kernels - potatos DHCP package has support for 2.2 (and 2.0) but I don't know about bootp. dhcp-beta has worked on 2.1* as long as I can remember. Unless you're talking about dhcpcd? Mike STone
Re: What's needed for kernel 2.2
On Tue, Jan 26, 1999 at 07:40:21PM +0100, Remco van de Meent wrote: - Pcmcia-cs 3.0.6 ; cardmgr -V While the userland binaries appear to work fine, the PCMCIA kernel module source in slink will not build with 2.2 kernels. Version 3.0.8 fixes this. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpOOfr0boHJn.pgp Description: PGP signature
Re: Getting Slink compatible with Linux-2.2.0
In my more than honest opinion, I think util-linux 2.9g should be included in slink. Developments in the computer business are going fast, as everyone knows, and on the day slink will get released, I think a lot of people who are going to upgrade to slink, also want to have the newest kernel, 2.2. That's why slink should be compatible with Linux-2.2, otherwise it is quite a bit outdated at the moment of release. There is a major difference between not being compatible with the latest major kernel release, and not including the latest patchlevel of some software thingie. A stable release is always out of date. If you want leading edge, use unstable. We release stable so people have a known set that works together. It isn't an attempt to package the end-all and be-all of current Linux stuff. Brian ( [EMAIL PROTECTED] ) --- All is fair in love and war.
Re: New logo strategy
Ben Gertzfield [EMAIL PROTECTED] wrote: I believe the GIMP contests specify that you need to use GIMP for creating the image. But you're right, there's really no way to check that. Also, there's a -- perhaps subtle -- difference using GIMP exclusively and using it as but one of a variety of tools. -- Raul
Re: Uploaded util-linux 2.9g-6 (source i386) to master
Ok, so if we really want a Debian 2.1 that is 100% kernel 2.2.x compatible it needs this package to be included in frozen. I've just uploaded it in Incoming/ 10 minutes ago. Non-developers can also access it at http://www.ldsol.com/~vincent/ (NB: there are _2_ binary packages to install: util-linux and mount.) We also need working DHCP and BOOTP support in Slink otherwise those people cannot use 2.2 kernels - potatos DHCP package has support for 2.2 (and 2.0) but I don't know about bootp. We do not officially support the 2.2 kernel in Slink. People who want to use 2.2 will have to compile it themselves and may have to upgrade some packages. Brian ( [EMAIL PROTECTED] ) --- Management should work for the engineers, not the other way around.
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Wed, 27 Jan 1999, Alan Cox wrote:
The mail spool MUST be accessible through /var/mail AND /var/spool/mail,
and spool files MUST take the form /var/{spool/}mail/$LOGNAME. Either
/var/mail or /var/spool/mail, or both, MAY be symbolic links to another
directory.
That sounds good to me
And several others, I beleive. Perhaps a vote is in order?
It is RECOMMENDED that /var/mail be the actual directory and
/var/spool/mail be the symbolic link. At some point use of /var/spool/mail
may become deprecated.
Thats policy where it isnt needed
Then it doesn't have to be included. I only put it in to placate all the
other UNIXen use /var/mail, so /var/spool/mail shouldn't even exist type
people.
+-++
| Jakob 'sparky' Kaivo| [EMAIL PROTECTED] |
| NoDomainName Networks |http://www.nodomainname.net |
| AtDot E-mail Services | http://www.atdot.org |
+-++
Re: Uploaded util-linux 2.9g-6 (source i386) to master
On Tue, Jan 26, 1999 at 07:14:04PM -0500, Michael Stone wrote: Quoting Jason Gunthorpe ([EMAIL PROTECTED]): We also need working DHCP and BOOTP support in Slink otherwise those people cannot use 2.2 kernels - potatos DHCP package has support for 2.2 (and 2.0) but I don't know about bootp. dhcp-beta has worked on 2.1* as long as I can remember. Unless you're talking about dhcpcd? I couldn't get either to work when I started using the -pre series. However, ISTR that at least one of them has been fixed since then (I haven't been using the packages since then). -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: Uploaded util-linux 2.9g-6 (source i386) to master
Quoting Mark Brown ([EMAIL PROTECTED]): On Tue, Jan 26, 1999 at 07:14:04PM -0500, Michael Stone wrote: dhcp-beta has worked on 2.1* as long as I can remember. Unless you're talking about dhcpcd? I couldn't get either to work when I started using the -pre series. However, ISTR that at least one of them has been fixed since then (I haven't been using the packages since then). Well, I've had success w/dhcpd-beta. There is also dhcpcd-beta, dhcpd, and dhcpcd, all of which I haven't tried. Does anyone have a pass/fail list for these? Mike Stone
Re: linux 2.2.0: System is 666kB
At 10:02 + 1999-01-26, Enrique Zanardi wrote: (BTW, is kernel-headers still needed? libc6-dev ships with a full set of headers, doesn't it?) I still need the kernel-headers to build glibc (whether or not they are in a package doesn't really matter, but it would help with source dependencies). -- Joel Klecker (aka Espy) URL:http://web.espy.org/ URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] Debian GNU/Linux PowerPC -- URL:http://www.debian.org/ports/powerpc/
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
From: Florian La Roche [EMAIL PROTECTED] Date: Tue, 26 Jan 1999 10:44:20 +0100 How can changing from /var/spool/mail to /var/mail be a full solution for the next years to come? Many people think that the mail-dir solution that e.g. qmail and mutt support is the real solution for the future. Maybe future Linux distributions want to ship that as a default? They couldn't be compliant with this standard even though they use a more modern mail-storing setup. The change from /var/spool/mail can be done on any system with an ln -s spool/mail /var/mail. Why mix up all Linux users instead of keeping this a local solution anybody can do? Most Mail User Agents for standard Unix systems look in /var/mail/user for the user's mailbox. So if qmail is switching to ~/Mailbox, then they have to solve the problem for all of the various MUA's out there, and that is really qmail's and mutt's problem. I assume someone in that community must have thought about the problem, since people generally don't react well when they're told that they can't use their favorite mail reader because some new mail system has decided to use a different mailbox convention. So maybe any standard should not say something about the mail spool dir? Well, the problem is what happens if a third-party wants to ship a mail user agent? If how you get mail on a system is a distribution-local thing, that means that only the distribution-provided mail readers have a chance of working correctly. The whole point of the LSB effort was to allow this kind of third-party application provider to be able to work across different Linux systems, and not have certain applications that only work on RedHat systems, but not Debian systems, or vice versa. - Ted
Re: Uploaded util-linux 2.9g-6 (source i386) to master
On Tue, 26 Jan 1999, Michael Stone wrote: Quoting Jason Gunthorpe ([EMAIL PROTECTED]): We also need working DHCP and BOOTP support in Slink otherwise those people cannot use 2.2 kernels - potatos DHCP package has support for 2.2 (and 2.0) but I don't know about bootp. dhcp-beta has worked on 2.1* as long as I can remember. Unless you're talking about dhcpcd? I am, the dhcp server software doesn't need anything special, the client software however does. Jason
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
Most Mail User Agents for standard Unix systems look in /var/mail/user for the user's mailbox. So if qmail is switching to ~/Mailbox, then they have to solve the problem for all of the various MUA's out there, and that is really qmail's and mutt's problem. I assume someone in that community must have thought about the problem, since people generally don't react well when they're told that they can't use their favorite mail reader because some new mail system has decided to use a different mailbox convention. So maybe any standard should not say something about the mail spool dir? Actually, it might be worthwhile to specify that if environment variable MAILBOX exists, then MUAs need to honour it? Well, the problem is what happens if a third-party wants to ship a mail user agent? If how you get mail on a system is a distribution-local thing, that means that only the distribution-provided mail readers have a chance of working correctly. The whole point of the LSB effort was to allow this kind of third-party application provider to be able to work across different Linux systems, and not have certain applications that only work on RedHat systems, but not Debian systems, or vice versa. -hpa
further discussion on mail spool to lsb-spec@linuxbase.org
Please move any further discussion on over to [EMAIL PROTECTED] The current scope of the discussion is narrow enough that we can trim down the Cc list. My next post will be over there... Thanks. - Dan
kernel-source-2.2.0_2.2.0-1.diff.gz, odd contents
In scanning the contents of this file in Incoming, I some mysterious NULL bytes. Is this intentional? zless kernel-source-2.2.0_2.2.0-1.diff.gz
Re: Getting Slink compatible with Linux-2.2.0
VR == Vincent Renardias [EMAIL PROTECTED] writes: VR Including the current (2.9g-5) util-linux from unstable in VR frozen is a Bad Idea(tm). This version has several big VR packaging issues. On top of everything else, alpha support (and quite possibly other non-x86 architectures) in 2.9 is ever so slightly flaky. m.
Re: WARNING: Re: debhelper /usr/bin/passwd
In article [EMAIL PROTECTED],
Joey Hess [EMAIL PROTECTED] wrote:
Yesterday I fixed a bug in dh_link, bug #23255. That bug concerns a
different package that diverts /usr/bin/{passwd,chsh,chfn}, and needed to
set up some symlinks from sysdb-wrapper to them using dh_link.
Talk about heartstopping... I was wondering how on earth that escaped
my system...
--
almost called it today, turned to face the void along with the suffering
and the question- Why am I? [queensrÿche]
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Tue, 26 Jan 1999, Theodore Y. Ts'o wrote: Most Mail User Agents for standard Unix systems look in /var/mail/user for the user's mailbox. So if qmail is switching to ~/Mailbox, then they have to solve the problem for all of the various MUA's out there, and that is really qmail's and mutt's problem. Generally it's configurable; my .pinerc just says 'inbox-path=Mailbox' and that takes care of it, and Mutt (along with many other mailers, I'm told) just pays attention to $MAIL. There's a file in the qmail distribution called INSTALL.mbox that explains what to do to switch to the ~/Mailbox convention. So maybe any standard should not say something about the mail spool dir? Well, the problem is what happens if a third-party wants to ship a mail user agent? If how you get mail on a system is a distribution-local thing, that means that only the distribution-provided mail readers have a chance of working correctly. The whole point of the LSB effort was to allow this kind of third-party application provider to be able to work across different Linux systems, and not have certain applications that only work on RedHat systems, but not Debian systems, or vice versa. There are several ways to handle this. You can use DLLs like Microsoft, you can specify filesystem locations and file formats (which is the current FHS situation), you can specify environment variables and file formats (which is the current de facto standard, and the reason why switching to ~/Mailbox was easy for me). Setting environment variables like MAIL can be done in the global profile and csh.cshrc files. Currently, the FHS only specifies filesystem locations. This is considerably more restrictive than the other alternatives; switching to maildir format is essentially infeasible. The benefit of only specifying filesystem locations is that it keeps both the interface and the implementation simple. If every MTA came with a DLL to provide access to mailboxes stored in that MTA's format, I suspect that mailboxes and access thereto would be considerably more complex and failure-prone. -- [EMAIL PROTECTED] Kragen Sitaker http://www.pobox.com/~kragen/ Computers are the tools of the devil. It is as simple as that. There is no monotheism strong enough that it cannot be shaken by Unix or any Microsoft product. The devil is real. He lives inside C programs. -- [EMAIL PROTECTED]
Intent to package: Xconfigurator
I know some of you may want to shoot me but Xconfigurator is the redhat Xfree configuration utility, it's a hacked up xf86config that scans the pci bus to auto-detect the vid card, has a monitor database, and has a nice looking slang interface too. It will need a quite a few modifications to work with debian so I'm wondering if I should just split the tree and make my own version. Any comments? ftp://csociety-ftp.ecn.purdue.edu/pub/redhat/redhat-5.2/SRPMS/SRPMS/Xconfigurator-3.82-1.src.rpm use alien --to-tgz to convert it to a tarball Copyright: Copyright (c) 1994 by The XFree86 Project, Inc. Copyright (c) 1998 Red Hat Software, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -- Stephen Crowley [EMAIL PROTECTED], [EMAIL PROTECTED] -* Finger [EMAIL PROTECTED] for my public key. PGP#22714B25 *-
Re: Getting Slink compatible with Linux-2.2.0
On 27 Jan 1999, Mikolaj J. Habryn wrote:
VR == Vincent Renardias [EMAIL PROTECTED] writes:
VR Including the current (2.9g-5) util-linux from unstable in
VR frozen is a Bad Idea(tm). This version has several big
VR packaging issues.
On top of everything else, alpha support (and quite possibly other
non-x86 architectures) in 2.9 is ever so slightly flaky.
The 2.9 Debian package already contains the alpha patches supplied by
Christopher C Chimelis [EMAIL PROTECTED] (see bug report
#17661).
I am not aware of any other patch or problem specific to the alpha
platform. Can you please elaborate?
Cordialement,
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://www.ldsol.com -
---
-Microsoft est à l'informatique ce que le grumeau est à la crépe... -
Re: Getting Slink compatible with Linux-2.2.0
VR == Vincent Renardias [EMAIL PROTECTED] writes: VR The 2.9 Debian package already contains the alpha patches VR supplied by Christopher C Chimelis VR [EMAIL PROTECTED] (see bug report #17661). I am VR not aware of any other patch or problem specific to the alpha VR platform. Can you please elaborate? The structure in partition.h that's specific to the alpha does not match the generic one - the difference that I first noticed (from memory) was the naming of the last two fields in struct partition. One solution is to mark the generic structure definition with __attribute__((packed)), as this shouldn't make any difference to any platform other than those that actually need it there. I was going to test this before suggesting it, but time constraints etc, etc, etc :) m.
Re: Release notes for slink
hi Ship's Log, Lt. [EMAIL PROTECTED], Stardate 250199.2228: How about adding that the xvidtune program is in the xf86setup package? Some users may be confident enough about their X configuration not to bother installing xf86setup, and then miss xvidtune. If they are confident about there configuration, why are they interested in xdvitune? CAn it do anything besids configurating your X? Oh, ok .. maybe they want to reconfigure a bit l8r .. but then they should install a package to configure X ... :-) Greetings -- Alexander N. Benner - [EMAIL PROTECTED] - http://home.pages.de/~Nikodemus/ Believing that true love waits, I make a commitment to God, myself, my family, my friends, my future mate, and my future children to be sexual abstinent from this day until the day I enter a biblical marriage relationship. 1-800-luv-wait
Re: Intent to package: Xconfigurator
Sorry to reply to myself but I left part of the license off. On Tue, Jan 26, 1999 at 08:22:08PM -0600, Stephen Crowley wrote: Copyright (c) 1994 by The XFree86 Project, Inc. Copyright (c) 1998 Red Hat Software, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, neither the name of the XFree86 Project or Red Hat Software shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the XFree86 Project. -- Stephen Crowley [EMAIL PROTECTED], [EMAIL PROTECTED] -* Finger [EMAIL PROTECTED] for my public key. PGP#22714B25 *-
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
In article [EMAIL PROTECTED] you write: Most Mail User Agents for standard Unix systems look in /var/mail/user for the user's mailbox. So if qmail is switching to ~/Mailbox, then they have to solve the problem for all of the various MUA's out there, and that is really qmail's and mutt's problem. I assume someone in that community must have thought about the problem, since people generally don't react well when they're told that they can't use their favorite mail reader because some new mail system has decided to use a different mailbox convention. So maybe any standard should not say something about the mail spool dir? Actually, it might be worthwhile to specify that if environment variable MAILBOX exists, then MUAs need to honour it? What MUAs *can't* use ~/Mailbox? The only problem I have with my computer is that each MUA (eg pine and nmh) requires seperate configuration, and doesn't look at the $MAIL environment variable. elm supports it though, mutt might, but I haven't tried it. Where does the $MAILBOX environment variable come into it? elm uses $MAIL. eg I have $MAIL=$HOME/Mailbox I don't administer large Unix systems, but I like the idea of keeping users private mail in their home directories - IMHO it makes is easier to manage when a users files are all in one location and not segragated around the entire disk structure. Also, I suspect that some people might be confusing ~/Mailbox and ~/Maildir issues. These are two completely different issues. Maildir comes from Qmail, but my guess is that ~/Mailbox didn't. Qmail has a program that will automatically convert ~/Maildir to ~/Mailbox (this is what I use). The only problem I have experienced with Maildir is that it is not possible to convert Mailbox--Maildir and programs like login and sshd which check for new mail on login do not work --- however this is deviating from the current topic.
Re: Getting Slink compatible with Linux-2.2.0
The guys running the big machines are going to be a minority and should have no problem downloading util-linux. Even over a modem, its probably OK. It may be not worth it to risk the instability for the vast majority. The kernel source itself may be a problem for a slow or expensive modem link. I guess I don't care too much about the cachet of having 2.2 in slink. I wonder if we'll put 2.4 in slink -- John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Hardcore baby!!! Yeah!!!!
Looking for the hottest in porn action. We have it all...Straight, Gay, Asian, TEEN, and black. Come pick YOUR pleasure a href=http://www.teenagehotel.com/xxx/zombie/page5.html;Click here for serious porn action!!/a
Re: Intent to package: Xconfigurator
Stephen Crowley quotes: Except as contained in this notice, neither the name of the XFree86 Project or Red Hat Software shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the XFree86 Project. The license looks DFSG-ok, but I wonder if Red Hat really means to delegate that power to XFree86. -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED] Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address.
Intent-to-package: XGGI
XGGI is an X server based on XF86 code that will run under any supported libGGI target. Currently, other than a few XF 3.3.3.1 compliance points, XGGI works fine; it's been tested with the X target, the fb target, the emu target. shall I go on? I don't think anyone's tried AA yet. G'day ;) -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org Nullum magnum ingenium sine mixtura dementiae fuit. -- Seneca
Re: Intent-to-package: XGGI
Aaron Van Couwenberghe wrote: XGGI is an X server based on XF86 code that will run under any supported libGGI target. Currently, other than a few XF 3.3.3.1 compliance points, XGGI works fine; it's been tested with the X target, the fb target, the emu target. shall I go on? I don't think anyone's tried AA yet. Please hurry. :-) I've been dying to use this for a while, with the AA target. -- see shy jo
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Tue, Jan 26, 1999 at 05:37:53PM -0800, H. Peter Anvin wrote: Most Mail User Agents for standard Unix systems look in /var/mail/user for the user's mailbox. So if qmail is switching to ~/Mailbox, then they have to solve the problem for all of the various MUA's out there, and that is really qmail's and mutt's problem. I assume someone in that community must have thought about the problem, since people generally don't react well when they're told that they can't use their favorite mail reader because some new mail system has decided to use a different mailbox convention. So maybe any standard should not say something about the mail spool dir? Actually, it might be worthwhile to specify that if environment variable MAILBOX exists, then MUAs need to honour it? MAIL -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
An improved rolldice utility
As I care passionately about random numbers, I wrote a version
which generates *perfect* results.
As per feature requests, it accepts d% as an alias for d100, and
interprets a base % as a request for the RoleMaster d100 re-rolling
rules as I understand them from the description given. Someone
who knows the game please check the code to make sure I got it right.
Just roll by itself (name subject to change) prints help. The help
is, um, for the technically minded.
This is, of course, GPLed.
--
-Colin
/*
* roll.c - FRP die-rolling utility.
* This uses Linux /dev/random for the highest-quality possible random
* numbers. It avoids using any more entropy than necessary (e.g. rolling
* 3d6 has 216 possibilities and requires 1 byte of entropy in the common
* case), and goes to pains to make sure that the results it produces
* are completely free of bias, so the chance of rolling 1 on d6 is
* precisely 1/6.
*/
#include stdio.h
#include assert.h
#include unistd.h /* For read() */
#include fcntl.h /* For open(), O_RDONLY */
#include stdlib.h /* For exit() */
/* Unsigned is assumed to be at least a 32-bit type. */
typedef unsigned word32;
/*
* This ingenious function returns perfectly uniformly distributed
* random numbers between 0 and n-1 using a minimum of input from
* /dev/urandom. The truly macho should try to understand it without
* the comments.
*
* At all times, x is a random number uniformly distributed between 0
* and lim-1. We increase lim by a factor of 256 by appending a byte
* onto x (x = (x8) + random_byte) whenever necessary.
*
* The value of x%n has at least floor(lim/n) ways of generating each
* possible * value from 0..n-1, but it has an additional way
* (ceiling(lim/n)) of generating values less than lim%n. (Consider
* lim = 4 or 5 and n = 3.)
*
* To produce perfectly uniform numbers, if x lim%n, we add another
* byte rather than returning x%n. Becasue we only do this if x lim%n,
* taking the branch means that lim %= n.
*
* Once we have x = lim%n, then y = x%n is the desired random number.
* x/n is unused and can be saved for next time, with a lim of lim/n.
* There is a small correction that has to be added to deal with the fact
* that x/n can be == lim, which is illegal.
*/
unsigned
rand_mod(int randfd, unsigned n)
{
static word32 x = 0;
static word32 lim = 1;
unsigned y;
unsigned char c;
assert(n = 65536); /* Larger risks arithmetic overflow */
assert(n 0);
while (x lim % n) {
lim %= n;
if (read(randfd, c, 1) != 1) {
perror(Unable to read from /dev/urandom);
exit(1);
}
x = (x8) + c;
lim = 8;
}
y = x % n;
x = (x / n) - (y lim%n);
lim /= n;
return y;
}
/*
* Parse a die-rolling string and return the total. This does not
* bother checking for overflow, although limiting the numbers to
* 65536 pervents most situations.
*
* This bombs out with an error message and exit(1) on error.
*/
int
roll_string(char const *s, int randfd)
{
unsigned n, d; /* Roll n dice of size d */
char const *p = s;
int total = 0; /* Value of entire string */
int part; /* Value of current component */
int sign = 0; /* 1 for - */
int sign_required = 0;
/* Simple hand-rolled parsing loop */
do {
sign = 0;
/* Optional leading sign */
if (*p == '+') {
p++;
} else if (*p == '-') {
sign = 1;
p++;
} else if (sign_required) {
/* Without this test, d6d8 would mean d6+d8 */
fprintf(stderr, %s: I don't understand that.\n, s);
exit(1);
}
sign_required = 1;
if (*p == 'd') {
n = 1; /* Number of dice defaults to 1 if omitted. */
} else if (*p == '%') {
/* Special RoleMaster critical roll */
part = rand_mod(randfd, 100)+1;
if (part = 5) {
do {
part -= d = rand_mod(randfd, 100)+1;
} while (d = 96);
} else if (part = 96) {
do {
part += d = rand_mod(randfd, 100)+1;
} while (d = 96);
}
p++;
goto got_component;
} else if (*p = '1' *p = '9') {
n = 0;
do {
n = n*10 + (*p++-'0');
Re: Intent to package: Xconfigurator
On Tue, Jan 26, 1999 at 08:22:08PM -0600, Stephen Crowley wrote: I know some of you may want to shoot me but Xconfigurator is the redhat Xfree configuration utility, it's a hacked up xf86config that scans the pci bus to auto-detect the vid card, has a monitor database, and has a nice looking slang interface too. It will need a quite a few modifications to work with debian so I'm wondering if I should just split the tree and make my own version. Any comments? Uh, I was kind of planning on recruiting some folks to rip that thing open and Debianizing it for the potato release. I already have the latest Red Hat diffs in my X work directory on various machines, and was going to go through them for potato X. I'm just still working on kicking slink X out of the nest. Would you mind doing this work under the umbrella of the X Strike Force? I'd like to ship the X configurator in xserver-common once it's ready for prime time. -- G. Branden Robinson | The errors of great men are venerable Debian GNU/Linux | because they are more fruitful than the [EMAIL PROTECTED] | truths of little men. cartoon.ecn.purdue.edu/~branden/ | -- Friedrich Nietzsche pgpHgl4QXG2py.pgp Description: PGP signature
Re: Intent to package: Xconfigurator
John Hasler wrote: Stephen Crowley quotes: Except as contained in this notice, neither the name of the XFree86 Project or Red Hat Software shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the XFree86 Project. The license looks DFSG-ok, but I wonder if Red Hat really means to delegate that power to XFree86. Also: ... neither ... shall not ... If I read this correctly, this paragraph requires us to use both these names without permission :-) Richard Braakman
Re: Uploaded util-linux 2.9g-6 (source i386) to master
On Tue, 26 Jan 1999, Brian White wrote: We do not officially support the 2.2 kernel in Slink. People who want to use 2.2 will have to compile it themselves and may have to upgrade some packages. But what about shipping an extra directory support_2.2 which contains the kernel packages and the necessary utilities together with the Debian CDs. This will not break the Debian policy but gives every user the chance to try it with its own risk and avoid downloading the things over slow connections. Kind regards Andreas.
Re: Uploaded util-linux 2.9g-6 (source i386) to master
Vincent Renardias wrote: Ok, so if we really want a Debian 2.1 that is 100% kernel 2.2.x compatible it needs this package to be included in frozen. I've just uploaded it in Incoming/ 10 minutes ago. Non-developers can also access it at http://www.ldsol.com/~vincent/ (NB: there are _2_ binary packages to install: util-linux and mount.) Needless to say that before to be eventually included in frozen, this package must be _heavily_ tested. So if you're currently running the frozen distribution, please install this package and report any problem you may find. NB: back in June 1996, I decided to switch from Slackware to Debian because Debian 1.1 (codename: buzz ;) was the very first to be kernel 2.0.x ready. So I hope having Debian 2.1 kernel 2.2.x ready will attract a lot a new users to Debian. ;) Yes, that was exactly what I was going to ask. :-) It would be very nice. One doesn't install Linux everyday, and once one does, it should last for a while. Jernej
ODP: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
Hi all, I know that it's a bit out-off-the-line (that is, the solution I'll propose), I don't have anything to add the current */mail* discussion, but please don't flame me, the solution is just an idea that may be somebody from the current discussion audience could take if one likes it. The subject: It looks to me, that everybody cares about mail spool disk usage, so a lot of people put mail spools on a separate partition. In doing so, some people like to have partitions mounted as close to root as possible (the /var/mail variant). IMHO the choice is really quite unimportant, we live with symlinks for quite some time now, and they really serve the purpose of allowing both distributors and admins not to care too much. There is also an issue of best backup schedules that are different for *spool/mail and for *spool/lpd (for example) that make people have spool/mail on a separate partition from spool/other; but this doesn't support my points in the following paragraph, so I leave it alone for now. The actual problem is disk usage management limitation that we have on Unix boxes. Independently of whatever conclusion this FHS discussion on */mail comes to; Probably, it would be quite nice if some kernel guru took a deep breath and think of a subdirectory tree based quotas as an addition to current UID based filesystem quotas and partition size limitations, that today's Unixes provide for disk space management. I think, that if such quotas existed - thus allowing to provide a quota of, say 40MB, within /var/spool/mail for GID=mail and nobody else; and, say 10MB, within /var/spool/lpd to UID=lpd and, say 15MB, within /var/spool/cron to UID=root -- current /var/spool/mail discussion would be much less fierce or even void. For a time, everybody would live with couple of compatibility symlinks around, and since there would be no reason to move any */spool/* around, even those symlinks would disappear soon... I think. -R -- Od: Alan Cox[SMTP:[EMAIL PROTECTED] Wys³any: 26 stycznia 1999 01:16 Do: Theodore Y. Ts'o DW: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; debian-devel@lists.debian.org Temat: Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0 One simple one - I want my mail on the spool disk. Its in the grows randomly, mostly crap, doesnt cause hassle if it fills for a while category
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Wed, Jan 27, 1999 at 02:51:40PM +1100, Brian May wrote: Also, I suspect that some people might be confusing ~/Mailbox and ~/Maildir issues. These are two completely different issues. Maildir comes from Qmail, but my guess is that ~/Mailbox didn't. Qmail has a program that will automatically convert ~/Maildir to ~/Mailbox (this is what I use). The only problem I have experienced with Maildir is that it is not possible to convert Mailbox--Maildir and programs like login and sshd which check for new mail on login do not work --- however this is deviating from the current topic. ~/Mailbox has been around awhile but qmail was the first MTA to use that by default. Debian's qmail uses procmail in order to use /var/spool/mail/$LOGNAME instead of ~/Mailbox, though I have configured procmail to use ~/Mailbox for all users and for myself I use ~/.mail/INBOX/ (maildir format)... Of course, I do this with exim nowadays as qmail drove me batty and isn't DFSG free anyway. -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
Intent to package wterm
wterm is another Rxvt hack. It is designed for use with Window Maker, although it will work fine with any window manager. It includes transparency, N*XTStep-like scroll bars, and colored shading. It is smaller and faster than Eterm. You can find it at http://wm.current.nu/files.html#wterm. Adam pgp3TzNAhroaA.pgp Description: PGP signature
Re: Hardcore baby!!! Yeah!!!!
On Tue, Jan 26, 1999 at 10:45:57PM -0600, [EMAIL PROTECTED] wrote: [ pathetic attempt at sex spam snipped ] Can we PLEASE enforce our spam policy and make these people pay for their crimes against humanity? -- I'm working in the dark here. Yeah well rumor has it you do your best work in the dark. -- Earth: Final Conflict
Re: Rolldice 1.1
Stevie Strickland wrote:
Because not all Debian GNU/Linux systems have /dev/urandom (at least
I, personally, had to mknod c 1 9 /dev/urandom myself), and I want
this running on any basic system... eventually, when I had more time
(like this weekend), I was going to add a command line option to allow
usage of this device, as well as /dev/random... which would knock out
the sleep delay (yay!), but introduce the delay of the kernel gathering
entropy (oh, well, can't win all the time, I guess ;)...
Well, here's a modified version, with a good RNG (a variant of George
Marsaglia's highly-regarded KISS generator) stuck in for the cases
where /dev/urandom isn't available. It's seeded with gettimeofday(),
getpid() and getppid().
It also prints out the numbers it's summing to get the final result.
For example, roll %-%-3d6+12 might print
%-%-3d6+12 = (98+90)-(01-62)-4-2-1+12 = 254
d100 are printed out with %02d format; other numbers are printed with
%d format. I realize that 00 is conventional for 100 on d%, but I'm
printing it as 100 to minimuze confusion.
The sum is printed without spaces to make it easy to extract the result
in a shell script with cut -d' ' -f5.
--
-Colin
/*
* roll.c - FRP die-rolling utility.
* This uses Linux /dev/random for the highest-quality possible random
* numbers. It avoids using any more entropy than necessary (e.g. rolling
* 3d6 has 216 possibilities and requires 1 byte of entropy in the common
* case), and goes to pains to make sure that the results it produces
* are completely free of bias, so the chance of rolling 1 on d6 is
* precisely 1/6.
*
* It also has a (fairly good) emergency backup pseudo-random number
* generator if /dev/urandom isn't available for some reason.
*
* Output is of the form 3d6 = 1+2+3 = 6, so the sum can be picked
* out with cut -d' ' -f5.
*/
#include stdio.h
#include assert.h
#include unistd.h /* For read(), gettimeofday() */
#include fcntl.h /* For open(), O_RDONLY */
#include stdlib.h /* For exit() */
#include sys/time.h /* For struct timeval */
#include limits.h /* For Uxxx_MAX */
#if ULONG_MAX == 0x
typedef unsigned long word32;
#elif UINT_MAX == 0x
typedef unsigned word32;
#elif USHRT_MAX == 0x
typedef unsigned short word32;
#elif UCHAR_MAX == 0x
typedef unsigned char word32;
#else
#error No 32-bit type available!
#endif
struct random_state {
int randfd; /* /dev/urandom. If = 0, the rest is ignored. */
word32 w, x, y, z;
};
/*
* Emergency backup RNG, returns a byte.
* Based on George Marsaglia's KISS generator, except that the two
* MWC components are added together rather than concatenated, since
* this only returns a byte. It also uses the high half of the CONG
* generator and returns the high half of the 16-bit sum.
* is returned.
*
* The period of w is 18000*2^15-1 = 589823999, a prime.
* The period of x is 2^32 = 4294967296
* The period of y is 2^32-1 = 4294967295
* The period of z is 36969*2^15-1 = 1211400191, a prime
* Thus, the total period is 13180436693658741103741078002865274880,
* 1.318e37, a bit over 2^123.
*/
static unsigned
random_kiss(struct random_state *r)
{
/* cycle the generators */
r-w = 18000*(r-w 65535) + (r-w 16); /* Mult with carry */
r-x = 69069*r-x + 1234567;/* Linear congruential */
r-y ^= r-y 17; /* Shift register generator */
r-y ^= r-y 13;
r-y ^= r-y 5;
r-z = 36969*(r-z 65535) + (r-z 16); /* Mult with carry */
/* Join them all together to return. */
return r-w - (r-x16)) ^ r-y) + r-z) 8) 255;
}
/*
* Bob Jenkins' mixing function for 32-bit words.
* Note that this is reversible, and maps zero
* to zero, so it maps non-zero to non-zero.
*/
#define mix(a,b,c) \
{ \
a -= b; a -= c; a ^= (c13); \
b -= c; b -= a; b ^= (a8); \
c -= a; c -= b; c ^= (b13); \
a -= b; a -= c; a ^= (c12); \
b -= c; b -= a; b ^= (a16); \
c -= a; c -= b; c ^= (b5); \
a -= b; a -= c; a ^= (c3); \
b -= c; b -= a; b ^= (a10); \
c -= a; c -= b; c ^= (b15); \
}
/* Start up the random state */
static void
random_init(struct random_state *r)
{
word32 w, x, y, z;
struct timeval tv;
r-randfd = open(/dev/urandom, O_RDONLY);
/* Emergency backup seeding, in case /dev/urandom doesn't work. */
/* Backup seed, good enough for government work. */
gettimeofday(tv, (struct timezone *)0);
w = tv.tv_sec;
x = tv.tv_usec;
z = ((word32)getppid() 16) + (word32)getpid();
mix(w, x, z); /* Shuffle the seed values non-destructively */
/*
* Now ensure that seed constraints are met.
* w should be between 1 and 589823999.
* x can be anything between 0 and 2^32-1.
* y should be between 1 and 2^32-1.
* z
Re: Rolldice 1.1
Colin Plumb [EMAIL PROTECTED] writes: Well, here's a modified version, with a good RNG (a variant of George Marsaglia's highly-regarded KISS generator) stuck in for the cases where /dev/urandom isn't available. It's seeded with gettimeofday(), getpid() and getppid(). Is this part of developing a dpkg-random which installs random packages? I just wondered what it haves to do with debian? Debian-devel is for developer for the Debian Distibution, not for general developer of any kind of free software. -- Peter er den mindst gamle af de gammeldags usenettere, og moderator på den eneste modererede gruppe i dk.*, so there. - citat RockBear
Re: filters: Licence problems
hi Ship's Log, Lt. Edward Betts, Stardate 260199.2004: touch: /bin/cat: Permission denied yeah, happened here too. It's because the un*x version of cat has a multiuser license. You have to register as root for the whole system: 7:36:40~ %sudo touch /bin/cat [EMAIL PROTECTED](p1)[770|1]Wed-27-01-1999 Password: 7:38:06~ % [EMAIL PROTECTED](p1)[771|0]Wed-27-01-1999 works without a prob. I guess it's to keep useres accidently paying for something the sysadmin is responsible. Gretings -- Alexander N. Benner - [EMAIL PROTECTED] - Christian - PHI-Student WEB: http://www.nikodemus.home.pages.de/ IRC: Efnet Nikodemus #Hosanna, #Baptist, #Ixthys ## 82.64% of all statistics are made up !! ##
Re: Rolldice 1.1
On Wed, Jan 27, 1999 at 11:25:46AM +0100, Peter Makholm wrote: I just wondered what it haves to do with debian? Debian-devel is for developer for the Debian Distibution, not for general developer of any kind of free software. Yes, I agree wholeheartedly... since the previous two messages were comments on my program, and not the Debian package of the same, I'd like to apologize for the fact that they were sent to this list as well as to me. Thanks, Stevie -- Stevie Strickland| 325912 Georgia Tech Station [EMAIL PROTECTED] | Georgia Institute of Technology http://computersprache.net/~sstrickl | Atlanta, GA 30332 Official Debian GNU/Linux Developer | PGP/GPG ID = 23A6D909/AE7637D9 PGP Key fingerprint = 84 52 C7 EA E6 DB A1 C5 6A C9 D6 B9 88 26 74 FC GPG Key fingerprint = 3062 4329 AA5C 6095 DB71 AF9A 2A5E C7DE AE76 37D9 pgpHZ1KRcQW4Z.pgp Description: PGP signature
Re: What's needed for kernel 2.2
Hamish Moffatt [EMAIL PROTECTED] writes: On Tue, Jan 26, 1999 at 07:59:29PM +0100, Remco van de Meent wrote: I just discovered, unfortunately, that you need the util-linux package from potato (unstable). Rest of the things in slink are fine with 2.2.0!! Why's that? I'm using the one from slink with 2.2.0 and it works just fine. I've been running 2.2.0-pre6 for a couple of weeks and just upgraded to 2.2.0 last night. I needed it to initialize a 256M swap partition. The old version of mkswap refused to do it. Later, Dale -- +- pgp key available --+ | Dale E. Martin | Clifton Labs, Inc. | Senior Computer Engineer| | [EMAIL PROTECTED]|http://www.clifton-labs.com | +--+
Re: Intent to package: micq
I'm going to pyut my maintainer application in RSN (I have to scan in my license *grumble*) After that, I would like to package micq, which is a text mode icq client, which is in the public domain. I already have preliminary version packaged. A while back I saw someone working on that... but the package never appeared so I guess it is all yours !
Re: ODP: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
I think that this is a good idea (IMHO as u would guess :) . I think that for far too long we have been chopping up our disks for this reason and losing alot of flexibility (and money if not sleep) because of this. I think that Linux needs new ideas in it or it would be just another very good unix but only that. OTOH I don't think I would be able to do it myself :-/ Husain Rafal Pietrak wrote: Hi all, I know that it's a bit out-off-the-line (that is, the solution I'll propose), I don't have anything to add the current */mail* discussion, but please don't flame me, the solution is just an idea that may be somebody from the current discussion audience could take if one likes it. The subject: It looks to me, that everybody cares about mail spool disk usage, so a lot of people put mail spools on a separate partition. In doing so, some people like to have partitions mounted as close to root as possible (the /var/mail variant). IMHO the choice is really quite unimportant, we live with symlinks for quite some time now, and they really serve the purpose of allowing both distributors and admins not to care too much. There is also an issue of best backup schedules that are different for *spool/mail and for *spool/lpd (for example) that make people have spool/mail on a separate partition from spool/other; but this doesn't support my points in the following paragraph, so I leave it alone for now. The actual problem is disk usage management limitation that we have on Unix boxes. Independently of whatever conclusion this FHS discussion on */mail comes to; Probably, it would be quite nice if some kernel guru took a deep breath and think of a subdirectory tree based quotas as an addition to current UID based filesystem quotas and partition size limitations, that today's Unixes provide for disk space management. I think, that if such quotas existed - thus allowing to provide a quota of, say 40MB, within /var/spool/mail for GID=mail and nobody else; and, say 10MB, within /var/spool/lpd to UID=lpd and, say 15MB, within /var/spool/cron to UID=root -- current /var/spool/mail discussion would be much less fierce or even void. For a time, everybody would live with couple of compatibility symlinks around, and since there would be no reason to move any */spool/* around, even those symlinks would disappear soon... I think. -R -- Od: Alan Cox[SMTP:[EMAIL PROTECTED] Wys³any: 26 stycznia 1999 01:16 Do: Theodore Y. Ts'o DW: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; debian-devel@lists.debian.org Temat: Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0 One simple one - I want my mail on the spool disk. Its in the grows randomly, mostly crap, doesnt cause hassle if it fills for a while category
Intent to package Open Source Erlang
Erlang is a pseudo functional language from Ericsson. It has support for con-current and distrubuted programming. erlang-47.4.0 had been released as Open Source last year.
Re: Intent to package: micq
I'm going to pyut my maintainer application in RSN (I have to scan in my license *grumble*) After that, I would like to package micq, which is a text mode icq client, which is in the public domain. I already have preliminary version packaged. Actually, according to the WNPP, Lalo Martins [EMAIL PROTECTED] is working on it. Maybe you should talk to him.
Re: Intent to package wterm
Hi, On Wed, Jan 27, 1999 at 01:06:34AM -0800, Adam Klein wrote: wterm is another Rxvt hack. It is designed for use with Window Maker, although it will work fine with any window manager. It includes transparency, N*XTStep-like scroll bars, and colored shading. Yes!!! Someone bit!!! g A word of caution Adam: PLEASE check out the diff for rxvt. You'll find that: a) There are lots of patches b) Not every patch has been incorporated to upstream rxvt source (read the colourful comments on the debianized source) c) Debian's version of rxvt and upstream's new version don't like each other AT ALL from the patch POV. d) Be prepared for a nightmarish journey regarding configuration. This infamous anonymous coder (that stinks!) seems have 'PropList config files' on his/her TODO list. e) /me hopes you'll package the newest version, which means either Requieres: wmaker (= 0.50.2) (not nice) or Conflicts: wmaker ( 0.50.2). Suggests: wmaker (= 0.50.2) would be nice, too (this program IS intented to work with Window Maker, but it doesn't requiere it). I have NO idea whatsoever as to why it doesn't like older versions of Window Maker. Thanks, this is REALLY appreciated, Marcelo
Re: Uploaded util-linux 2.9g-6 (source i386) to master
We do not officially support the 2.2 kernel in Slink. People who want to use 2.2 will have to compile it themselves and may have to upgrade some packages. But what about shipping an extra directory support_2.2 which contains the kernel packages and the necessary utilities together with the Debian CDs. This will not break the Debian policy but gives every user the chance to try it with its own risk and avoid downloading the things over slow connections. To do so would indicate that Slink officially supports v2.2 of the kernel, which it does not. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Intent to package: olex
[#include not.subscribed.to.debian-devel.h] While doing my necessary daily check of Slashdot and Freshmeat, I noticed two programs I will most likely use - one is irssi, a GTK IRC client that runs in the panel, but I can't package it now because none of my GTK-1.1 stuff is working (figures I'll have to give a nasty day to my poor low bandwidth to fix). If anyone's interested in trying, its homepage is at http://www.sicom.fi/~ikioma/irssi.html (wnpp - this may be added to software that should be packaged) and it's from the guy who originally wrote yagirc. The other is olex, and it's an object-oriented replacement for (lex|flex)/(yacc|bison). Makes full use of classes and ISO C++, so I'll have use for it in my own projects (and it will run in my machine, which is the sweet part) so I'm packaging. It's very alpha and the HP is at http://www.gv.kotnet.org/~jafar/olex/ []s, |alo + -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:[EMAIL PROTECTED] pgp key in the web page Debian GNU/Linux --http://www.debian.org
Looking for someone to take over Imlib
Hey gang, I'm looking for someone to take over the Imlib packages. I have had increasingly less time to work on them, and quite frankly are burning me out. It's an important package now, not just in the domain of Enlightenment, but also in all of GNOME now. Any people interested should be warned that the author (Carsten Haizler, aka the Rasterman/raster), has a tendency to burn out debian maintainers ;) It's not a excruciatingly difficult package, I have two normal bugs open on it, and one wishlist. People who are interested in it should have some measure of free time, as it's updated fairly frequently, and as I mentioned, GNOME is heavily dependent upon it. On a related note, I am going to hand over my fnlib and stringlist packages to Steve Baker (sbaker or fantumn on IRC), as soon as he completes the new maintainer application process. Hope I haven't scared off everyone =) Thanks, Brian -- Brian Almeida [EMAIL PROTECTED] Debian GNU/Linux Developer http://www.debian.org PGP Key: 0x3A800C65
Re: Intent to package wterm
On Wed, Jan 27, 1999 at 08:17:39AM -0600, Marcelo E. Magallon wrote: Hi, On Wed, Jan 27, 1999 at 01:06:34AM -0800, Adam Klein wrote: wterm is another Rxvt hack. It is designed for use with Window Maker, although it will work fine with any window manager. It includes transparency, N*XTStep-like scroll bars, and colored shading. Yes!!! Someone bit!!! g A word of caution Adam: PLEASE check out the diff for rxvt. You'll find that: a) There are lots of patches b) Not every patch has been incorporated to upstream rxvt source (read the colourful comments on the debianized source) Hmm? I got the source from the Largo's site, and it's not distributed as a patch, but a full source tree. Have these patches been included upstream? I'm packaging anonymous coder's version, rather than Alfredo. c) Debian's version of rxvt and upstream's new version don't like each other AT ALL from the patch POV. Debian's version is pretty old. It's based on the last stable version, but it's been extensively patched. Adam
Re: Intent to package wterm
On Wed, Jan 27, 1999 at 08:40:47AM -0800, Adam Klein wrote: On Wed, Jan 27, 1999 at 08:17:39AM -0600, Marcelo E. Magallon wrote: Hi, On Wed, Jan 27, 1999 at 01:06:34AM -0800, Adam Klein wrote: wterm is another Rxvt hack. It is designed for use with Window Maker, although it will work fine with any window manager. It includes transparency, N*XTStep-like scroll bars, and colored shading. Yes!!! Someone bit!!! g A word of caution Adam: PLEASE check out the diff for rxvt. You'll find that: a) There are lots of patches b) Not every patch has been incorporated to upstream rxvt source (read the colourful comments on the debianized source) Hmm? I got the source from the Largo's site, and it's not distributed as a patch, but a full source tree. Have these patches been included upstream? I'm packaging anonymous coder's version, rather than Alfredo. I mean the debian patches. Some of them are incorporated upstream, some are not. Marcelo
Re: Bug#29352: Emacs postrm doesn't remove its site-lisp directory
[EMAIL PROTECTED] (Julian Gilbey) writes:
When emacs20 is de-installed or upgraded to a version with a different
minor number, the /usr/share/emacs/20.x directory will probably not be
removed as there will most likely be some junk left in it by other
packages. Since the directory is then defunct, the postrm script
should probably finish with
rm -rf /usr/share/emacs/${MAJOR}.${MINOR} || true
exit 0
OK, so presuming that this is the right thing to do, where is the safe
place to do it? I want to make sure I only remove this directory
after any other packages that need its contents during their removal
are finished (i.e. add-on packages). This would seem to indicate that
the right place would be the postrm, however, I noticed that I've got
the removal code for /usr/local in the prerm right now:
(rmdir /usr/local/share/emacs/${FULL}/site-lisp 2/dev/null \
rmdir /usr/local/share/emacs/${FULL} 2/dev/null) || true
and as I recall I was pretty careful to try and make sure to put
things in the right files/order when I originally set this stuff up.
So which should it be for the rm -rf major.minor, prerm, or postrm?
--
Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Re: Intent to package: Xconfigurator
While at it, why not add monitor detection, like windows can do? Date: Wed, 27 Jan 1999 01:23:29 -0500 From: Branden Robinson [EMAIL PROTECTED] To: debian-devel@lists.debian.org Cc: [EMAIL PROTECTED] Subject: Re: Intent to package: Xconfigurator On Tue, Jan 26, 1999 at 08:22:08PM -0600, Stephen Crowley wrote: I know some of you may want to shoot me but Xconfigurator is the redhat Xfree configuration utility, it's a hacked up xf86config that scans the pci bus to auto-detect the vid card, has a monitor database, and has a nice looking slang interface too. It will need a quite a few modifications to work with debian so I'm wondering if I should just split the tree and make my own version. Any comments? Uh, I was kind of planning on recruiting some folks to rip that thing open and Debianizing it for the potato release. I already have the latest Red Hat diffs in my X work directory on various machines, and was going to go through them for potato X. I'm just still working on kicking slink X out of the nest. Would you mind doing this work under the umbrella of the X Strike Force? I'd like to ship the X configurator in xserver-common once it's ready for prime time. == Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Looking for someone to take over Imlib
Hi Brian, If no one else will take your Imlib packages, I will. Let me know what you think. Thanks, -Ossama On Wed, 27 Jan 1999, Brian Almeida wrote: Hey gang, I'm looking for someone to take over the Imlib packages. I have had increasingly less time to work on them, and quite frankly are burning me out. It's an important package now, not just in the domain of Enlightenment, but also in all of GNOME now. Any people interested should be warned that the author (Carsten Haizler, aka the Rasterman/raster), has a tendency to burn out debian maintainers ;) It's not a excruciatingly difficult package, I have two normal bugs open on it, and one wishlist. People who are interested in it should have some measure of free time, as it's updated fairly frequently, and as I mentioned, GNOME is heavily dependent upon it. On a related note, I am going to hand over my fnlib and stringlist packages to Steve Baker (sbaker or fantumn on IRC), as soon as he completes the new maintainer application process. Hope I haven't scared off everyone =) Thanks, Brian -- Brian Almeida [EMAIL PROTECTED] Debian GNU/Linux Developer http://www.debian.org PGP Key: 0x3A800C65 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Platforms Four
I just committed the final platform to the web source CVS. By this evening, it should be up on www.debian.org and tomarrow the major mirrors should have it. Once again, the link is http://vote.debian.org/1999/vote_0001 -- = * http://benham.net/index.html * * * -BEGIN GEEK CODE BLOCK- ---* *Darren Benham * Version: 3.1 * * [EMAIL PROTECTED] * GCS d+(-) s:+ a29 C++$ UL++ P+++$ L++* * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- * * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++ * * [EMAIL PROTECTED] * G++G+++ e h+ r* y+* * * --END GEEK CODE BLOCK-- ---* = pgpWa5g3mwcKn.pgp Description: PGP signature
Two imlib maintainers on package maintainer list
Hi, There are two imlib maintainers listed on the People Behind Debian web page, Brian and Shaleh. Is that right? :) Thanks, -Ossama __ Ossama Othman [EMAIL PROTECTED] 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: Uploaded util-linux 2.9g-6 (source i386) to master
On Wed, 27 Jan 1999, Brian White wrote: To do so would indicate that Slink officially supports v2.2 of the kernel, which it does not. What about a README file that says: No, Debian doesn't officially support 2.2, but for those people who hadn't enough bandwidth but enough courage here are the sources. Kind regards Andreas.
Re: Two imlib maintainers on package maintainer list
On Wed, Jan 27, 1999 at 12:14:57PM -0600, Ossama Othman wrote: There are two imlib maintainers listed on the People Behind Debian web page, Brian and Shaleh. Is that right? :) No. Shaleh was the maintainer before me.
Re: Looking for someone to take over Imlib
On Wed, Jan 27, 1999 at 11:57:39AM -0600, Ossama Othman wrote: If no one else will take your Imlib packages, I will. Let me know what you think. They're yours.
RE: Two imlib maintainers on package maintainer list
On 27-Jan-99 Ossama Othman wrote: Hi, There are two imlib maintainers listed on the People Behind Debian web page, Brian and Shaleh. Is that right? :) Thanks, -Ossama The right answer is hell no (= The detailed answer is I used to maintain it and hamm still contains the packages I uploaded.
Re: Intent to package: Xconfigurator
On Wed, Jan 27, 1999 at 09:40:18AM -0800, Kenneth Scharf wrote: While at it, why not add monitor detection, like windows can do? I plan on doing that, but the VESA DDC specifications are not freely available, I'm going to call VESA today and see if I can find out anything about the specs, I would have used their website but it sucks. -- Stephen Crowley [EMAIL PROTECTED], [EMAIL PROTECTED] -* Finger [EMAIL PROTECTED] for my public key. PGP#22714B25 *-
RE: Two imlib maintainers on package maintainer list
Hi, The right answer is hell no (= I get the feeling nobody wants these packages. Did I just make a boneheaded move by accepting the Imlib packages? :) -Ossama __ Ossama Othman [EMAIL PROTECTED] 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
RE: Two imlib maintainers on package maintainer list
On Wed, 27 Jan 1999, Ossama Othman wrote: I get the feeling nobody wants these packages. Did I just make a boneheaded move by accepting the Imlib packages? :) I'm very happy that you took the package, because I'm heavyly dependend from it. In my humble opinion maintaining is not so hard, because the program compiled well in all version I compiled myself (sometimes there where reasons despite the Debian packaging...). Thanks for maintaining this package Andreas.
-rpath with libtool and Debian Linux
I'm bringing this conversation (with permission) to debian-devel@lists.debian.org because my knowledge of how -rpath works is limited. To recap, for the Debian folks: libtool, a tool for creating libraries and linking programs with those libraries on multiple platforms, forces all programs it links to be linked with the -rpath option, which hard-codes the path to the library being linked with into the binary. This is bad for Debian, because in all binary packaging systems, shared libraries can and will be moved around from time to time, as policy and major upgrades (like libc5 - libc6) mandate. However, Alexandre Oliva [EMAIL PROTECTED] brings up an important point: -rpath is necessary if one is installing libraries and binaries linked to those libraries in one's home directory, or if your Unix has no support for library search paths via environment variables like Linux's LD_LIBRARY_PATH. Basically, I have been asking Alexandre if it's possible to add a --no-rpath option to libtool when calling it to tell it to not use -rpath when linking binaries, but he refused, saying he'd have to port that to 'hundreds of platforms'. Can someone with more knowledge of -rpath and libtool than I explain why Debian policy mandates avoiding -rpath? Thanks, Ben -- Brought to you by the letters C and O and the number 14. Porcoga daisuki! Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox. --- Start of forwarded message --- To: Ben Gertzfield [EMAIL PROTECTED] Cc: Manish Singh [EMAIL PROTECTED], [EMAIL PROTECTED], James Troup [EMAIL PROTECTED] Subject: Re: [gimp-devel] gimp1.1 rpath hell References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] From: Alexandre Oliva [EMAIL PROTECTED] Date: 27 Jan 1999 01:16:59 -0200 Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 On Jan 27, 1999, Ben Gertzfield [EMAIL PROTECTED] wrote: Alexandre Or just fix ld.so so that, if a program or library Alexandre depends on libc.so.5, it shouldn't even try to use Alexandre libc.so.6, and vice-versa. If we move the libraries, any program that is compiled with -rpath WILL NO LONGER WORK. Period. You shouldn't move shared libraries. Period :-) If the particular version of libX11.so was linked with depends on libc.so.5, ld.so should use it. I don't see any need for a separate directory for libraries, if library versioning would work correctly. This has happened before with Debian, as emacs was compiled with -rpath /usr/X11R6/lib to force the X libraries to be stored there. If libraries are not found in the -rpath, they should be searched in the default search directories. Aren't they? -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil --- End of forwarded message ---
RE: Two imlib maintainers on package maintainer list
On 27-Jan-99 Ossama Othman wrote: Hi, The right answer is hell no (= I get the feeling nobody wants these packages. Did I just make a boneheaded move by accepting the Imlib packages? :) -Ossama Raster and I had philosophical differences, which made the maintainer/author relationship hard. Give it a shot, if you can't do it someone else will step in.
Re: Two imlib maintainers on package maintainer list
On Wed, Jan 27, 1999 at 01:53:44PM -0500, Shaleh wrote: Raster and I had philosophical differences, which made the maintainer/author relationship hard. Give it a shot, if you can't do it someone else will step in. Same reason here. Just took me a few months to really realize it =)
Intent to package xfntbase, xfnt75, etc.
Hi. I intend to package all the dummy packages we have been talking about. They match the packages that changed its name in the great X reorganization. My rationale for creating these packages is the following: *) Since dselect's default behaviour is to upgrade everything, most people *will* expect the old X packages to be updated automatically. Since the packages changed their names, dselect does not do what it is expected to do, so these packages will fill the gap between the old and the new packages. *) We have discussed enough, it's time to do something positive so that this issue is solved as soon as possible. I'm open to all these type of objections, which I order according to their likelihood: * (From Branden Robinson) Ok, don't worry, I think I should be the one to do it, since I'm the X maintainer. * (From Branden Robinson) Ok, I will rename the X packages back, so that a hamm user will never notice that these packages had a different name during the frozen stage of slink. I will just postpone the renaming until it is supported by the packaging system appropiately. * (From Ian Jackson) Ok, I used the time machine :-) and changed the past, now hamm's dpkg allows package renaming just by using the new `Alias:' field, so it may already be used in all the packages in slink needing it. I would consider the following objections not acceptable: [ I include the reasons for which I consider them unacceptable ] * You should not create them because they are useless. Not true, since lot of people expect the old packages to be upgraded by the new ones automatically, these packages are exactly which is needed (with existing tools) so that the upgrade is done automatically. * Don't do it, they are ugly. Having an ugly thing does not mean it may not be useful as well. Functionality is more important than aesthetics. * Trying to emulate dselect's behaviour (by forcing the upgrade of all the packages) is wrong. If upgrade everything is not what dselect should do, what is it supposed to do, then? Where is the bug against dselect for its wrong behaviour? * There should be some better way. Fine. Which one? Thanks. -- 88d678e67ef37f67fb75dd7e51f24816 (a truly random sig)
Re: Two imlib maintainers on package maintainer list
On Wed, Jan 27, 1999 at 07:41:45PM +0100, Andreas Tille wrote: I'm very happy that you took the package, because I'm heavyly dependend from it. In my humble opinion maintaining is not so hard, because the program compiled well in all version I compiled myself (sometimes there where reasons despite the Debian packaging...). No, the maintaining of it is not hard. Compiles cleanly and no major hacks are required to the source. I just didn't necessarily agree with the author on all things...;) That and it's hard for me to test / debug gnome stuff because I refuse to use it. (Let's not go there, please =) Brian
Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, Ben Gertzfield [EMAIL PROTECTED] wrote: This is bad for Debian, because in all binary packaging systems, shared libraries can and will be moved around from time to time, as policy and major upgrades (like libc5 - libc6) mandate. You might have included my suggestion to prevent having to move libraries in the first place: creating a libc6-specific directory right now, instead of installing libraries in /usr/lib and having to move them into another directory when libc7 should be released. However, Alexandre Oliva [EMAIL PROTECTED] brings up an important point: -rpath is necessary if one is installing libraries and binaries linked to those libraries in one's home directory, or if your Unix has no support for library search paths via environment variables like Linux's LD_LIBRARY_PATH. More than that (and it was my fault to have failed to mention that before): libtool will hard-code the installation directory of the library into the `libdir' variable of the .la script it installs. Therefore, if one moves the library then tries to link with the .la file, he loses. There's also the dlopening issue: libltdl (to be released with libtool 1.3) will dlopen a library in the directory pointed to by `libdir' too. In general, I feel that moving libraries around is a very bad idea, because it will lead to failure most of the times, and that's why I don't feel libtool should help people doing that. Basically, I have been asking Alexandre if it's possible to add a --no-rpath option to libtool when calling it to tell it to not use -rpath when linking binaries, but he refused, saying he'd have to port that to 'hundreds of platforms'. Actually, not issuing -rpath or equivalent is quite easy to do, but choosing *when* not to do it is the part that is hard to port. Thomas Tanner has suggested that we could omit the -rpath switch for libraries that are supposed to be installed in directories listed in the default search path. However, the default search PATH might change, and, even if it did not, it would be possible to link an application with a library in, say, /usr/local/lib, and then find out that at run-time it loads a library with the same name in /usr/lib, because /usr/lib appears first in the standard search path. The other issue is *how* to specify that -rpath should be ommitted. Should it be a configure option, that would permanently disable any -rpath switches? Or should it be an additional argument to the libtool script at program-linking time? Or should it be specified at library linking time, with one of three options: hardcode path in the library, hardcode path in any program linked with it, or do not hardcode path at all? Or something else? What to do on a platform that doesn't support the requested hardcoding strategy? The issue is very complex because we can't think just of GNU/Linux with all its bells and whistles, because libtool is supposed to present an homogeneous, portable interface to creating libraries. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: Reality check! [was: Re: Debian goes big business?]
Enrique Zanardi [EMAIL PROTECTED] writes: On Sun, Jan 24, 1999 at 01:32:28PM -0700, John Lapeyre wrote: I guess I should add this to my last post about how bad the installation is. The boot floppies themselves and apt are quite good. Getting the base system on is easy for someone who knows what is going on. Probably not for a beginner. Suggestions for making the boot-floppies beginner-friendly are welcome (but read the todo list first). Of course, code is even more welcome. :-) The boot floppies are excellent for what they intend to do. They try to provide maximum flexibility, and then to be as friendly as possible. Perhaps a clueless-proof install should be on a separate disk. I won't say anymore, because I have not installed RH ors SuSE recently, and have no concrete suggestions. Also, in retrospect, I should have realized that picking the scientific workstation option could cause problems . That was over 500 packages . This is a severe test for any OS. -- John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Intent to package: PARI/GP and STL Documentation
Hi there, first of all: I'd say hello to every volunteer working for debian - great project, nice system. Thank you all. After using debian since 0.93R6 I just started to learn something more about creating packages and how to help the debian development. There are two things I'd like to add to the debian distribution, but before becoming a new maintainer, I'd practice the creation of packages. There are (at least) two more debs I'd like to see in debian: First is the PARI/GP library (a C library for number theory, to be short), it was included in the 1.something release of debian and is gone now -- anybody knows why? Second the html-documentation of the Standard Template Library. I saw this on WNPP an wrote an email to the maintainer, but did not get any answer. The status of my packaging: stl-doc is ok (lintian reports no errors), the library package of PARI/GP is somewhat harder: After reading all available documentation and building a simple libhello-package (you all know what's that for ;-), I started to build a debian-package from the pari sources. It works, I get 4 binary-debs from the source: the shared library, one static lib with header files, one static lib with debug info and, last not least, one deb containing the binary gp (some shell on top of libpari). libpari1_2.0.13.alpha-1_i386.deb libpari1-dev_2.0.13.alpha-1_i386.deb libpari1-dbg_2.0.13.alpha-1_i386.deb gp_2.0.13.alpha-1_i386.deb There is one big problem where I need help. First of all, there's some strange output of lintian: E: libpari1: shlib-with-non-pic-code usr/lib/libpari.so.2.0.13 I watched the complete build-process: _Every_ source file is compiled with gcc -c -O3 -fPIC -fexpensive-optimizations -malign-loops=2 \ -malign-jumps=2 -malign-functions=2 sourcefile.c the linkage is done with: gcc -shared -Wl,soname libpari.so.2 -o libpari.so.2.0.13 ... object files [ gcc is 2.7.2.3, taken from frozen ] When I do objdump on the .o-files (like lintian does it), there's no .rel.text-entry. When I link them together to get the library and do objdump on the library, I get: 3 .rel.text 0068 b768 b768 b768 2**2 And (as you expected), lintian reports the error above. Any idea how this could happen? Anyway, I need some help with the licenses. Before posting many lines of copyrights, licenses and readmes here, I would like to ask if this is done better on debian-mentors? After all, I did not yet get through the new maintainer-registration and have some questions to those issues, too. My PGP-Key is signed by c't (german computer magazine), is this ok to verify my real-life identity? Thanks for listening and any help, Jonas -- OS/2? Hah. I've got Linux. What a cool name (Linus Torvalds)
struct iface
Does anyone know where is the struct iface definition for the networking code?. The structure ifaddr has a pointer to it but i can't find it.
Re: -rpath with libtool and Debian Linux
On Wed, Jan 27, 1999 at 17:07:30 -0200, Alexandre Oliva wrote: You might have included my suggestion to prevent having to move libraries in the first place: creating a libc6-specific directory right now, instead of installing libraries in /usr/lib and having to move them into another directory when libc7 should be released. I'm sorry, but this is IMHO completely backwards. On Linux systems, there is nothing wrong with moving libraries around as the need arises. Having libtool default to -rpath is what's causing problems. I've seen one too many instances of foo crashes on Debian that turned out to be foo is a libc5 binary with an RPATH of /usr/X11R6/lib which on any reasonably up to date Debian system contains libc6 X libraries. The X example also shows that the problem isn't limited to /usr/lib either. What's next? /usr/local/lib/libc6 ? However, Alexandre Oliva [EMAIL PROTECTED] brings up an important point: -rpath is necessary if one is installing libraries and binaries linked to those libraries in one's home directory, That is a special case. The default should be sane for regular cases. or if your Unix has no support for library search paths via environment variables like Linux's LD_LIBRARY_PATH. While I appreciate concerns about supporting less fortunate operating environments, I don't think their existence should hold us back from doing the right thing on Linux. In general, I feel that moving libraries around is a very bad idea, because it will lead to failure most of the times, and that's why I don't feel libtool should help people doing that. I see no reason why moving libraries around is a bad idea. I see defaulting to -rpath as a bad idea, which breaks moving libraries around. Ray -- POPULATION EXPLOSION Unique in human experience, an event which happened yesterday but which everyone swears won't happen until tomorrow. - The Hipcrime Vocab by Chad C. Mulligan
Re: Intent to package: olex
[#include not.subscribed.to.these.lists.please.cc.replies.h] Shaleh hinted that I might want to look at the Olex license. It does put some restriction on output - which, differently from the buttonware discussion a while ago, seems legitimate to me since Olex output is full of code written by the Olex author. So, this is the actual LICENSE.GENERATED file: This license applies to the source olex generates and to both the LookAhead.cc and the LookAhead.h file in this package. You may - apply the GNU Public License. See the LICENSE file that came with this package. - apply the Artistic License as distributed with the most current Perl. See http://language.perl.com/misc/Artistic.html. - apply a different license provided that any user reasonably has access to the source code of the original olex file. That she/he is allowed to make changes to the original olex file. That she/he is allowed to compile this patched olex file and that she/he can relink the resulting object files with your application, either statically or dynamically. That she/he is allowed to distribute the resulting binary, the intermediate object files, the changes to the olex file and the original to other parties who will receive the same rights. Is this ok for main? Should I print a warning, or even maybe add it to the package description? []s, |alo + -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:[EMAIL PROTECTED] pgp key in the web page Debian GNU/Linux --http://www.debian.org
spectremu - zx spectrum emulator.
Hi, my name is John Travers, I have been using debian for about 8 months and have also been using a zx spectrum emulator called spectremu. It is distributed under the GNU GPL. I was wondering if anyone was packaging this (they are not according to the docs) and if not if you think it a good idea if I did. regards, John Travers More than just email--Get your FREE Netscape WebMail account today at http://home.netscape.com/netcenter/mail
Re: -rpath with libtool and Debian Linux
Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes: Alexandre You might have included my suggestion to prevent having Alexandre to move libraries in the first place: creating a Alexandre libc6-specific directory right now, instead of Alexandre installing libraries in /usr/lib and having to move Alexandre them into another directory when libc7 should be Alexandre released. This is rather frustrating, because then we will need to make a /lib/libc6, /usr/lib/libc6, /usr/X11R6/libc6, /usr/local/lib/libc6.. it never ends. :) Alexandre More than that (and it was my fault to have failed to Alexandre mention that before): libtool will hard-code the Alexandre installation directory of the library into the `libdir' Alexandre variable of the .la script it installs. Therefore, if Alexandre one moves the library then tries to link with the .la Alexandre file, he loses. There's also the dlopening issue: Alexandre libltdl (to be released with libtool 1.3) will dlopen a Alexandre library in the directory pointed to by `libdir' too. I've never understood what the .la scripts are for. Why are they installed into /usr/lib/, where libraries live? This is kind of off-the-subject, but they have always confused me, and I delete them out of any libtool-using library package I maintain. Alexandre In general, I feel that moving libraries around is a Alexandre very bad idea, because it will lead to failure most of Alexandre the times, and that's why I don't feel libtool should Alexandre help people doing that. With Debian and Red Hat, it's totally the opposite. Moving libraries around is what leads to upgrades being possible. Alexandre The issue is very complex because we can't think just Alexandre of GNU/Linux with all its bells and whistles, because Alexandre libtool is supposed to present an homogeneous, portable Alexandre interface to creating libraries. Totally agreed. You are worrying just a bit too much about this, though -- we don't need to worry about a switch that has to decide WHEN to disable -rpath, just a switch that understands, Okay, the builder knows what he's talking about, no -rpath is fine with me. Ben -- Brought to you by the letters V and D and the number 3. Porcoga daisuki! Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.
Re: Intent to package: olex
I decided not to package or help this project because of the original license -- either GPL your code or dont use Olex. The author is a good guy and is just trying to promote free software and make sure his work is not used to make proprietary software. I think this license is free enough. The output code is similar to using a library. If the library was gpl, you could only use it in a compatible fashion -- this is like that.
Re: spectremu - zx spectrum emulator.
On Wed, Jan 27, 1999 at 07:41:42PM +, John Travers wrote: have also been using a zx spectrum emulator called spectremu. Does it have an URL? It is distributed under the GNU GPL. Great. if not if you think it a good idea if I did. Please do. Remember to read the Policy Manual, Developer's Reference and Packaging manual first, if you haven't already. You can find them at the Developer's Corner of the Debian website. Antti-Juhani -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% EMACS, n.: Emacs May Allow Customised Screwups (unknown origin)
Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, J.H.M. Dassen [EMAIL PROTECTED] wrote: On Wed, Jan 27, 1999 at 17:07:30 -0200, Alexandre Oliva wrote: You might have included my suggestion to prevent having to move libraries in the first place: creating a libc6-specific directory right now, instead of installing libraries in /usr/lib and having to move them into another directory when libc7 should be released. I'm sorry, but this is IMHO completely backwards. On Linux systems, there is nothing wrong with moving libraries around as the need arises. Except that you risk replacing a library with an incompatible one. That's what has caused you so much trouble. If, instead of moving the X11 libraries to another dir and creating new, incompatible versions under the same pathname, you had created new versions in other directories, no unexpected crashes would have occurred. Having libtool default to -rpath is what's causing problems. This is IMHO completely backwards :-) When a program is linked with a shared library, a contract is established between them stating that the library (or any newer but compatible version thereof, on systems that support library versioning) will supply the symbols that the program resolved from it, and the program will be able to find the library at that point. If you move the library and replace it with an incompatible one, you're breaking the contract and the versioning mechanism, so you can't blame the program for crashing, nor the tool that created the program. I've seen one too many instances of foo crashes on Debian that turned out to be foo is a libc5 binary with an RPATH of /usr/X11R6/lib which on any reasonably up to date Debian system contains libc6 X libraries. See? You replaced one library with an incompatible one without modifying its version number to mark it as incompatible. Isn't this breaking the contract? How could you expect it to work? The X example also shows that the problem isn't limited to /usr/lib either. What's next? /usr/local/lib/libc6 ? Maybe some library versioning mechanism that allows incompatible changes to be marked as such. Maybe an environment variable or some file in /etc containing a number that will be added to the major version number of any library libtool creates, so that they will be marked as incompatible. However, Alexandre Oliva [EMAIL PROTECTED] brings up an important point: -rpath is necessary if one is installing libraries and binaries linked to those libraries in one's home directory, That is a special case. The default should be sane for regular cases. You see the regular case as the one you use the most. I see it as the one I use the most. I don't install any packages in /usr or /usr/local because I find it *horrible* to have a huge /usr/local/bin without any clear separation between packages. It's a pity that the GNU/Linux distributions don't care about clearly separating packages from one another... or if your Unix has no support for library search paths via environment variables like Linux's LD_LIBRARY_PATH. While I appreciate concerns about supporting less fortunate operating environments, I don't think their existence should hold us back from doing the right thing on Linux. For which definition of the right thing? :-) In general, I feel that moving libraries around is a very bad idea, because it will lead to failure most of the times, and that's why I don't feel libtool should help people doing that. I see no reason why moving libraries around is a bad idea. I see defaulting to -rpath as a bad idea, which breaks moving libraries around. Because you break a contract every time you remove a library from the place in which it used to live. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
Re: Intent to package: PARI/GP and STL Documentation
On Wed, Jan 27, 1999 at 08:19:35PM +0100, Jonas Rathert wrote: Second the html-documentation of the Standard Template Library. I saw this on WNPP an wrote an email to the maintainer, but did not get any answer. Do you mean this? [EMAIL PROTECTED]:58:40]:~$ dpkg -s stl-manual Package: stl-manual Status: install ok installed Priority: optional Section: doc Installed-Size: 3249 Maintainer: Heiko Schlittermann [EMAIL PROTECTED] Version: 3.11-3 Suggests: web-browser Description: C++-STL documentation in HTML This is the documentation for the C++ Standard Template Library as found on SGIs Website. [EMAIL PROTECTED]:58:47]:~$ This is already packaged. Anyway, I need some help with the licenses. Before posting many lines of copyrights, licenses and readmes here, I would like to ask if this is done better on debian-mentors? debian-legal is meant for the license stuff. Antti-Juhani -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% EMACS, n.: Emacs May Allow Customised Screwups (unknown origin)
Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, Ben Gertzfield [EMAIL PROTECTED] wrote: I've never understood what the .la scripts are for. They contain inter-library dependency information, the location and the name of the actual library, and any additional run-time paths needed for the library dependencies. libtool (1.2d) is able to link with an installed .la file, meaning that it will select the appropriate switches to link the library, its dependencies and its run-time paths into the program or libtool library being linked. .la files are also used by libltdl, a portable dlopening library that is available in the current libtool CVS tree, and that will be released with libtool 1.3. libltdl will use the .la file to find out the pathname of the file to be dlopened, as well as any dependencies that must be dlopened before the library. It is possible that libtool 1.3 will be able to find and use .la files even when -L and -l switches are used to refer to it (currently it requires the pathname of the .la file). With Debian and Red Hat, it's totally the opposite. Moving libraries around is what leads to upgrades being possible. Then why do you find so much trouble with it? Totally agreed. You are worrying just a bit too much about this, though -- we don't need to worry about a switch that has to decide WHEN to disable -rpath, just a switch that understands, Okay, the builder knows what he's talking about, no -rpath is fine with me. In this case, you already have the suggestion of the ld wrapper script, right? :-) The point is that, if we support this flag, it must be supported in a portable way, otherwise GNU/Linux developers may feel inclined to enable it by default in the packages they maintain, and this will result in their packages *having* to be installed with --prefix=/usr/local, and even then, they will only work on GNU/Linux. I want to avoid this situation at all costs. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
GNOME in potato needs slink libs
Hi guys, Another quick question... Why does potato's GNOME require slink's gtk/gnome/etc libs? -Ossama __ Ossama Othman [EMAIL PROTECTED] 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: GNOME in potato needs slink libs
On Wed, 27 Jan 1999, Ossama Othman wrote: Hi guys, Another quick question... Why does potato's GNOME require slink's gtk/gnome/etc libs? Because potato is not yet a complete distribution, and should be 'overlayed' over slink? /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: spectremu - zx spectrum emulator.
On Wed, Jan 27, 1999 at 09:56:10PM +0200, Antti-Juhani Kaijanaho wrote: Please do. Remember to read the Policy Manual, Developer's Reference and Packaging manual first, if you haven't already. You can find them at the Developer's Corner of the Debian website. And the new maintainers' guide, if I may say so :) -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: GNOME in potato needs slink libs
Hi Jules, Another quick question... Why does potato's GNOME require slink's gtk/gnome/etc libs? Because potato is not yet a complete distribution, and should be 'overlayed' over slink? Ah, I see. I did a clean potato installation, i.e. not over slink. Anyone have any idea when GNOME for potato will be updated? No rush or complaints, I'm just curious since I want to test the imlib packages on potato's GNOME once I start releasing imlib package updates. Thank you much, -Ossama __ Ossama Othman [EMAIL PROTECTED] 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
slink machine available for compiling and abuse
Hi all, I just setup a VAIO laptop running Slink. It is 100% pure slink. If anyone needs a package recompiled, I will gladly do so and upload it for you. I can also do some testing of package installs, although that could be more limited as I actually need to USE this laptop. I have a huge oc3 type connection at school and a T1 at work, so bandwidth is not an issue. My goal is to leave this laptop as one release behind. This way I can continue doing this. As long as the needed laptop packages continue, I do not see a problem with this.
slink needs pcmcia-cs version 3.0.8 to support 2.2 kernels
I am glad slink will ship with 2.2. However laptop users need a new version of the pcmcia packages for this to work. I can make an nmu if needed. See my previous email.
Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote: Having libtool default to -rpath is what's causing problems. This is IMHO completely backwards :-) When a program is linked with a shared library, a contract is established between them stating that the library (or any newer but compatible version thereof, on systems that support library versioning) will supply the symbols that the program resolved from it, and the program will be able to find the library at that point. If you move the library and replace it with an incompatible one, you're breaking the contract and the versioning mechanism, so you can't blame the program for crashing, nor the tool that created the program. The contract does not state that the library will be found in a particular location on the filesystem hierarchy. The contract simply states that the library will be found. Which library is used can be determined by the linker. Where is the need for rpath here? The combination of library versions uniquely identifies, to a suitably well configured linker, which library to find. I've seen one too many instances of foo crashes on Debian that turned out to be foo is a libc5 binary with an RPATH of /usr/X11R6/lib which on any reasonably up to date Debian system contains libc6 X libraries. See? You replaced one library with an incompatible one without modifying its version number to mark it as incompatible. Isn't this breaking the contract? How could you expect it to work? It did work. On all binaries without -rpath. It worked. What do you mean, 'How could we expect it to work?' However, Alexandre Oliva [EMAIL PROTECTED] brings up an important point: -rpath is necessary if one is installing libraries and binaries linked to those libraries in one's home directory, That is a special case. The default should be sane for regular cases. You see the regular case as the one you use the most. I see it as the one I use the most. I don't install any packages in /usr or /usr/local because I find it *horrible* to have a huge /usr/local/bin without any clear separation between packages. It's a pity that the GNU/Linux distributions don't care about clearly separating packages from one another... I'm sorry, but I'm flabbergasted. To think that the person in charge of libtool actively disagrees with a) The whole point of packaging systems b) The FHS Our distribution cares greatly about separating packages from each other. And it does it very well. There is no need to acheive this by enforcing such package structure on the file-system - which package a file belongs to is a concept orthogonal to where the file lives in a sensible filesystem. Worried, Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: GNOME in potato needs slink libs
On Wed, 27 Jan 1999, Ossama Othman wrote: Hi Jules, Another quick question... Why does potato's GNOME require slink's gtk/gnome/etc libs? Because potato is not yet a complete distribution, and should be 'overlayed' over slink? Ah, I see. I did a clean potato installation, i.e. not over slink. Anyone have any idea when GNOME for potato will be updated? No rush or complaints, I'm just curious since I want to test the imlib packages on potato's GNOME once I start releasing imlib package updates. I have almost all of GNOME 0.99 propogated to my mirror now. The only missing link is libgtop0. So, soon, would be my guess. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, Jules Bean [EMAIL PROTECTED] wrote: On 27 Jan 1999, Alexandre Oliva wrote: Having libtool default to -rpath is what's causing problems. This is IMHO completely backwards :-) When a program is linked with a shared library, a contract is established [...] If you move the library and replace it with an incompatible one, you're breaking the contract and the versioning mechanism, so you can't blame the program for crashing, nor the tool that created the program. The contract does not state that the library will be found in a particular location on the filesystem hierarchy. Correct. The contract simply states that the library will be found. Which library is used can be determined by the linker. Except that, if you replace the library with an incompatible one, you *are* breaking the contract. Furthermore, there's no reason to assume that the user will *not* have used -rpath himself, so moving libraries does have a potential for breaking user programs, therefore it should best be avoided. Where is the need for rpath here? There's no need for it, but it doesn't cause any harm unless you break the rules, i.e., replace a library with an incompatible one that holds an apparently compatible version number. *This* is the root of all your problems, not that fact that a rpath is specified. If you had not replaced libraries with incompatible versions, the dynamic linker would not have found it in the hard-coded rpath and would look for it in the default search path, and find it in the appropriate alternate location. See? You replaced one library with an incompatible one without modifying its version number to mark it as incompatible. Isn't this breaking the contract? How could you expect it to work? It did work. On all binaries without -rpath. It worked. What do you mean, 'How could we expect it to work?' Except for this `minor' restriction. You may be silently breaking *user* programs because they have chosed to specify -rpath where it was not necessary. If you think people *must not* use -rpath on your system, you'd better completely disable it, not blame the user for making use of a (IMO nice) feature of your system. I think a solution that is not general is not a good solution. Since the solution of moving shared libraries around has the potential of causing problems, if I were you, I'd work harder to try to find a complete solution (which I happen to have already suggested) instead of trying to blame libtool or other users for doing things that are perfectly correct, but not in the way that would let you replace incompatible libraries. Our distribution cares greatly about separating packages from each other. Not from the point of view of the end user. When they want to find a tool, they may `ls /usr/bin /usr/local/bin' and will be presented *thousands* of files. I'd rather have a classification system in which I could have links (or similar) to all programs in a common directory, but in which I could search for programs by subject. I'd like to have development tools such as compilers in one directory, text writing tools such as word processors and text editors in another, system administration utilities in another, and so on. Additionally, I'd like to be able to keep multiple versions of a package installed, and the only way I could do that is by installing each version in a separate directory, and selecting which version to use via soft-links in the directory that happens to be in my PATH. How does the current packaging system allows me to test one version of a package while other users of the same host are running a stable version of that tool? Or are the GNU/Linux distributions all moving towards the Micro$oft model of single-user workstations? -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil
upload to slink allowed to fix missing dependency?
Hi, The version in slink of the debiandoc-sgml package has an undeclared dependency on the libwww-perl package. Is it still allowed to upload a corrected version? This doesn't involve any code changes, just an extra dependency declaration in the debian/control file. Thanks, Ardo -- Ardo van Rangelrooij home email: [EMAIL PROTECTED], [EMAIL PROTECTED] home page: http://www.tip.nl/users/ardo.van.rangelrooij PGP fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9
Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote: The contract simply states that the library will be found. Which library is used can be determined by the linker. Except that, if you replace the library with an incompatible one, you *are* breaking the contract. We don't replace libraries with incompatible ones. We bring in new libraries, which are incompatible. We keep the old ones, which are compatible. Our linker knows how to tell which is which. Who cares where they are stored? Actually, we do care where they are stored. My point is, that it doesn't matter if the new library is in the location the old library used to occupy. Our linker knows which is which. Furthermore, there's no reason to assume that the user will *not* have used -rpath himself, so moving libraries does have a potential for breaking user programs, therefore it should best be avoided. This is a valid point. It is my feeling that -rpath should not be used for libraries in the 'standard' paths, which allows them to move (which is a useful feature). It is reasonable to use it for libraries in unusual places (another useful feature). I think a solution that is not general is not a good solution. Since the solution of moving shared libraries around has the potential of causing problems, if I were you, I'd work harder to try to find a complete solution (which I happen to have already suggested) instead of trying to blame libtool or other users for doing things that are perfectly correct, but not in the way that would let you replace incompatible libraries. I agree with your suggested solution, which amounted to more complex understanding and use of inter-library dependencies by the tools. However, I don't have the expertise to implement this. And I disagree with you (strongly) about the correct use of the existing system. Our distribution cares greatly about separating packages from each other. Not from the point of view of the end user. When they want to find a tool, they may `ls /usr/bin /usr/local/bin' and will be presented *thousands* of files. I'd rather have a classification system in which I could have links (or similar) to all programs in a common directory, but in which I could search for programs by subject. I'd like to have development tools such as compilers in one directory, text writing tools such as word processors and text editors in another, system administration utilities in another, and so on. Additionally, I'd like to be able to keep multiple versions of a package installed, and the only way I could do that is by installing each version in a separate directory, and selecting which version to use via soft-links in the directory that happens to be in my PATH. We do have a classification system. And we don't use the filesystem for it. We have lists of packages, with descriptions. We even support separate versions of software, to some extent, although I'd agree completely that our support in this area is not what it might be. How does the current packaging system allows me to test one version of a package while other users of the same host are running a stable version of that tool? Or are the GNU/Linux distributions all moving towards the Micro$oft model of single-user workstations? Of course not ;-) If you want to test one version, you simply run it with ./configure --prefix /home/me/nicepackage or whatever. But you knew that. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: libtool rpath
Hamish Moffatt [EMAIL PROTECTED] writes:
+case ${host} in
+ *-pc-linux-gnu)
^^
s/pc/*/ (pc==non-i386 unfriendly)
--
James
Never trust trucks
[Fwd: [Jikes-License] Jikes Parser Generator now available in source form]
Wonderful news from IBM. I will have packages up shortly. Original Message Subject: [Jikes-License] Jikes Parser Generator now available in source form Date: Wed, 27 Jan 1999 14:33:12 -0500 From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] We've just shipped the source for the Jikes Parser Generator to alphaworks. It should be available in a few hours: http://www.alphaworks.ibm.com/formula/jikespg. We plan no support other than to make sure it processes java.g properly, as the Jikes compiler itself is our first priority. For license-fans: It uses a license based on the revised Jikes license, i.e., it's the new Jikes license with 'Compiler' changed to 'Parser Generator'. The termination clause now uses the same language as the SecureMailer license (also available from alphaworks). dave and philippe
Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote: Having libtool default to -rpath is what's causing problems. This is IMHO completely backwards :-) You know, I seem to remember that there is another rather unpleasent side-effect of rpath - it basically completely disables library searching and thus disables LD_LIBRARY_PATH, once you have used rpath it is not easy for a user replace that library (for whatever reason) and I find that highly annoying. I've seen one too many instances of foo crashes on Debian that turned out to be foo is a libc5 binary with an RPATH of /usr/X11R6/lib which on any reasonably up to date Debian system contains libc6 X libraries. See? You replaced one library with an incompatible one without modifying its version number to mark it as incompatible. Isn't this breaking the contract? How could you expect it to work? Not exactly, the x libraries are fully compatible and were built with the same source - the trouble is that one is linked with libc5 and the other with libc6. In normal cases the dymanic linker would figure this out one way or another with rpath this functionality is disabled as it overrides the library versioning scheme. The linux dynamic linker will resolve things in some magical way based on the library dependencies and the program dependencies to locate the proper library in many cases - rpath does cripples, not enhances, this function. On another note, you have suggested that we use /usr/lib/libc6 and other things to isolate libraries that have been recompiled with updated dependencies - the trouble with this is that all the distributions and all the distributers would have to agree on a scheme for this - otherwise a 'debian' binary would not function on a RH system because they used a different scheme and their rpaths would be incompatibly different. Furthermore this idea of a /usr/lib/libc6 becomes entirely unmanageable when we start having soname changes for things like libgtk - we will have the -same- problem with all the millions of libs that link with libgtk as we did with libc6! The linux dynamic linker has the ability to resolve these issues on it's own by carefully relocating the old libraries, rpath simply does not. We must be able to turn it off for libraries used on our system! Jason
RE: [Fwd: [Jikes-License] Jikes Parser Generator now available i
Now we need a free JDK and off we go (=
Re: GNOME in potato needs slink libs
On Wed, Jan 27, 1999 at 02:22:36PM -0600, Ossama Othman wrote: Hi Jules, Another quick question... Why does potato's GNOME require slink's gtk/gnome/etc libs? Because potato is not yet a complete distribution, and should be 'overlayed' over slink? Ah, I see. I did a clean potato installation, i.e. not over slink. Anyone have any idea when GNOME for potato will be updated? No rush or complaints, I'm just curious since I want to test the imlib packages on potato's GNOME once I start releasing imlib package updates. Huh? the new GNOME has been uploaded at about 2-3 days ago, it doesnt depend on slink libs. Try a mirror that is not so out of date. -- Stephen Crowley [EMAIL PROTECTED], [EMAIL PROTECTED] -* Finger [EMAIL PROTECTED] for my public key. PGP#22714B25 *-
