Re: Imminent Checker upgrade release
In article <[EMAIL PROTECTED]>, Tom Lees <[EMAIL PROTECTED]> writes: >> (I actually had to install an extra hard drive in order to build this >> package. It takes over 200MB of hard disk space to build--is that a >> record?) > > No, IIRC the just the XFree86 sources take ~250MB :> The X consortium sources (which are basically the same; they also include sources for Xsun and a few others that probably aren't in the xfree source but are small anyway) are about 120 Mb uncompiled; compiling them takes just under 200 IIRC.
Re: compiling with gettext
On Wed, 14 May 1997, Susan G. Kleinmann wrote: > Yesterday I reported that I was no longer able to compile the package 'sp'. > Santiago Vila and Tom Lees both kindly offered suggestions, but both of > these still leave sp in an uncompilable state. > > Santiago pointed out that the problem might be intrinsic to the > existing gettext-0.26, and suggested I wait til gettext-0.28 becomes > available. This might be a very long time, since gettext-0.26 came out > in December. > > Tom pointed out that my include line: > > > #include "/usr/share/gettext/intl/libgettext.h" > referred to libc6 headers, which must surely have caused a problem since No, that is the GNU gettext generic header, that is right. What I said was, you were trying to link against libc6 but you compiled against libc5. > I was linking with libc5. So I changed this to > #include "/usr/include/libintl.h". > But this produces the same result as if I had no include line at all: You need to make sure you are linking the libintl.h file into the right directory, and including the right file (-I../intl, etc.). > ../lib/libsp.a(MessageTable.o): In function > `GettextMessageTable::GettextMessageTable(void)': > MessageTable.o(.text+0x35): undefined reference to `bindtextdomain' > ../lib/libsp.a(MessageTable.o): In function > `GettextMessageTable::getText(MessageFragment const &, String &) const': > MessageTable.o(.text+0x69): undefined reference to `dgettext' Also, you need to link with -l../intl/intl.a. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
e2fsprogs_1.07-1 still in 'experimental' !
"Package": master.debian.org Version 1.07-1 in experimental of e2fsprogs has been superceeded by 1.10-2 in unstable. I think it should be removed. (experimental shadows unstable on my system; I think this is normal...) -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: sendmail/smail with relaying blocks?
[EMAIL PROTECTED] (Chris Walker) wrote on 14.05.97 in <[EMAIL PROTECTED]>: > I beg to differ. I think what is the sensible default depends on the > usage of the machine. For departmental mail servers, then you are > correct relaying is more sensible, but for "Satellite" systems, it is > more sensible to block it. > > Could you ask a question at configuration time, probably defaulting to > not allowing relaying. If you want to be really clever, you could make a > guess based on earlier answers. > > At the very least, a comment in the exim.conf file would be useful. > > I don't think the above would be very difficult to implement, but I may > have missed something. The sensible default is always to relay only for your clients, in both directions. The problem with this is that it is not easy to automatically determine who your client are. Here's an idea. It probably needs some work. First, ask if the machine is to be a mail server for other machines. If not, block all relaying; you have no clients. If yes, ask user to supply a list of client domains, then allow relaying for mail destined to those domains. Also, ask for IP numbers/nets for clients; then allow relaying for mail originating from those IPs. In any case, allow to leave this unconfigured, and put comments in the config file(s) to explain what to put where. And also allow a wide-open configuration, but warn heavily against it. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Imminent Checker upgrade release
On 12 May 1997, Ben Pfaff wrote: > (I actually had to install an extra hard drive in order to build this > package. It takes over 200MB of hard disk space to build--is that a > record?) No, IIRC the just the XFree86 sources take ~250MB :> -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: sendmail/smail with relaying blocks?
In article <[EMAIL PROTECTED]>, Chris Walker <[EMAIL PROTECTED]> writes: >> My exim package currently allows relaying; as Craig points out below, what >> you allow relaying to/from is extremely site-dependent. > > I beg to differ. I think what is the sensible default depends on the > usage of the machine. For departmental mail servers, then you are > correct relaying is more sensible, No it isn't. Only relaying from machines in the department is sensible. > but for "Satellite" systems, it is more sensible to block it. Should the satellite systems be accepting connections from systems other than themselves (and possibly, depending on how the system is set up, the departmental server) > Could you ask a question at configuration time, probably defaulting to > not allowing relaying. If you want to be really clever, you could make a > guess based on earlier answers. Better still would be to ask what domains to allow relaying for (allowing all and none as options of course).
Re: New Source Formats and Source Package Verification
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 13.05.97 in <[EMAIL PROTECTED]>: > Or, thirdly, we use pristine sources iff they are in supported > formats, or else the upstream source is massaged into a supported > format, and BIG signs are posted pointing to the real sources and the > steps taken to massage it into the supported format. And we include md5sums of both the original and the repacked stuff, or something similar, so people can check that what they got from the original site is the same that the maintainer got. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 13.05.97 in <[EMAIL PROTECTED]>: > >> >>"Kai" == Kai Henningsen <[EMAIL PROTECTED]> writes: Kai>> Well, yes. Scan the temp dir after unpacking. If it contains one Kai>> directory and nothing else, that directory is the main package Kai>> directory. If it contains anything else, the temp dir is the main Kai>> package dir. Rename the right directory to the right name and Kai>> place, and if the temp dir is still around, throw it away. > package A:, in A-1.0.tar.gz; > % tar zfx A-1.0.tar.gz > ./B > ./B/C > ./B/C/D > ./B/C/D/1 > ./B/C/D/2 > ./B/C/D/3 > ./B/C/D/4 > ./B/C/D/5 > > Though this is pathological, I have really seen sources on the net > distributed like this (though I don't think current packages have > sources anything this wierd.) Well, we can do one of two things. We can either say that B _is_ the main package dir, or if we don't want that, we can recurse until we find something different than a single dir. Both are easy. > Oh yes, pathanmes with .. components would _also_ break the > algorithm. Of course, those break everything. I'd insist of having no tarballs even in the Debian source archive that contain those. A different problem is absolute path names (/X/Y/Z). GNU tar automatically discards the "/" (which may, in fact, be related to distributions like the above example) on both tarring and untarring, as far as I remember, unless you explicitely tell it not to; but other tars don't. So do we insist on repacking tars with absolute path names? MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Pbs with locale and fonts
I've encountered two little problems in hamm. First one shows while using dselect. I have the following message several times: perl: warning: Setting locale failed for the categories: LC_CTYPE LC_COLLATE perl: warning: Please check that your locale settings: LC_ALL = (unset), LC_CTYPE = (unset), LC_COLLATE = (unset), LANG = "fr_FR" are supported and installed on your system. perl: warning: Falling back to the "C" locale. perl: warning: Setting locale failed for the categories: LC_CTYPE LC_COLLATE perl: warning: Please check that your locale settings: LC_ALL = (unset), LC_CTYPE = (unset), LC_COLLATE = (unset), LANG = "fr_FR" are supported and installed on your system. perl: warning: Falling back to the "C" locale. It happens since I've installed 'locales' instead of 'wg15-locale' and 'localebin'. I _do_ have LC_CTYPE and LC_COLLATE files in /usr/share/locale/fr_FR. Second thing is the fonts: [15:39:24] root> /usr/bin/setfont lat1-16.psf Bad input file size >From what I could see, setfont and the fonts I use come from the same package (or were updated at the same time) since they have the same date. Too bad they don't seem to be compatible... Mat -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: sendmail/smail with relaying blocks?
Tim Cutts wrote: > > On Fri, 9 May 1997, Craig Sanders wrote: > > > On Thu, 8 May 1997, Mark Baker wrote: > > > > > In article <[EMAIL PROTECTED]>, > > > Thomas Koenig <[EMAIL PROTECTED]> writes: > > > > > > I don't know what's in Tim's debian package though, as I was already > > > running exim when I upgraded to debian and used my old configuration > > > file. > > My exim package currently allows relaying; as Craig points out below, what > you allow relaying to/from is extremely site-dependent. Agreed. > I think it is > more sensible to allow relaying by default; I beg to differ. I think what is the sensible default depends on the usage of the machine. For departmental mail servers, then you are correct relaying is more sensible, but for "Satellite" systems, it is more sensible to block it. Could you ask a question at configuration time, probably defaulting to not allowing relaying. If you want to be really clever, you could make a guess based on earlier answers. At the very least, a comment in the exim.conf file would be useful. I don't think the above would be very difficult to implement, but I may have missed something. > without it remote mail from > Eudora and the like will fail, and I'd rather it worked by default. Agreed, it is better if things work out of the box. > I > have only just restricted mail relaying on my largest exim site (an SG > Origin 200 machine with >1200 accounts) since relaying abuse by spammers > has only just become a significant problem. As Mark suggested below, most > use temporary accounts and the usual ISP's SMTP server. I think most > spammers are probably morons who don't actually have a clue how mail > works. Chris -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#8814: dpkg: Executable conffiles in /etc/cron.*/ run even if package is deinstalled.
On Sun, 11 May 1997, Ian Jackson wrote:
> Nicolas Lichtmaier writes ("Bug#8814: dpkg: Executable conffiles in
> /etc/cron.*/ run even if package is deinstalled."):
> ...
> > $ l /etc/cron.weekly/man*
> > -rwxr-xr-x 1 root root 148 Mar 31 1996 /etc/cron.weekly/man*
> > -rwxr-xr-x 1 root root 255 Feb 26 15:08 /etc/cron.weekly/man-db*
> ...
> > rc man 2.3.10-18 Display the on-line manual.
> > ii man-db 2.3.10-33 Display the on-line manual.
> >
> > When a package is removed (not purged) it removes itself from rc scripts,
> > and from places like that. However, executable conffiles executed by
> > run-parts are still executed. dpkg can chmod -x file or something...
> > This can turn into annoying behaviours... in this example, the catpages
> > would be created twice!
>
> I think that dealing with this is the responsibility of the package
> which creates the /etc/cron.*/ script, not of dpkg, just as packages
> which provide /etc/rc*.d/ scripts should check whether they are still
> installed.
>
> Who is our policy manual editor ? Can this please be mentioned in the
> policy manual ?
That's me. I'll include it in the next release of the Policy Manual.
Thanks,
Chris
-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED],
Debian is looking [EMAIL PROTECTED], [EMAIL PROTECTED]
for a logo! Have a
look at our drafts PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
athttp://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Sending closed bug notices to interested parties.
On Sun, 11 May 1997, Chris Walker wrote: > Further to the announcement from Ian Jackson about the creation of a > mailing list for closed bugs > > There may be circumstances when I wish to know if a bug has been closed, > but am not the person who reported the bug (eg I want to know when the > CVS/inetd.conf bug is fixed so I can feel safe upgrading). > > Would some mechanism of saying "when this bug is closed notify me as > well" eg by sending a specially formulated e-mail, or perhaps some web > interface. This might be useful, as in general I probably don't want to > see all bug report closures. > > Would anyone else be interested in this? Yes, I think that's a great idea. What about sending mail to [EMAIL PROTECTED] with subject "watch" or "notify"? > As an extension to this, it might be useful to send this bug closing > message to all those who submit information about a particular bug report. > I'm not sure if this is worthwhile though, as anybody particularly > interested could always express an interest using the methods described > above. Cheers, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- "DIE ENTE BLEIBT DRAUSSEN!" -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
-BEGIN PGP SIGNED MESSAGE- Noel Maddy <[EMAIL PROTECTED]> writes: > Berate me for missing the obvious, but couldn't KDE just be compiled > with a QT clone for Debian? What am I missing? Probably, but I haven't seen whether the KDE license itself is free. A good bet might be getting KDE to support both Qt and another free toolkit. Good clean patches are the best way to convince the KDE people to do that. Another option is a Qt-compatible library that is just a front-end for a free library. A Qt-to-free-toolkit is another option. The best option, IMO, is the first one. Otherwise, you're encouraging people to write Qt-compatible software. I'd rather encourage people to write software for a free toolkit, wouldn't you? - - Dan -BEGIN PGP SIGNATURE- Version: 2.6.3 Charset: noconv iQCVAwUBM3mymKkybebRDjw1AQFtJQQAl+tPyS/Yjxq8+QieTzqbRKuyaYrvFcQ9 TYyXKyQKFXMwTTe1sb9PWLHDKe+31iRoHLUHDuLP3vly7gx7Lz8loPPEFvJjZcjy NkpzfpK5uTidFPNj3LLZk95MWDlhC6vgyPez/OJWnXQiEsPhNHiEfwHfMI5EL53A vaKJW+jCFVo= =XEWV -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
-BEGIN PGP SIGNED MESSAGE- Jim Pick <[EMAIL PROTECTED]> writes: > Besides, Qt is 'almost-free' software. If it doesn't become a runaway > commercial success, I'd bet Troll Tech would re-release it as free > software after a few years. Troll is using a different economic model for generating revenue than other free software companies. They get other people to write free software (for zero cost to them) on one platform so they can sell it under their own license commercially on other platforms. They prevent those same authors from redistributing the free software they wrote on those other platforms (anything other than the X Window System). The X Window System is likely to be replaced, at which point your Qt-based free software will become very non-free. Sounds like a losing bet. Why exactly is Qt almost-free? It's a scam. Just because some free software authors have been snookered into it, doesn't mean we should put all of our hopes and dreams at the whim of a company that works against our interests, our goals, and the free software community. If Linus, GNU, X11, or BSD had used such as license, would Debian exist? Would Linux be what it is today? No. - - Dan -BEGIN PGP SIGNATURE- Version: 2.6.3 Charset: noconv iQCVAwUBM3mxmKkybebRDjw1AQF2VQQA1dYZEaLJklPnFYu8DB35zrJMxmE+B5Br OuIm+wYX4X6R8EruPEXOxl1wLV95rIyF9RirRspN/usbSJQjpH/eDEVfyBt6iJB9 dSWE7yimL1MZjdXccnCQiQzZiycJvux7JZH5wF6LpAclv2lcD/JvC8JZ52x8o8yk 34oBmHMKtHA= =wZnt -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: compiling with gettext
Yesterday I reported that I was no longer able to compile the package 'sp'. Santiago Vila and Tom Lees both kindly offered suggestions, but both of these still leave sp in an uncompilable state. Santiago pointed out that the problem might be intrinsic to the existing gettext-0.26, and suggested I wait til gettext-0.28 becomes available. This might be a very long time, since gettext-0.26 came out in December. Tom pointed out that my include line: > > #include "/usr/share/gettext/intl/libgettext.h" referred to libc6 headers, which must surely have caused a problem since I was linking with libc5. So I changed this to #include "/usr/include/libintl.h". But this produces the same result as if I had no include line at all: ../lib/libsp.a(MessageTable.o): In function `GettextMessageTable::GettextMessageTable(void)': MessageTable.o(.text+0x35): undefined reference to `bindtextdomain' ../lib/libsp.a(MessageTable.o): In function `GettextMessageTable::getText(MessageFragment const &, String &) const': MessageTable.o(.text+0x69): undefined reference to `dgettext' If anyone has any other suggestions, I'd be very grateful. Susan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
Jim Pick wrote: >I'm not really clear on what the best toolkit for development really >is, but some of the free ones look really, really good. Can you summarize the good and bad points of the free GUI toolkits/frameworks you've checked out and/or point to reviews? - Jim Van Zandt -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Source Formats and Source Package Verification
In article <[EMAIL PROTECTED]> you wrote: : BTW: Do you know anybody who really needs to put all the tools needed : to build source packages onto floppies? :-) Yes, I do. A friend has an older laptop that has a floppy drive, and that's his only current path of getting bits in and out. He may someday have something better, but that's it for now. The argument holds just as well for folks using slower dialup connections to pull files, and/or for those who get to pay per-packet for their network connections. Bdale -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
