> actually view what's being upgraded before you download 250 packages that
That would be "-u", and has been there for a long time (forever?) My
only issue is that it isn't the default, really :-)
> And why are packages being REMOVED (lib-pg-perl for example) when I dist
> upgrade?
Because th
>> Isn't it time to remove emacs19 from unstable? The emacs20 package is more
>> than 2 1/2 years old and RMS said that emacs19 is no longer supported
>> upstream.
In fact, it is in the WNPP with an intent-to-orphan... but people seem
to care enough to keep doing NMU's...
package: wnpp
severity: normal
IBM announced at LinuxWorld the "Open AFS" release of AFS under the
IPL; relevant URLs include
http://oss.software.ibm.com/developerworks/opensource/
http://www.transarc.com
AFS is the "Andrew File System", as originally done at CMU and spun
off to Transarc which i
Yes, given docbook*, task-sgml, psgml, yasgml, and especially jade,
are in text, I'd concur that transformiix should go there too...
> it's an either/or situation (i.e. no way of satisfying both parties
Actually, it isn't -- there's an easy way of giving users a choice,
and two people have suggested it already (debconf). This seems to be
the most Debianish way to handle it - technologically superior, and
avoids punishing one
> *But* in this case, it seems hard to avoid. As I understand it, the
> *whole* mtools package makes 'parasitic' use of the X protocol
Point of information: only floppyd itself is linked against any X
library. The others, which *doing* clever things with xauth tokens
[according to the docs, I ha
> But I don't see the need to *package* large ascii files. What would be
I do see one value, as evidenced by the doc-rfc package: "apt-get
update" means I don't have to keep track of it, I *always* have the
latest version close at hand. In otherwords, the packaging is an
encoding of some human ef
> no, but it should be pretty obvious from the description. e.g. a pop
> server package is going to install a pop server. a web server package is
> going to install a web server. etc. this should be self-evident.
True, but don't forget the case of an initial install - you pick some
profile, and
It looks like "floppyd" is the only thing that needs X. (It's pretty
scary, from the man page -- yes, it's a tribute to debian packaging
tools that I didn't notice this extra component in the upstream
release, I'll be more procedurally careful about that...)
> Correction: mtools in slink does *no
In addition to apologies to Mr. Norman, perhaps there's some value in
either (1) making tcplogd etc. require enough configuration to force
people to read the documentation, or (2) enhance those packages to
interpret things a little more, so they scare naive users a bit less?
Yes, the lack of suidregister unregistration is an already-reported
bug. I even have it fixed, but was mocked by some of the /usr/share
changes and haven't got an updated build yet.
> 2) it takes 47 MB (7.37%) of first CD on which, in theory, the most
> useful packages
This is a good point --
I'm pretty sure xmem was in procps or xproc at one point, and got
dropped because it wasn't being maintained upstream, or something like
that...
> to your cron file that does 'date' and 'date -u'? Set it to run more
I haven't seen the problem yet myself, but throw in an "env"
too... I've noted (in a bug report in regard to inetd) that doing
"apt-get upgrade" with sudo or su with a full *user* environment often
means that you end up with an
> use -rpath /usr/lib for their programs.
Just to make it clear, since I don't think this has come up yet,
/usr/lib isn't the only problem -- /usr/X11R6/lib is as well (or was,
at some point; I haven't looked at the upstream XFree86 Imake
configuration recently, but it did use --rpath at one point
You might look at the "ares" library (Asynchronous RESolver) that Greg
Hudson <[EMAIL PROTECTED]> wrote...
athena-dist.mit.edu:/pub/ATHENA/ares/ares-0.3.0.tar.gz
is the current version. (At very least, compare notes with him...)
_Mark_ <[EMAIL PROTECTED]>
> I think you need to install the new nfs-server package.
Yeah, I got bit by that too, and it took me a while to find that...
maybe we need some sort of "transitional-recommends" field? Something
that is ignored if you are installing the package (to avoid causing
even more pain to dselect users,
Yeah, there's been enough discussion in this context. The decision to
ditch the "emacs" name as a package name was in fact made for good
reasons, a while back; just-before-the-release is the wrong time to
revisit it. As emacs and emacs19 maintainer, I'm closing it, with this
message. Feel free to
> What about the idea of running the x server directly from init,
> and using xdmcp? Is that bogus?
In fact, someone sent in reasonable-looking patches that do just that,
not long before I stopped working on X; they should be in one of the X
bug reports on the subject. I'd have to dig to find t
Yes, in fact, I apologize for not noticing your response -- I'd
forgotten that I sent it in from another account which I don't check
as often (*blush*) so after sending my rant, I then went back and
found it in my mail box. Oops.
Also, I didn't know that it had been orphaned; that would certainly
> [1] I don't why my system always reboots in "read-only" mode now;
Umm, what kernel were you running before? The kernel has defaulted to
mounting the root read-only for a *long* time (before debian-1.3, I
thought), and then remounting it in the rc scripts -- grep shows:
/etc/rcS.d/S10checkroot.s
someone on tcsh-dev found that bug - I sent in the particular patch as
a bug report, but haven't heard anything (on this or on the
history-lines 2*longer than the buffer problem either, though I
haven't dug through and sent that upstream myself...)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wi
> xcontrib's xload also has permissions rws--x--x which is pretty bad, and
Note that whining about this on debian-devel is inappropriate - that's
what the bug tracking system is for. And, you should not that it
also isn't true, as of frozen 3.3.2-3 (yeah, it's only 3 or 4 days old
:-)
> The xme
yeah, lintian might be cool, but it didn't make it into unstable until
a week or two ago, so I haven't tried it...
I don't know how I missed the 19217 bug report, but a fixed xcontrib
is in Incoming as of a few hours ago; it didn't help the situation
that xload was added back "late" after it fell
> emacs needed to work with motif to run on proprietary operating systems
Uhh, that's deep into fantasy land. Emacs didn't use *any* widget set
until emacs19, and emacs18 worked all over the place (and the problems
it had on newer platforms had far more to do with memory allocation
than window s
*traditionally*, you openned /dev/tty, did an fstat(), and the kernel
filled in the real major/minor numbers for the tty you had; then you
scanned /dev/ (or wherever depending on how creative your system was)
and stat'ed things until you got a matching major/minor device
number. (ttyname did all t
Yes, emacs19 is in Incoming for frozen and unstable, in fact, the
second version is there because people actually snarfed the first one
(which was unstable-only) and filed bug reports (yay.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PRO
> What would be the use of looking at a screen full of control characters?
Because when I look at a binary with less, I *mean* to do
that... usually to look for corruption (blocks of nulls) or things
like *short* strings or strings not in the text section, that
"strings" *won't find*.
> mentione
> Fonts for X could be stored as bz2 instead of gz, man-pages could be
> bz2.
No, that's actually not true. Changing how gzip-the-program behaves
would have no effect on X font handling.
Fonts are stored gzipped because there is a fast, free-enough-for-X,
zlib implementation. (The server hasn
In fact, it has been mentioned (on tar-forum, I believe) that gzip
(the program) will eventually include the bzip2 algorithm...
But in the meantime, it makes sense for dpkg-source to deal (ideally,
by having a set of original files and an explicit map [*not* a general
purpose shell script] of how
> How about just using "cp -r ..." to make the image you're going to
Or even mkisofs -f...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> My educated guess on this is that there could be sensitive data in the
> root core dump. I remember this was true on some unix I've worked on in
That's often true if the program is *setuid* (or setgid) [to anything,
not just root] - most, perhaps all unices will fail to dump core in
that case
> I originally asked that there be a D option which would do
> diff -u $x $x.dpkg-dist | ${PAGER:-more}
I did too, though I'd make the change that any arguments given after
the D get passed to diff instead of -u... though -u is what I usually
want, it lets people use "D -c" if they want (it's a
fine with me; I need to get a new emacs19 release out (sparc-linux patches,
among other things :-) fairly soon anyway so the timing is good...
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
sigh. Alright, if you can forward those diffs to this bug report,
I'll look into it; xcontrib doesn't take all that long to build so I
can probably try to send it off this weekend.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to
Yeah, it was specifically left out of xcontrib, because the procps one
was a lot better: from dpkg --status,
> xfontsel, xgc, xman, and xmessage. (xload is in xproc now.)
Did the procps upstream give any *reason* they don't include xload
anymore? Could the current procps maintainer keep it in as
> upload all files with one "scp" when using SSH to upload?
Isn't that what ssh-agent is for? You run it, give it the pass
phrase, and then dupload forever :-)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
> should be able to recompile X with a different version number and
> *only upload binaries*. What would redoing and uploading the source
Yeah, my recent experience with the sparc port confirms this. At this
stage, it seems that all of the non-x86 ports have "system changes
that aren't usefully
> Where did you get this 4000 years figure anyway? 33 bits would just
Oh, having become hopelessly confused by the original posting, I came
up with some additional errors (the 16x10^18 is just as wrong, too;
584,942,417,355 is more like it...) Comes of posting to debian lists
in my sleep :-)
-
> a 64 bit variable, it's good for another 4000 years.
Uhhh -- no. If it went from 32 bits to *33* bits, that would get us
4000 years. This gets us more like 16 billion billion years (american
billions - 16 x 10^18 is what I mean, but it's off the top of my head...)
> Don't you think you're ov
well, swab() isn't a "standard" function, for one thing. It's a
rarely used old-BSD bit, that people occasionally use anyway. Putting
the code directly inline is probably all you can do...
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?
I was wondering about that too -- because gdb has an older bfd in it
that doesn't support sparc-linux, but we've got a current sparc-linux
libbfd; if gdb could use the common package and shared lib, it would
save a lot of porting work. (Of course, I was hoping someone else
would do it -- trying t
Isn't there something *else* going on here as well? Namely, why does
libc6-dev suddenly want kernel-headers, and a particular version at
that, when neither it nor libc5-dev ever did before (and for
good reasons?)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PR
Cool. Thanks!
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
I was just upgrading a system from [hamm a few weeks old] to [hamm
today] using, for the first time, dftp (instead of a mirror and manual
dpkg -BORGiE runs.) I selected libnfslock, it created
/etc/ld.so.preload, and since then any attempt to run a dynamic linked
program gives a message, BUG IN DYN
So, timezone (7.48-3) is installed, and "required", so dpkg won't
remove it. timezones (2.06-1) is available, and "replaces/conflicts"
timezone, but dpkg (1.4.0.19) won't replace it, even with
auto-deconfigure. Is there a non-"force" way to handle this?
--
TO UNSUBSCRIBE FROM THIS MAILING LIST
At least in the US, trademarks don't work that way. If "The MULE"
were software, it would be worth checking if it were editing software,
and *then* looking more closely; since the url you sent describes a
hardware device, it's simply not a trademark conflict. "different
namespaces" as it were. (A
Given that the current build constructs either libc6-only (for some
non-x86 ports) or libc6+altdev-libc5 trees, arranging it to build for
1.3.1 would be a fair amount of painful work. Someone else may be
willing to do this. However, I think the effort is better spent
actually getting Debian 2.0 o
I'll note that emacs19 does what was right at one point, *before*
liblockfile was written; I don't know if they're compatible but figure
that before debian 2.0 it would be safest to code up a fix. (Or steal
your code from emacs20 :-)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "uns
> .elc files compiled with emacs 19.z with z >= 29 will only work on
> emacs 19.29 or later.
Doesn't setting byte-compile-compatibility help with this, or is it
too much of a performance loss?
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Troubl
linux 1.x/libc4 had writev implemented in libc, with no kernel
support. This implementation was, to put it kindly, "marginal". I
think libc5 added code to check if you had SYS_writev and use it, if
not, fall back to the old code. I'm not sure which kernel actually
added the writev syscall, nor a
Note also that the *shell* issue is hard because it's hardcoded into
scripts in various ways, so you really need /bin/sh to work whatever
it is -- the use of "cp", however, can be dealt with by adding
/usr/gnu/bin to your path :-)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubs
> I heard that the original DEC vt100? terminals had delete there and so they
Nope. The VT100 *actually* had both keys there:
+--++--++--+
|~`||BS||BK|
+--++--++--+
+---++--+
| ||DL|
| |+--+
+--+ |+--+
| RET ||\||
+--++--+
where "RET" was labeled RET
> Check out the forwarded message below. I get the same error using
> Debian unstable. Does this mean that Red Hat has thread-safe X libs
> and we don't?
Well, I wouldn't mistake that for a bug report... no indication of
*what* is producing the error, why it would have *anything* to do with
th
I'd promised to package up emacs 20 at some point (since that would
save the hassle of going back and forth to sure emacs19 and xemacs*
would all coexist :-) but I recently joined a new startup company, and
with some of the other projects eating my personal time, I'm just not
going to have time to
On 07-Dec-1997 12:43:00, Kai Henningsen <[EMAIL PROTECTED]> wrote:
> Which easily leads (for me) to actually missing them - because of
> duplicate suppression, they do not show up where they are expected (with
> the mailing list).
One of the reasons I *don't* use duplicate supression (I leave
> (@debian.org??) I'll raise something I thought about a while
I think it's [EMAIL PROTECTED] actually, but I'm not sure; I
only occasionally get mail to it -- all of it inappropriate
(everything I've gotten to xbase@<> in particular should have either
gone to debian-user or to [EMAIL PROTECTED],
I think the policy guide is clear on how to handle emacs lisp files in
packages (it's at least got detail on how to intrude into the user's
startup with autoloads and such.) If that's not enough info, look at
psgml, or even dpkg-dev (it has debian-changelog.el and a hook to make
it autoload) as ex
You might look at the rsalabs web site; there's an "introduction to
asn.1" document there which is quite thorough, despite the name,
though if I remember correctly it only describes one of BER or DER,
whichever PKCS actually use. It might be worth a look.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST
>DecStation 5000. MIPS R4000, but different byte-sex from other MIPS
>systems. No Linux kernel, and may never have one because the
>documentation's not available.
>DecStation 3000. MIPS R3000. See above.
Actually, there's enough documentation for the 3000 series at least --
proof by existence: Ne
>nedit installed its files to /usr/X11/bin, which didn't previously
>exist. I can't remember if there was supposed to be a symlink from
Ok, we can at least get that one fixed...
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [E
Send it to "[EMAIL PROTECTED]", with a package: and version: line
in the body, just like the website says (somewhere.)
> seems to be at fault. My /usr/include/X11 was empty, so the cp failed
Any idea how it *got* that way? Were you upgrading (from what) or
installing fresh? [you can look at /va
> FAKEROOT: after stat, failing?: known=0, stat=d:i=(2051:196739),
> mode=0100664, nlink=1,
I've seen this too (on an x86 hamm system) but I forget if I filed it.
Running "fakeroot alien" on a .tar.gz file triggered it; the .tar.gz
file happenned to have pathnames longer than dpkg can handle [gr
Is there a web page or other document that explains what our strategy
for libc6 is? I'm not talking about random comments on the list, I
mean something nailed down that I can refer to...
In particular, I've got a few issues to work out.
1) libgdbm -- libc6 includes libdb, and therefore gd
Package: linuxdoc-sgml
Version: 1.5-2
Maintainer: Sven Rudolph <[EMAIL PROTECTED]>
from /usr/info/linuxdoc-sgml.info.gz:
File: guide.info, Node: Installation, Next: Writing Documents With
Linuxdoc-SGML, Prev: Introduction, Up: Top
Installation
Get `linuxdoc-sgml-1.5.tar.gz'
> The 0.93R6 sysvinit-2.57b used /var/log/initrunlevel as the file to
> communicate with init. The debian-1.0 version of sysvinit-2.57b
Interesting. I was just about to submit a report about how if I did a
shutdown -h now, it halted the system, and then if I hit ctl-alt-del I
got a message about
Package: gzip
Version: 1.2.4-6
uncompress should be a link to gunzip, as many programs (such as
w3.el) as well as users expect to be able to run uncompress on *.Z
files. (gunzip handles this fine, it's just a matter of naming...)
I'm using debian 0.93r6.
That would be quite useful for something different (or this can be
subsumed into dbackup): I've got a makefile (appended) that I use to
look at all the non-homedir files on my system and compare the list to
/var/lib/dpkg/info/*.list and *.conffiles, leaving me with information
about what files are
The hello-1.3 debian.rules does the 'make install' as root, presumably
in order to have correct uid's and permissions on the resulting
tree. While that's certainly a result to be desired, it is
inconvenient when building packages over NFS or in shared environments
where root access is not made triv
> and will also provide a mtools-2.0.7-15a package to be
> retrofitted into the 0.93 a.out distribution.
Great; I'll keep an eye out for that. Thanks for the detailed
response...
> This problem generally shows up on DOS partitions which have
> been shrunk with fips.exe. The shrinkage leaves the
Should packages ever replace files in other packages? This would make
uninstalling the later package more complicated, although I could
imagine a design where preinst renamed foo to foo.old, and postrm
renamed it back.
This would require that the dependencies introduced an ordering to
package inst
standards/virtual-package-names-list.text lists:
X11R6 XFree86 R6, including base system
xR6shlibXFree86 R6 shared library only
I've put together a package of xterm_color (an xterm that supports
ANSI color) and used a "Depends: xbase"; it appears t
Package: mtools
Version: 2.0.7-12
With the following /etc/mtools.ref
A /dev/fd0 12 0 0 0
B /dev/fd1 12 0 0 0
C /dev/hda1 16 0 0 0
either with or without the additional line
#CHK_FAT=FALSE
I get:
# mdir c:
fat_read: Wrong FAT encoding?
Exit 1
The kernel handles the partition fine:
/dev/hda1 on
72 matches
Mail list logo
