I think it covers everything; would you mind floating it before a
broader audience though (gnu.emacs.misc perhaps, if not also
comp.protocols.x.something?)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
while it would be interesting to perhaps do a 1.3.1 or a 1.4 with
other features, there has to be pressure against doing anything to 1.3
other than what qa wants to do to get it out the door. We can't make
every release perfect; in fact, we can't make *any* release
perfect... but we can try to set
> because CVS always wants write access to the directory (for lock files)
Yep. I've seen patches for this at MIT, but I don't think they're in
the mainline... You've also got some potentially major access control
problems; look at what freebsd does, and consider that you *don't*
want general a
> # mv /usr/X11R6/bin/xdm-shadow /usr/X11R6/bin/xdm
> I can switch back and forth between shadow and non-shadow passwords,
> and can login via xdm just fine. Nothing bad happened, my machine
> hasn't exploded yet, etc. :-)
Ah, I see, it just logs an error, but doesn't actually fail. (The
code on
> It's not officially dropped, it's just not currently maintained; I don't
> think there's any plan to drop it totally.
Umm, it's not maintained *upstream*; I maintain the debian package.
It is worth porting the code to use db, even using the dbm-style
interfaces, but since there's no data-level
however, there *are* freely-written z-code games, which can be
distributed (and I think even have been already, for debian? I may
have seen them somewhere else.)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED]
actually, a lot of us find the sound driver stuff objectionable too
(because it leaves us with practically useless sound code, almost
enough to drive one to NetBSD :-) I still don't have any way to use
*both* ESS1688's in my laptop (when docked), which should be *trivial*
if the module took argumen
> But if OSS, X-Free and QT all operate along similar lines, thats 3, there
Umm, no, XFree86 does *not* work that way. Though they do release
non-source timebombed betas, they always release full-source "real"
releases. You can ignore the betas (as debian does, I mean they are
*betas* after all
yeah, cygwin32.dll is under the GPL. So? It's a DLL, like libc5 and
libc6 are... [the *only* thing I'm aware of that actually uses the
LGPL is libg++; it was as much of an experiment as anything, and I'm
not aware of any not-otherwise-free software taking advantage of those
terms...] Just because
> I just brought this up, since it was my understanding that if you
> want to write a commercial program (ie. not under the GPL), and
> link it against cygwin.dll, you've got to pay Cygnus $$$. Not all
> that different than the restrictions on Qt, really.
Two questions: (1) in what way is cygwin3
> I believe libc5.so is LGPL...
I don't. /usr/doc/libc5//copyright doesn't *mention* the LGPL *at
all*, though the libc6 one mentions both.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
> Now, when you link -- statically or dynamically -- you are including
> portions of libc5 in your binary. This results in your binary being
Umm, no, actually -- the whole point of dynamic linking is that you're
*not* including portions of libc5 in your binary. A replacement libc5
that met the "i
right, usually that means "mirror sites only" and then in a day or two
they'll all change the modes together. (This keeps the master site
from getting flooded; I remember Jim Gettys posting about people
connecting to ftp.x.org which was a heavily loaded Sony NEWS machine
buried off a local net in
> However, the unique interface issue does exist with regard to gzip,
> since that is purely a GPLed product. I think a libgzip or a gzip.dll
> would run into the same issues as the libdb did.
Not to distract from the original point (thank you for the clearer
explanation of the libmp issue!) no
> The xserver packages want to setup x, this gets stuck because xinitrc is
> missing because it is part of xbase - which is not installed at that
Hmm. Yeah, I think I've probably always won because I use dpkg from
the shell, and with globbing get everything in alphabetical order :-)
The problem
and don't forget, there's *still* no written-down policy on shadow:
% grep -i shadow /usr/doc/dpkg/programmer.html/*
Exit 1
I mean, I will get this straightened out with 3.3, but the
picky-detail side of me is still miffed that debian's shadow policy is
still basically hearsay. :-}
--
TO UNSUBS
correct analysis except:
> As it happens xdm-shadow works fine on non-shadow systems, so I believe the
> maintainer has (or is about to) uploaded a copy where xdm and xdm-shadow are
> the same (shadow enabled) binary.
Not uploaded yet -- it's just one of the things I'll be sure the 3.3
upload g
In fact, as X maintainer, I requested that the 3.1.2 sources be
removed, oh, at least a couple of weeks ago (when I figured out that
they had nothing to do with *any* current tree, not even xcontrib...)
Perhaps it only got removed from unstable?
_Mark_ <[EMAIL PROTECTED]>
> But shouldn't xbase then replace and conflict with xterm-color?
Yes, it probably should have done that a long time ago. Go ahead and
file a bug report so I remember to get that in.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mai
hmm. xnest should work fine with xfs (I'd used it that way under
3.1.2, when I was developing the gzipped font stuff) but note that the
very end of the man page has some warnings about how xnest actually
*fakes* all of it's font handling. (Rather than repeat it here, look
near the end of man Xnes
> When will we get libc6 X packages ?
probably in the next week or two (I'll try to push out a 3.3-2 with
the dependency problems and XF86Setup problem fixed this weekend, and
then convert my stock-1.3 build machine into a mixed-mode machine and
work forward from there...)
--
TO UNSUBSCRIBE FROM
debian's Xfree86 3.2 packages were not built reentrant. I'm working
on the 3.3 libraries now, and once they're stable and working, I'll
be adding other support to them. (have you ever tried programming
with X and threads? you probably want to only use Display* per-thread
anyhow...)
I've seen this reported elsewhere; if the xemacs maintainer has
vanished, perhaps someone could grab the debian sources and rebuild a
non-maintainer release using the 3.3 libs? Or at least look into the
problem? (Xemacs has more dependencies on X than emacs does -- the
current emacs works fine wit
> dpkg-gencontrol: failure: chown new files list file: Illegal seek
It means that you don't have a utmp entry for that shell. Upgrade to
a newer dpkg-dev (probably from unstable) for a version that just
whines about the lack of utmp entry, instead of actually breaking...
--
TO UNSUBSCRIBE FROM
xcompat is dead (ie. it dates from when those were valid... since no
current packages need those virtual names, xcompat isn't needed either.)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
> I was under the impression that xcompat is needed to run non-Debian
> binaries that were compiled against old libs. I believe that may be true
That is possible (xcompat is an a.out library.) I haven't heard
direct reports of such (and xcompat is still dead -- there were never
"real" sources
as I was informed when doing the libgdbm-altdev packages, you need to
have symlinks in /usr/i486-linuxlibc1/lib/ pointing to the .so* files
you put in /usr/lib/libc5-compat. Also, debstd now knows about
/usr/lib/libc5-compat, which helps.
It would help if you specified that documentation went in
You should certainly remove libdb-dev, since libc6-dev replaces it (as
libc6 includes libdb.) I haven't done a libdb-altdev, and unless
someone asks probably won't bother (the libgdbm* packages are already
uploaded though.)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe"
> Your're kidding ;-)? There're several really great HTML browsers like
> netscape, lynx etc. And you should remember that for example KDE will use
I don't think he's kidding. Lynx is *awful* for searching (it doesn't
even have a keystroke for "same pattern, next occurance"...) Netscape,
wel
Ahh. Now that I think about it, I had problems in the early days of
19.34 releases, where it worked fine with some libc's and not with
others; it turned out that the best effect was compiling it with a
very new libc, then it didn't matter as much what it ran with. (Yeah
that sounds fuzzy -- it is
Except that the xterm-color entry isn't particularly widespread, yet;
so if you rlogin or telnet somewhere that doesn't have it, you pretty
much lose. This is the main reason I'm reluctant to force the
change... though I might be convinced to do it for the unstable (with
libc6 and all the other ex
> /usr/info/emacs-info. I suggest to split this off into a new package
> called "emacs-doc-info". In addition, we should create an "emacs-doc-html"
Interesting. Not really an option, though; as far as emacs is
concerned, that's part of how it documents itself. If you come up
with a way that wor
in practice, the "linux" entry not being supported by solaris (for
example) was handled by people doing "set term=vt100" and whining a
lot...
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
> 0.5.21, gpc is 2.something, who knows about gnat...
gnat is 3.09, 3.10a is in test and might be released some
time... in any case, while merging gcc/g77/gpc into one release
probably makes a lot of sense, gnat is "not like the others" --
because it's *written* in Ada, not C, so you need the mos
Hmm. While there are *particular* problems doing 32->64 bit cross
compilation, doing any 32->32 compilation is probably *quite* solid.
(In particular, compilers targeting the 68k are probably *better* than
the x86 native compiler -- because we've [we==Cygnus] actually had a
lot of paying 68k custo
> environment variable), and then changing tar to look for that file
> (agian in that environment variable), and ajust the permissions/ownerships
Not necessary -- tar 1.12 (I think) has --owner, --group, etc. In
fact, you could write an "install" program that was just a wrapper
around tar --appe
> decided that the best way to do this would be to write a stream
> editing tool that could edit a tar archive (I think the format's
I'd prefer that this only be done using tar itself -- because debian
has had such a bad track record with handling tar format, particularly
in the fringes (long fil
That makes sense (using deity support for the exclusion, I mean.)
After all, as a *package maintainer*, I want it to be *difficult* for
a user to accidentally not install documentation; I want them to have
to deliberately go out of their way if they want to fail to install
it. (After all, I want th
> IBM developed a cypher called "lucifer". The NSA examined it,
> recommended some changes to the algorithm, and the result was DES.
Changes which, we now know, *strengthened* it against differential
cryptanalysis (which they new about in the 70's, and called the
"sliding attack", if I remember
> knew about another attack), and they reduced the key size to 56 bit so
> they could crack it with brute force in massively parallell hardware.
Umm, no, part of the *problem* with lucifer is that the 128 bit key
had symmetries that made it's strength *trivially* less than 64 bit
and as I recall
> * gcc should be in Important because everybody expects a C compiler
Maybe they expect it, but these days, they don't *get* one... none of
solaris, hpux, irix ship with a [working] C compiler...
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Tr
> The situation looks completely different if the server has its own
> package, like `msqld' for the server and `msql' for the client.
Not really -- the user should still be prompted (or have some control
over it) because the daemon package probably contains the
*documentation* for the daemon! I
> 1. Does debian include any additional drivers on top of the
> standard XFree source?
Nope -- you can look at the xfree86_3.3-3.diff.gz and see *exactly*
what changes we've made, but they're mostly configuration.
> 2. Does anyone know of similar development work elsewhere?
> I've contacted Xfre
> Apparently,
> the case got taken to court and FreeBSD won against the gov't.
I've heard no evidence of this (and would find it *very* unlikely.) In
fact, the FreeBSD web pages still tell people to go to sites in South
Africa, Brazil, or Finland for the "eBones" and "secure" packages...
Even bet
> : Don't worry: gzip is part of the base system.
> Your word needs to be in Microsoft's and Apple's ear.
I don't get it -- why would we care if gzip is anywhere *other* than
the debian base system? It's not like there's any way (yet) to
install/extract these packages on a mac, though you can s
package: mflib
Version: 1.0-5
Maintainer: Nils Rennebarth <[EMAIL PROTECTED]>
possibly also:
Package: xdvik
Version: 18f-5
The remaining possibly related items are:
ii dvipsk 5.58f-5TeX DVI-driver for Postscript
ii ps2pk 1.4-4 Create pk fonts from type1 fonts
could you give me more information on this? (I'm the current libgdbm
maintainer.) Calling it libgdbm.so.2.0 would really seem like a
mistake, since after all, libgdbm itself is only at 1.7.3... but I can
probably put in a compatibility link if there's enough evidence for it
(namely, programs which
Wouldn't it be easier to do something like I did with BIND -- detect
the "protocol not available" (ENOPROTOOPT?) and don't use the feature,
instead of calling it an error...
>Last time (yesterday) when I used \usepackage{times} in my latex2e
>files, itworked OK, but you probably mean something different
>with the postscript fonts.
Did you use xdvi, though? latex->dvips works, I think, it's the
latex->xdvi that screws up (xdvi uses ugly fonts at the wrong size
instead,
Package: mount
Version: 2.5j-1
I don't know if we have this problem currently, but I'd appreciate it
if you'd check.
--- Forwarded transaction
[8323] [EMAIL PROTECTED] (Theodore Y. Ts'o) Consulting_FYI 08/13/96 19:59 (73
lines)
Subject: [linux-security] Vulnerability in ALL linux distribut
package: fsp
version: 2.71-3
[If I just hit return, it spews; if I actually hit n, it seems to do
the right thing fix is probably to change the
$input = "y"
to something like
"$input" = "y"
so they don't vanish...
Setting up fsp (2.71-3) ...
If you want, I can configure FSP
> but are small anyway) are about 120 Mb uncompiled; compiling them takes just
> under 200 IIRC.
Actually, xfree86 (which generates a bunch of .deb files) is a 360M
source + build tree, not counting the resulting .deb files themselves...
There's probably not much bigger than that in the debian r
Given that we already have "sp" and a bunch of other sgml tools, it
would be nice if someone packaged jade as well -- since it has decent
conversion tools, as metioned below...
[from http://www.jclark.com/jade/]
What is Jade?
Jade is an implementation of the DSSSL style language. The current vers
> Q: Is anyone using `autoconf`? I wonder if it's worth learning to
> use, and what people use it for. (I've barely glanced over the
> manuals for it, so far.)
Most main GNU packages (ie. what's on prep) have switched over to
autoconf (even gcc itself probably will, there's an effort underway,
> IIRC libgdbm is no longer developed, because even the author saw that
> libdb was better, and that there was no reason for double work.
Nice theory; however, db can't read gdbm files, nor does it provide
the gnu-specific version of the interface... so the existing gdbm
will be needed provided
> If we want to be friendly to newbies, we can write an X configurator
> like RedHat; but I don't think that's what we want.
I've heard rumors of this, but not seen it -- how does it differ from
XF86Setup (not xf86config, which is probably what the debian
old-timers think of, but the new tk-based
Oh, I see. Nevermind then -- what you're saying is that the "X
configurator" is at the level of an X based dselect -- so that's the
problem of the "diety" team, right? (Thus it's not something I need
to be particularly concerned with.) Thanks... _Mark_
--
TO UNSUBSCRIBE FROM THIS MAILING LIST
> this since he asked for it a while back. The upgrade to libc6 for perl
> can't happen until there is a libgdbm compatible with it though since I
> refuse to break everyone's dbm interfaces. I'll also be able to release
Great - as soon as I get some consensus on package naming, I'll try to
put
> No. xlib6 should be for libc6 (more long-term solution). Then create an
> xlib6-libc5. How we handle the dependencies for this, I don't know. Fix
But then anyone "upgrading" xlib6 (the 6 for x11r6, not libc6!) will
end up with a libc6 version; Is that what we want to happen?
> > alt-xlib6-dev
> 1/ Doom comes without any source, so dlltools won't be of any use.
Irrelevant -- *aout-svgalib* is what needs dlltools, not doom itself.
> Debian still support a.out executables _execution_ but not a.out
> _development_ anymore...
I guess I could believe that as long as the a.out developmen
> libc6 | libfoo-dev | /usr/{lib,include}
> libc5 | libfoo-libc5-dev| /usr/{lib,include}
I still have trouble with this. There is already a
libc5 | libfoo-dev| /usr/{lib,include}
for each libfoo out there. When people upgrade from 1.3->2.0, what's
*s
> NOO We should _NOT_ use this name. I hate it (and its probably
"Style sheets" then. :-)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
(1) xterm-color has *not* been in X for years, though it was a
collection of patches for X11R5 and X11R6 -- it was not in XFree
3.1.2, it was only added to XFree 3.2, probably via X11R6.1 but I'd
have to check -- it's possibly *only* in XFree. This would mean not
only that xterm-color isn't *widel
nope, recent versions of xbase aren't any better about shadow support,
because
1) there's nothing in the programmers guide even mentioning it
2) the xdm shadow support doesn't fall back in any sane way,
and it's more than just dropping a check -- a bunch of code needs
rearrangement.
> emacs. While this is an inconvenience, it allows people to choose
> their options.
Indeed - I'm the *emacs* maintainer, and I ran xemacs on one of my
systems for a *long* time (finally switched back to emacs for
performance and diskspace reasons, but it was a primary mail reading
site for 6 mo
> Of the 5 oldest bugs, 4 are on xbase, and might refer to problems
> specific to XFree86 3.1.2, which is no longer current. Someone ought
In fact, when I took over X, I went through and closed a *large*
number of bugs in the database; this also involved writing a bunch of
patches, which is wh
> In dselect, running "configure packages" multiple times, as suggested in
> the documentation, did not seem to correct some of the misinstalled
> packages (Xserver, xext).
Please be sure to report these problems specifically, I really am
paying attention to them... cut&paste of the actual messa
Just a pointer -- CPAN (the Comprehensive Perl Archive Network,
inspired by CTAN [s/Perl/TeX/]) has some tools for monitoring their
mirrors for freshness and accuracy; you can probably find the tools
and reports from any CPAN site or from the perl website... or else ask
on the perl-packrats (archiv
well, there is a half-baked idea that I've seen go by: in emacs, *if*
the user has done an stty erase ^h (ie. if the ltchars erase entry is ^h)
then treat ^h as backspace, otherwise treat it as help-char...
However, that's not going into debian emacs unless it goes into the
upstream version (19.35
> Huh. I have the opposite problem: The end key doens't work in xterms!
in xterm, or in rxvt? (This is one of the two or three differences
between the rxvt and xterm termcap entries...)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-ma
Ove Kaaven <[EMAIL PROTECTED]> writes:
> Joerg Jaspert skrev:
>> - Packages in main need to be installable and not cause their (indirect)
>>reverse build-depends to FTBFS in the absence of data.debian.org.
>>If the data is necessary for the package to work and there is a small
>>datas
fakechroot is a great idea for reducing the privileges needed for
pbuilder builds, and thus simplifying developer builds of packages.
However, if you look at the current bug set, it turns out that there
are half dozen bugs that actually get in the way of using it for that
purpose (there are anoth
> installed packages in the work-in-progress root, etc.) with one which
> can be run entirely as a normal user. fakechroot was integral to
> making this happen. I'd be thrilled to see fakechroot frilled out and
woohoo :-) Current status: Piotr turned up and has given me access to
the tree on al
> It works perfectly at the moment so I'm not sure that I'd benefit from a
> heavily repaired version, however this may change when I get to do more
> with the script in the future - I really should look at the bugs I guess.
Given that you run a specific set of operations, it is plausible that
yo
It could also be a simple use of sgrep...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> So, who wants to add support to apt-spy for querying BGP routing tables?
When I worked for Adero, that was *hard* information to get. However,
that inspires the thought of another approach: Akamai (the far more
successful vendor in that space) already builds pictures of the net
from BGP and lo
> will do, sorry. a DOS is still a form of exploit - you exploit
One way to clarify your thinking about this: to repair a DOS problem,
you simply need to fix the effected service (with a big hammer, like
"apt-get remove" or an ip firewall entry, or with more subtle tools
like fixing the bug and u
> (insert standard promotial rant about Super Sparrow here).
google finds supersparrow 0.0.0 from Feb 2001 on supersparrow.org and
sourceforge, and nothing more recent -- is there any life to it? it
certainly sounds interesting...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
> I don't see any harm in making up jigdo files for DVDs --- I don't see
Ooh, yes, please - I'd love to be able to make bootable dvds to pass
around here [MIT area.]
> Of course, if loads of people with DVD writers mail me, I'm likely to be
metoo :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
This is probably the same "missing build-depends for makeinfo" that
id-utils was having trouble with...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> How about: /usr/bin/latex is a program - my_neat_little_phdthesis.tex is
> a file?
Actually, /usr/bin/latex is an interpreter.
my_neat_little_phdthesis.tex *is* program code, even though the vast
proportion of the content will be literal text for output. See Andrew
Greene's BASiX (BASIC interp
$EUID is a bash-ism; you'd need to run "id" instead.
Also, the echo should include the name of the script...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> As far as I can see neither the gcc nor the binutils documentation has
> invariant sections. I don't know about KDE.
Gcc 3 docs do: gcc-3.0/gcc/doc/gcc.texi has (1) the GPL itself [which
we already need some way of dealing with, the text of the GPL isn't
DFSG but we include it...] (2) the three
> That is Horms-versioning. He starts version numbers at 0 instead of
I was questioning the "exactly one release which hasn't been touched
in 14 months", rather than the actual number; it is a general rule
that the first public exposure of something is *not* good enough for
real use, and I find it
84 matches
Mail list logo
