-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sat, 27 Sep 2008 22:04:28 -0400
Source: lx-gdb
Binary: lx-gdb
Architecture: source i386
Version: 1.03-12
Distribution: unstable
Urgency: low
Maintainer: Mark W. Eichin [EMAIL PROTECTED]
Changed-By: Mark Eichin [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sat, 27 Sep 2008 21:51:24 -0400
Source: ratmenu
Binary: ratmenu
Architecture: source i386
Version: 2.3.16
Distribution: unstable
Urgency: low
Maintainer: Mark W. Eichin [EMAIL PROTECTED]
Changed-By: Mark Eichin [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sat, 27 Sep 2008 22:39:57 -0400
Source: owl
Binary: owl
Architecture: source i386
Version: 2.1.8-4
Distribution: unstable
Urgency: low
Maintainer: Mark W. Eichin [EMAIL PROTECTED]
Changed-By: Mark Eichin [EMAIL PROTECTED]
Description
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sun, 28 Sep 2008 00:39:22 -0400
Source: owl
Binary: owl
Architecture: source i386
Version: 2.1.11-1
Distribution: unstable
Urgency: low
Maintainer: Mark W. Eichin [EMAIL PROTECTED]
Changed-By: Mark Eichin [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 26 Sep 2008 01:37:00 -0400
Source: ratmenu
Binary: ratmenu
Architecture: source i386
Version: 2.3.15
Distribution: unstable
Urgency: low
Maintainer: Mark W. Eichin [EMAIL PROTECTED]
Changed-By: Mark Eichin [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 26 Sep 2008 02:52:32 -0400
Source: owl
Binary: owl
Architecture: source i386
Version: 2.1.8-3
Distribution: unstable
Urgency: low
Maintainer: Mark W. Eichin [EMAIL PROTECTED]
Changed-By: Mark Eichin [EMAIL PROTECTED]
Description
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
dataset (like 5
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
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
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
It could also be a simple use of sgrep...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
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
$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
(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
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
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
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 Xfree
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 better,
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
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
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] .
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
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 --append,
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 file
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,
well,
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
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
/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 works as
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] .
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
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
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
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
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-mail
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
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
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]
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
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
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
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!) note
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
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
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
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] .
# 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 only
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
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
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
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
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
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-mail
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] .
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
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 why
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... cutpaste of the actual messages
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
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
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
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 that
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 development
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
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
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 so
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
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: 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
84 matches
Mail list logo
