Manoj Srivastava [EMAIL PROTECTED] wrote:
Absolute novices unwilling to learn should be lead gently to
the nearest windows box.
How about something like:
introductory vi help (unmap '?' to restore reverse searching)
This editor has two modes, in Input mode you may enter text,
in
Manoj Srivastava [EMAIL PROTECTED] wrote:
Most features? *VI*? or you mean XEmacs? Since when has vi
been an editor with features? ;-)
The biggest advantage of vi over xemacs is that vi is easier on the
wrists. For example, vi's . command (repeat last command which changed
the text) is
Z-Y [Jerry] [EMAIL PROTECTED] wrote:
I am no guru. But let's stop this war!
I apologize for everything I said which seemed combative.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bdale Garbee [EMAIL PROTECTED] wrote:
Have you actually tried this and found something different?
I've run ntpdate numerous times with xntp already running.
I've actually had several folks request that I break ntpdate out into a
separate package, so that they could install just it and
Marcus Brinkmann [EMAIL PROTECTED] wrote:
Maybe the text you wrote could be displayed when vi is started (like emacs
has some text at start-up) ?
Remember that we're talking theory here, even elvis-tiny is
currently bigger than ae, and space is cramped on the rescue
disk.
That said, I was
Jason Gunthorpe [EMAIL PROTECTED] wrote:
You can't background ntpdate, both ntpdate and xntpd can not run at the
same time, if you load one then the other will fail.
Hm... then I guess it should be done the other way around.
ntpdate will run with xntpd running, I've done this numerous times.
Sudhakar Chandrasekharan [EMAIL PROTECTED] wrote:
Things seemed to be going fine till today. Today I noticed that apt-get,
dpkg and dselect all dump core -
Sounds like a significant bug.
Please file a bug report. I think you should include with it an strace
(-f) of dpkg failing.
[Note: dpkg
Tim Sailer [EMAIL PROTECTED] wrote:
Yeah, but I need to support netscape mail under Lose95...
There's a command line version of ssh that runs under win32
(I've used it under NT, I never run '95), that will do
port redirects (which would allow you to tunnel the pop
port).
--
Raul
--
To
Tim Sailer [EMAIL PROTECTED] wrote:
Yes, and it's an ugly method, and costs $99/seat. Netscape has
native support for SSL. I'm trying to avoid clear passwords
across the network. Eudora and qpopper support apop, but netscape
doesn't... sheesh..
Well, there's the whole mozilla thing you can
I noticed that apt is not yet in hamm. In my opinion, this is the
currently the single most important issue for hamm: unless we have
a real good reason, we should be focussing our efforts around putting
apt into hamm.
[Yeah, it's new software -- it's also the best way to keep the hamm
upgrade
Paul Slootman [EMAIL PROTECTED] wrote:
If you take a look at the bug report, you'll see that there's a
workaround already in place for this bug, but the maintainer left the
bug report intact because he wants to find a cleaner solution.
Hence this discussion of lpr - lprng is pretty much
Dan Jacobowitz [EMAIL PROTECTED] wrote:
Now, don't get me wrong...I hate windows registries just as badly as
anyone else, and I've been using linuxconf on and off for ages. But
this has one darn good idea to it: many programs using the same data
source. For instance, I just installed this
Marcus Brinkmann [EMAIL PROTECTED] wrote:
DEBIAN: Sorry, you need a ph.d. in computer science, 10-year-experience
in unix system administration or a good handbook on the obscure vi program
before you can edit a file during installation process.
Don't even think of installing it.
Er.. a
Yann Dirson [EMAIL PROTECTED] wrote:
Hm, be careful with 2.0.34...
Sounds like it should go in extra, for now.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Branden Robinson [EMAIL PROTECTED] wrote:
This is a poor design. xbase-configure would be more properly called
xserver-configure, and in slink when I jigsaw the upstream sources
differen tly there's going to be an xserver-common package where
xserver-configure, XF86Setup, et al. will go. It
Andreas Jellinghaus [EMAIL PROTECTED] wrote:
everyone can use joe. it might be very frustrateing but it's possible.
We already have that with ae. Is Joe smaller than ae?
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Martin Schulze [EMAIL PROTECTED] wrote:
As a compromise I could think of adding a paragraph to the description
for pinepgp.
.
As we are not allowed to distribute a pine package you
have to install pine-src and pine-diff in order to compile
a pine packge out of it.
Ian Jackson [EMAIL PROTECTED] wrote:
3. Obviously additional development of the bug system would be good.
This can be done either by the person doing 2., or independently.
In any case the patches generated need to be sent upstream to me.
I'm interested in taking a look at this. I don't want to
Martin Schulze [EMAIL PROTECTED] wrote:
This again means that we need to encourage more maintainers to work on
multi-package-solution and to skip the 300-mini-cathedral-situation.
Only few people are working on package that are not maintained by
them, this needs to be re-considered.
I'm not
Jim [EMAIL PROTECTED] wrote:
Why? I think you see vi as I see gpm and they see mc: as an essential
convenience.
vi has the advantage of being backward compatible into the early '80s.
The only unix editors which vie with vi for standardness are ed (the
unix standard), and emacs (backwards
Ian Jackson [EMAIL PROTECTED] wrote:
I got to this a little late, but how about putting them in a
subdirectory, like the mh commands are ? /usr/bin/dnsquery or some
such.
Then if you wanted these commands you could at it to your PATH.
That's overkill, and doesn't solve any problems.
[mh
Jim [EMAIL PROTECTED] wrote:
Isn't ease of use more important than standardness when it comes to
an editor to be used for a rescue situation? I think that I would try
doing an alternative set of boot disks to see how folx liked them. Is
it possible to make mc use vi? On the rescue disk, size
Marcus Brinkmann [EMAIL PROTECTED] wrote:
Maybe we should raise our demands to our developers: We should probably make
clear *before* someone wants to become a developer that the job of a
developer is not only care about the packages he/she maintains, but also the
quality of the whole
Mark W. Eichin [EMAIL PROTECTED] wrote:
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
Karl M. Hegbloom [EMAIL PROTECTED] wrote:
There are man pages in the base set that I cannot read. Man isn't there.
You should be able to read them for content (even if it's not very
pretty) using ae.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Bdale Garbee [EMAIL PROTECTED] wrote:
Am working on the release-critical bugs in bind. It appears that
lintian flags the 'mx' and 'ns' commands as possible namespace
pollution. These, along with '', 'soa', and 'zone' are symlinks
to 'host' that do quickie lookups for those types of
Chris Lawrence [EMAIL PROTECTED] wrote:
Dunno. But a lot of people have a copyright restriction in the document to
make sure that the actual integrity of the standard remains intact (see, for
example, the W3C's standards for HTTP and HTML).
This need is met by a label is sacred sort of
Luis Francisco Gonzalez [EMAIL PROTECTED] wrote:
Precisely, in bo the boot-floppies had to disable pcmcia because it was
broken. I guess you never had to install using a pcmcia network card.
If we make changes to the kernels, let's make sure there is no broken
dependent package.
I don't see
Jim [EMAIL PROTECTED] wrote:
Are you unhappy with the result (hamm)? I'm not...
I'm not unhappy with hamm, but I am unhappy that we didn't have any
releases between bo and hamm.
Mind you, I've come up with workarounds, but I also had some service
outages that could have been avoided if I could
G John Lapeyre [EMAIL PROTECTED] wrote:
My last message couldn't have been more wrong ! Maybe there is a
difference between the perl interface to gdbm and some core perl function
that relies on it ?
I guess I'm forced to agree:
# cd /usr/lib
# ls *gdbm*
libgdbm.a libgdbm.so.1
Joey Hess [EMAIL PROTECTED] wrote:
How is it possible to check for block sizes with lintian? And what do you
expect a maintainer to do if they use a different block size and lintian
dislikes that? Reformat?
To deal with block sizes we'll need to abandon (or upgrade) du.
To find out what block
Raul Miller [EMAIL PROTECTED] wrote:
To deal with block sizes we'll need to abandon (or upgrade) du.
Argh.. please ignore this sentence, it makes no sense.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Jason Gunthorpe [EMAIL PROTECTED] wrote:
This is getting out of hand, do we really need to consider slack space
when calculating if the user has enough room to install!?
No, what we mostly need is an estimate.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Branden Robinson [EMAIL PROTECTED] wrote:
3) We have the magical mystical respawning-xdm-on-broken-configuration
problem.
What about the idea of running the x server directly from init,
and using xdmcp? Is that bogus?
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Jules Bean [EMAIL PROTECTED] wrote:
Is du -k not the answer?
du -S, but you need to know how many files are in each directory
to estimate block-size overhead -- assume that each file requires
two thirds of a block of unused space and you won't be too far off.
--
Raul
--
To UNSUBSCRIBE, email
Chris Lawrence [EMAIL PROTECTED] wrote:
[RMS article omitted because it may only be distributed verbatim; my
quoting would violate his copyright]
No, fair use allows quotes.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Jim [EMAIL PROTECTED] wrote:
Speaking as a debian advocate, it would be highly embarrassing to try
to explain something like Oh yeah, the new kernel is there, but you
can't use it yet since ... where ... stems from the person's need for
some dependant package. Example: say he needs pcmcia.
James Troup [EMAIL PROTECTED] wrote:
I don't know perl, and am only going on what Ray has been telling me.
It was my understanding that perl could be made to dynamically load
it's gdbm part on request and that way perl need only recommend or
(better) suggest gdbm. Is this not the case?
A
I would like to recommend that linux 2.0.34 be made available as a
part of hamm. This is because 2.0.34 is a bugfix-only upgrade to
2.0.33.
However, I don't think we have enough experience with 2.0.34 to
eliminate 2.0.33 from the distribution. So both should be available.
--
Raul
--
To
Luis Francisco Gonzalez [EMAIL PROTECTED] wrote:
Let's be clear about what this means. We need to compile the kernel
and all packages that depend on it, pcmcia-modules, boot-floppies,
etc. (We could, I guess live with the boot-floppies being 2.0.33 but
given that there is a mismatch between
Richard Braakman [EMAIL PROTECTED] wrote:
http://master.debian.org/~dark/lintian/reports/depcheck.html#i386 :-)
Looks like libstdc++2.8 and libgdbmg1 should be required, and that
dpkg-dev, dpkg-perl, and libnet-perl should be standard.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
James Troup [EMAIL PROTECTED] wrote:
No; perl shouldn't depend on libgdbmg1. libgdbmg1 is obsolete and
deprecated. I asked the perl maintainer if he could fix this back in
March or so, apparently it hasn't happened.
This close to hamm's release, we should probably rely on non-maintainer
Andreas Degert [EMAIL PROTECTED] wrote:
No, i meant you can't prevent the parser to error out on some edited
config files, not that it will happen with every edited config file.
config files which are broken should be treated as error conditions.
For example, if you put this email message into
Andreas Degert [EMAIL PROTECTED] wrote:
please don't answer too quickly; if you think about it a second
(in the context of the thread) you will realize that I wrote about
syntactically and semantically correct config files that are too
complex for the parser.
That shouldn't matter for context
Andreas Degert [EMAIL PROTECTED] wrote:
That is not the point; of course just the parsing, the syntactical
portion, is rather easy. Else, how should a program like samba parse
it's config files? Even if it's a complex embedded language, by
definition its syntax can be parsed, and if it's for a
Brederlow [EMAIL PROTECTED] wrote:
dpkg should start one thread to extract a package, when a package is
done a second threat is signaled and the next is extracted.
The second thread configures the package. If any question is to be
asked, the controll is given to a third threat and the next
Joost Witteveen [EMAIL PROTECTED] wrote:
OK, that may well be true. But still the text of the GPL is clear:
you are not allowed to change it, whether you change the name of your
cahnged version or not.
You're saying that all those people who have licensed their software
under modified versions
Jules Bean [EMAIL PROTECTED] wrote:
Talked myself into a corner. Someone dig me out?
Hmm, you raised some good points I hadn't thought about...
How about this quote:
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender
Manoj Srivastava [EMAIL PROTECTED] wrote:
I am interested in something way more fundamental to the project than
the mere next release. Unless we thing beyond the next quarter, and
if we fail to make more or less radical changes, we are doomed to
repeat the pattern of past releases.
Yes.
Craig Sanders [EMAIL PROTECTED] wrote:
BTW, the fact that you don't understand sendmail doesn't prevent others
from doing so.
The problem with sendmail isn't that it's difficult to understand, it's
that it rewrites headers, by default. This introduces a whole class of
rather subtle bugs that
It seems to me that bug #21998 against xbase (xbase provides a manpage
for Xnest) should be promoted to severe: while this bug exists it's
impossible to install xnest.
Am I way off base here?
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
This is a draft.
I've written a document which touches on what I feel are important
meta-policy issues. It's a little bit of history, a little bit of
speculation, and a bit of an essay on how I think of debian.
I'm sure other people have different ideas. I hope none of what
I've written makes
Manoj Srivastava [EMAIL PROTECTED] wrote:
Actually, when Debian was formed it had only one developer,
and no one could contribute packages, since that would have diluted
the distributions tight integration. This bazaar thing has evolved.
My memory doesn't extend back that far, nor
Buddha Buck [EMAIL PROTECTED] wrote:
Reading your draft, I see discussion of the importance of the goals,
but not the importance of the standards -- or at least, not in as many
words.
Fair enough.
Do you think the small change you recommended satisfy this need? Or are
you asking for some
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I remember Debian 0.04. Basically, it was what we'd nowadays term base +
bootfloppies - an minimalistic base system on which to build the
distribution. Even then, mailing lists were central to development, and
development was a group effort.
That was
Marcus Brinkmann [EMAIL PROTECTED] wrote:
Am I the only one reading the following in the way that derived works are
forbidden?
...provided that in all above cases Seyon is intact
and is not made part of any program either in whole or in part [...].
We need explicit permission to
Manoj Srivastava [EMAIL PROTECTED] wrote:
In my opinion, sendmail is well documented *and* has lots of
documentation. I also fail to find sendmail.cf obfuscatory -- but
then, I have been writing sendmail.cf files since 1992.
Depends what you're trying to do, I suppose.
When I want
Test $DISPLAY, it's the Right Way to test for X.
On Sat, May 02, 1998 at 08:24:50PM -0400, Raul Miller wrote:
But not the right way to test for xterm.
Rev. Joseph Carter [EMAIL PROTECTED] wrote:
If $DISPLAY is set you're either in an xterm, rxvt, or kvt. As far as ae
would care
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
There are several problems with the packaging of enlightenment. It's
menuing system is *not* easy to integrate with debian menu. This is simply
because of the flexible and highly detailed syntax it uses. It is not
modular in any way.
A preliminary
From: Raul Miller [EMAIL PROTECTED]
To: debian-devel@lists.debian.org
Subject: Re: Coming to closure on ae...
Your message has been enqueued and undeliverable for 1 day
to the following recipients:
Recipient address: [EMAIL PROTECTED]
Original address: [EMAIL PROTECTED]
Reason: unable
Shaleh [EMAIL PROTECTED] wrote:
I just was un-subscribed from debian-user for generating too many
bounced mails. I have now problems with my mail. I have received some
400 e-mails in the last day and a half and sent around twenty. I work
for the ISP, our mail server is stable. Otherwise
Raul Miller [EMAIL PROTECTED] wrote:
I expect that everyone who has sent email to debian-devel this
weekend will have been unsubscribed.
[Er... probably not everyone: the too many bounces mechanism
probably won't knock off people who posted just a few times.]
--
Raul
--
To UNSUBSCRIBE
Manoj Srivastava [EMAIL PROTECTED] wrote:
Raul I've mostly agreed with (Buddha and Philip's) statement you
Raul quoted a few days ago which talks about what to do when policy
Raul doesn't apply properly. I think it has a weakness: in creating
Raul the rules for how debian-policy is or isn't
Bill Leach [EMAIL PROTECTED] wrote:
I am a bit frustrated with hamm right now. As of just before hamm went from
'unstable' to 'frozen' almost every upgrade on my PC box 'breaks something'.
I was literally 'spoiled' by the fact that during the last 6+ months of
development under unstable
Manoj Srivastava [EMAIL PROTECTED] wrote:
Raul You honestly think this is good enough for new developers? I
Raul must confess that I'm not really in touch with the sort of
Raul things they would think.
Of course. You gotta trust people some time. I think we give
folks the benefit of
Manoj Srivastava [EMAIL PROTECTED] wrote:
You suddenly seem to be arguing that policy never be amended
since we may just be screwing it up.
Er... no. Not even close.
Later,
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Steve McIntyre [EMAIL PROTECTED] wrote:
I'm happy that we can work with this license, as we distribute diffs.
Thomas thinks otherwise. Thoughts?
This license conflicts with point 3 of DFSG. We can't distribute
modified versions under the same terms as the original.
--
Raul
--
To
Dale Scheetz [EMAIL PROTECTED] wrote:
It seems to me that we have accepted non-modified source as DFSG compliant
as long as modified binaries are not restricted.
We allow exceptions to point 3, as long as point 4 is satisfied
(explicit permission to distribute software built from
modified
I'm having a problem sending mail to [EMAIL PROTECTED],
the host name doesn't have an MX record, and appears to have
a dynamic ip address. The mail relay being used
(mail.rdu.bellsouth.net) also doesn't appear to know anything
about this host name.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL
On Sat, May 02, 1998 at 06:52:47PM -0400, Raul Miller wrote:
mail supports procmail. ssmtp does not support mail reception, nor does
it support local mail delivery.
Rev. Joseph Carter [EMAIL PROTECTED] wrote:
one word: fetchmail.
fetchmail doesn't do local mail delivery, but relies
Rev. Joseph Carter [EMAIL PROTECTED] wrote:
Test $DISPLAY, it's the Right Way to test for X.
But not the right way to test for xterm.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Dale Scheetz [EMAIL PROTECTED] wrote:
What would be wrong with having the non-x ae tell you in the help
screen what you need to run to get xterm support? The need for this
xterm support comes from folks who want to administer a base system
remotely from a system using an xterm. This is a
Drake Diedrich [EMAIL PROTECTED] wrote:
Yep, but it'd be nice if there were guidelines on how to keep local
packages out of the way of upstream debian packages.
Er.. there are: put everything local in /usr/local/. (or, for that matter,
under /home/.)
If you're stuck with something
Jason Gunthorpe [EMAIL PROTECTED] wrote:
You can configure fetchmail to run through procmail.
Er, the fetchmail FAQ implies that if you use -mda procmail you can lose
mail to resource exhaustion.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Sendmail configuration is tough but it is also the best documented MTA
bar none!
Please don't confuse lots of documentation for well documented.
In fact, a useful documentation tactic is to alter the program to
make it easier to document.
--
Raul
Dale Scheetz [EMAIL PROTECTED] wrote:
Is the info page wrong? Should I submit a bug?
Yes.
Aside: on solaris it's /var/adm/utmp, on the bsd system I have access to
it's /var/run/utmp, I don't remember what system would have it in /etc/.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Buddha Buck [EMAIL PROTECTED] wrote:
Your objection is to the use of the admittedly subjective criteria
if they feel it is a technically superior approach. Would the
(slightly) more objective criteria if they feel that strict adherence
to the policy would jeopardize system integrity or weaken
Robert Woodcock [EMAIL PROTECTED] wrote:
Yeah, that's right, an editor that opens /dev/mem.
If you do an objdump (-Slx) on the binary, you'll see that it's trying
to treat the screen as a region of memory.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Rev. Joseph Carter [EMAIL PROTECTED] wrote:
You need MTA. You just do. But you don't need a complex MTA. If you
consider sendmail the standard to judge by, most everything is smaller,
simpler, or better for personal systems. My personal choice for an MTA is
qmail. The savings in
Dale Scheetz [EMAIL PROTECTED] wrote:
The reason I feel compelled to ask is that I will be creating two new
names: xvi and xae.
xvi, intuitively, seems to refer to an x aware version of vi (elvis or
vim). How about xaevi?
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Dale Scheetz [EMAIL PROTECTED] wrote:
ln -s '/bin/ae -f /etc/aex.rc' xae
and, while it seemed to build the link I desired (it looks good with ls
-l) when I try to execute xae, bash tells me the file is not found.
Any idea what I am doing wrong?
That's only going to work if you have
John Labovitz [EMAIL PROTECTED] wrote:
have you looked at ssmtp? i just took a quick look at the source, and
it seems that it's *extremely* simple -- sounds like a good one for a
send-only MTA.
The problem with ssmtp is that it doesn't have a queue. That means
if it can't deliver the message
Manoj Srivastava [EMAIL PROTECTED] wrote:
This is the first I have heard of our Policy documents being
goals, and I disagree.
Policy, by its very nature, lies somewhere between goals and procedures.
While the DFSG and Social contract are very good, they don't say a lot
about the
root: The person who gets root's mail (also daemons', etc).
This userid (on the mailhub) get all mail sent to
local adressees with userids less than 10. In other
words, she gets mail the system mails to root, daemon,
etc.
Rev. Joseph
Dale Scheetz [EMAIL PROTECTED] wrote:
As to source dependency problems, it is my understanding that all the
packages in the main distribution can be built using only packages from
main.
That's a lot of packages. I've used .deb packages which include source on
little dinky machines with only a
Bear Giles [EMAIL PROTECTED] wrote:
That said, I can't see anyone using a MCA card as his primary
interface.
I can see this, or serial console, being used for a server.
Also, don't forget the sorts of interfaces blind people use...
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Jason Gunthorpe [EMAIL PROTECTED] wrote:
Actually, you'd be insane to put a MCA card in a server (you'd have to get
it second hand and so on). They generally slow down the machine because of
the limits they place on the ISA bus and require special mca screens!
I've put together my share of
Manoj Srivastava [EMAIL PROTECTED] wrote:
We do need a statement saying that the project has indeed adopted
this policy document, and the ``policy'' nomenclature is not a
``mistake''.
We have one -- Ian made it. You've been objecting to it.
[Actually, we have many such statements, go look
Ronald van Loon [EMAIL PROTECTED] wrote:
I find having a constitution sprung on me out of the blue, as well as the
forming of a technical committee whose authority is unclear rather
unsettling and contrary to the open way things have been handled so far -
rather un-Debian, so to speak.
For
Jules Bean [EMAIL PROTECTED] wrote:
deb, however, is not the appropriate format for a source distribution - and
by distributing something in source form as .deb, you are spreading a small
amount of confusion.
So this means we should stop distributing .el sources, and compiling
them in the
Stephen Carpenter [EMAIL PROTECTED] wrote:
now if we only had a featherball
This kinda defeats one of the advantages of distributing diffs... unless
we also want to distribute an exploded version of the ar (or if we
could somehow get the ftp server to let you cd into an ar archive).
--
Stephen Carpenter [EMAIL PROTECTED] wrote:
featherball was a joke by the way...
Sure, but it would be easy enough to put all the various source pieces
into an ar archive (kind of like what we do for the binary pieces
when we create a .deb file), and the way things are heading
maybe that's
Daniel Martin at cush [EMAIL PROTECTED] wrote:
What about a pine-installer package?
This would be similar to the netscape3 and netscape4 packages of old -
the user would be asked in the preinst to put the pine .orig.tar.gz,
the .diff.gz and the .dsc files into /tmp (or $TMPDIR); if those
Dale Scheetz [EMAIL PROTECTED] wrote:
What is your point? The .deb packaging of source doesn't deal with source
dependencies any better than the current source package.
Sure it does. You put the dependencies on the Depends: line of the
control file.
There is no current declared method for
Daniel Martin at cush [EMAIL PROTECTED] wrote:
I don't quite understand what ability it is that you think would be
discarded. The ability to distribute everything needed to compile and
install pine all at once?
Essentially, yes.
I don't see how this would not be accomplished by a
Sure it does. You put the dependencies on the Depends: line of the
control file.
James Troup [EMAIL PROTECTED] wrote:
You can do that in the .dsc file too, but it suffers from the same
problem, i.e. what to do with source dependencies like svgalibg1-dev,
which are arch-specific when .dsc
I [EMAIL PROTECTED] wrote:
Sure: we do need to fix our source packaging system. I don't
agree with that very strongly.
Argh.. bad editting on my part.
I *do* agree very strongly that we need to fix our source packaging
system.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Manoj Srivastava [EMAIL PROTECTED] wrote:
I wish you would talk to Raul directly. He points out that
violations of policy shall be enforced thus:
a) since policy is supposed to be authoritative for bug filers, and
policy violation can be flagged as a bug.
b) any disputes about
Manoj Srivastava [EMAIL PROTECTED] wrote:
Policy should be followed, except where a discussion about the clause in
question is still ongoing, in which case the maintainer may indulge in a
policy violation if they feel it is a technically superior
approach.
Hmm.. this is actually
Richard Braakman [EMAIL PROTECTED] wrote:
Lintian would have to parse that in order to get a full list, and it
doesn't do that (yet).
Another possibility would be to run a test install on some
machine, with strace examining the calls used during the
installation.
--
Raul
--
To UNSUBSCRIBE,
201 - 300 of 483 matches
Mail list logo
