night.
Please let me know if there are still problems.
[EMAIL PROTECTED] (Bill Mitchell)
On Wed, 29 Nov 1995, Joel Ray Holveck wrote:
> It appears that the cvs binary installation does not install several
> files in /usr/lib/cvs that are necessary to create the repository.
> This causes cvs to have incorrect assumptions about the state of the
> repository when it is first created (pe
> > What's a wibble?
>
> Never seen blackadder? :)
I saw parts of a couple of episodes. The only thing I recall about it
is "Is he really crazy or has he just put underpants on his head and
stuck soda straws up his nose?". Never got into it. Most British
humor goes right past me (Except Monty
Ian Jackson <[EMAIL PROTECTED]> said, regarding package diffs:
> Bill Mitchell writes ("Re: watch-1.0-2"):
> > Gunzip will choke on a zero-length compressed file, so I've been
> > gzipping a file which contains a single newline to provide a .diff.gz
> &g
"Peter Tobias" <[EMAIL PROTECTED]> said:
> > There should be no subdirectories within /bin.
> > Given the intention of FSSTND compliance, this is an absolute
> > prohibition.
> They're just talking about /bin and not /usr/bin.
Oops. Right.
Scott Blachowicz <[EMAIL PROTECTED]> said:
> Ian Jackson <[EMAIL PROTECTED]> wrote:
>
> > I agree. But, now you see that we have a script called /usr/bin/aout
> > and a potential directory called /usr/bin/aout. Hence my suggestion
> > that it ought to be called something else. with-aout perhap
[EMAIL PROTECTED] (Bruce Perens) said:
> From: Ian Jackson <[EMAIL PROTECTED]>
> > 6a. No unnecessary up/down-loading by maintainers.
The issue gets bigger as the connectivity gets worse. I think it's
a big issue, and I use a 9600 bps modem on a phone line which isn't too
terribly noisy most of
Ian Jackson <[EMAIL PROTECTED]>
> Bill Mitchell writes ("Re: bogo-1.2-1 released"):
[.. downside comments ..]
> [.. disagreement ..]
[.. upside comments ..]
> I'm confused. Here you're making my point for me.
I wasn't arguing, really. I was remarking on
Ian Jackson <[EMAIL PROTECTED]> said:
> Karl Ferguson writes ("bogo-1.2-1 released"):
> > Well, it's a tough job, but someone's got to be low enough to do some
> > small Debian packages :-) One day when I feel more confident I'll do
> > some real packages
>
> Does anyone else think it would be
PACKAGE: memtest
VERSION 0.1-1
root:/root# memtest 1024
Segmentation fault
[EMAIL PROTECTED] (Bill Mitchell)
On Sat, 25 Nov 1995, Bruce Perens wrote:
> We should encourage authors to package their programs individually rather
> than dump them on Rik. Sometimes, we're going to have to make judgement
> calls.
And someone commented that it'd have been better if all the programs in
upstream digest packages
Alvar Bray:
I have heard several other people say they have had corrupt
database files - how do they get corrupted? I have never managed to
corrupt mine (but then I, as the package maintainer, wouldnt would
I)
Possibly a SIGINT, SIGQUIT, SIGTERM, SIGKILL at an inopportune time.
On Thu, 23 Nov 1995, Ian Jackson wrote:
> We should document what we ship as we ship it.
No argument, but that implies lots of work for maintainers
when initially building packages and when upgrading to new
upstream releases. I'm not sure that it's practical.
Some quick grepping around in my fa
On Thu, 23 Nov 1995, Ian Jackson wrote:
>[...]
> I Having lots of packages is good, but half a dozen (probably often
> poor) implementations of the same tiny script in half a dozen
> different packages doesn't seem optimal to me.
I'd expect a rash of package contributions as hordes of new
debian
ve changed).
Xtet42 still runs very slowly, with about three seconds between
object positions. I'm putting that down to the application being
written to need a mega-fast CPU.
Thanks to all involved in the offline email exchanges for helping
to explain this.
[EMAIL PROTECTED] (Bill Mitchel
during processing of /etc/initd/modules.
Between "Calculating dependencies ..." and "done", I see about
lines of "sh: /bin/nm cannot execute binary file". There's
noting in between there except "depmod -a". Manually running
"depmod -a" after
On Thu, 23 Nov 1995, Andrew Howell wrote:
> Is your 486 a dx? Do you have any video memory left over for a font cache?
> How much RAM do you have? What kind of video card?
Dx -- dunno. Didn't take note when I had it open. I grepped
/var/log/messages for a bogomips figure, but that's apparently
1 operations are able
to continue normally and the ctrl-alt-* commands work OK during its
startup.
[EMAIL PROTECTED] (Bill Mitchell)
On Wed, 22 Nov 1995, Chris Fearnley wrote:
> The info documentation included refers to /usr/local/bin/cfengine when
> Debian's cfengine is installed in /usr/bin/cfengine.
I'm closing this without action.
I've looked at the cfengine info files, and I think it's clear
from the context that the re
triggers this under some man programs.
[EMAIL PROTECTED] (Bill Mitchell)
On Wed, 22 Nov 1995, Gordon Russell wrote:
> Packages: base
>
> The /etc/magic file does not allow the file command to identify
> elf .a files from aout .a files very easily. Indeed, an elf archive
> : archive
> but an aout archive
> : random archive
>
> Would someone update this to something mo
On Wed, 22 Nov 1995, Ian Jackson wrote:
> Bill Mitchell writes ("convenience script for building a.out packages"):
> > This is a script I've placed in /usr/local/bin/aout on my system.
> > It's intended as an aid in building a.out packages on an
> >
reassign 1891 file
Chris Fearnley <[EMAIL PROTECTED]>
> When I try to reformat a paragraph, with the command '!}fmt', in elvis,
> core is dumped. When I do it in vim or nvi, I get garbage instead of a
> reformatted paragraph. I tried reinstalling (and rebuilding the .deb
> package for) elv-fmt and the same effects
The following are my best guesses at answers. If I guess wrong,
someone with better information will correct me.
Chris Fearnley <[EMAIL PROTECTED]> said:
> [...] I have a few questions on this my first
> debianization effort.
>
> o Why is gawk a required package? And is there any reason why g
This is a script I've placed in /usr/local/bin/aout on my system.
It's intended as an aid in building a.out packages on an
elf-ized debian system. It's invoked as:
aout { normal command line }
#!/bin/sh
PATH=/usr/i486-linuxaout/bin:$PATH
"$@"
Considering that 0.93 is considered the stable release, and considering
the user confusion that's been seen between 0.93 packages and the
elf packeages, does it make sense to be announcing elf package
uploads to debian-changes?
[EMAIL PROTECTED] (Bill Mitchell)
[EMAIL PROTECTED] (J.H.M.Dassen) said:
> As far as I can see, the following packages will have to go through this
> transition: electric-fence, libdb (part of libc4, but not of libc5; I'll take
> a look at this), libg++, libident, libncurses.
add flex (for libfl)
Matthew Bailey <[EMAIL PROTECTED]> said:
> I don't know if this is a good news or bad news.
> but I think there is a big misunderstanding about debian-0.93 and debian-1.0
> I really forsee the need to do this
>
> debian-0.93
> release -> debian-0.93
> development/debian-1.0
> NOTICE: NO LINK
> d
On Wed, 15 Nov 1995, Ian Murdock wrote:
> [...] For now, I urge everyone to upgrade their
> copies of gcc, libc, etc., as we're going to start wanting to building
> ELF packages fairly soon.
I've started working on mine. The second package build failed
because it uses curses.
The plan, AFAK, i
On Sat, 11 Nov 1995, David Engel wrote:
>[...]
> 3. Start converting other packages to ELF.
What's the protocol for package uploads from here on out?
Upload a.out packages? Announce where?
Upload elf packages? Announce where?
If both a.out and elf packages are to be uploaded, how are
uploade
On Wed, 15 Nov 1995, Daniel Quinlan wrote:
> Open input is good, in general. If you want to guarantee haggling, do
> it on a mailing list. If you don't want haggling, have input sent to
> a responsible party.
Good point. I agree. General distribution of bug reports is a useful
option, but sh
On Tue, 14 Nov 1995, Ian Murdock wrote:
>BTW, I like the way their manual is set up and on the web. And I
>also like that it seems more geared to open contributions than the
>Debian manual.
>
> Hmm.. Well, I did release a draft of the manual in July so that the
> Project could con
On Wed, 15 Nov 1995, Ian Jackson wrote:
> If it sees what looks like a Debian mirror of some kind (possibly in a
> `debian' subdirectory) and has `stable' and `development'
> subdirectories it will offer the user the choice between the stable
> tree and the development one, rather than requiring
Ian Jackson <[EMAIL PROTECTED]> said:
> Below is a draft copy of a revised set of packaging guidelines.
> [...]
>(This file was last updated on 6th November 1995. Please check the
> directory `project/standards' at any Debian GNU/Linux archive for a
> potentially more up to date copy.)
How a
Ian Jackson <[EMAIL PROTECTED]> said:
> Below is a draft copy of a revised set of packaging guidelines.
> Please comment if you feel appropriate. [...]
Comments:
1. "Text documentation should be [...] installed in /usr/doc."
This is wrong. Text documentation should be installed in
/us
Ian Jackson <[EMAIL PROTECTED]> said:
> [...] It's just that /etc/init.d/functions is
> obsolete, and should be replaced with an empty file so that people
> stop thinking it's useful :-).
>
> It shouldn't be removed until all the packages that source it have
> been updated not to do so, or they'l
der) and sets the TERM environment variable
according to which entry it finds first.
However, on my 0.93r6 installation, xterms always come up with
TERM=linux, which doesn't work well at all.
[EMAIL PROTECTED] (Bill Mitchell)
reassign 1843 manpages
Ian Jackson <[EMAIL PROTECTED]> daid, regarding doclinux and docdebian:
> Why can't we just stick with `doc' containing both sets of
> documentation ? Is there any point in splitting the package up ?
I like the idea of separate docs collections for vanilla linux
and for incremental debian issue
On Sun, 5 Nov 1995, Bill Mitchell wrote:
> [...] The terminfo data/linux file has kbs=\177.
and kbs doesn't appear to work.
rified this under debian 0.93r6, hence the bug report.
--
[EMAIL PROTECTED] (Bill Mitchell)
[EMAIL PROTECTED] (Andrew Howell) said:
> > Which would seem to contradict their copyright statements.
>
> No, not everyone uses the GPL.
>
>
> This program is copyrighted (c) 1995 by Holger Schemel.
>
> It is freely distributable as long as no profit is made with it
> and as long as the packa
[EMAIL PROTECTED] (Andrew Howell) said:
> Some of the authors of the software we have packages have asked for
> a free copy of the CD in return for them letting us put it on the CD,
Which would seem to contradict their copyright statements.
> or just out of gratitude.
But that's another thing
("What's the "debian" stuff in the /usr/src/linux directory?",
I was asked...)
On Sun, 5 Nov 1995, Bruce Perens wrote:
> It's a feature! The /usr/src/linux directory can re-build all of the
> Debian kernel packages ("image", "includes", and "source") using itself
> as the source. The Debian sub-
I said:
>[...]
> :it#8:ku=\E[A:kd=\E[B:kr=\E[C:kl=\E[D:kb=^H:ti=\E[r\E[H:\
^
This is in the linux section of both the present /etc/termcap
and the expanded one I provided earlier. However, my bs key
produces ^? (stty raw; cat -v). The term
, so can't provide an update.
[EMAIL PROTECTED] (Bill Mitchell)
package: source
version: 1.2.13-4
I ran into a debian user a while ago, and he asked me what the
Debian directory was doing in the kernel sources. I'd never noticed
it and had to say I didn't know.
I see now that /usr/src/linux/Debian contains kernel-headers,
kernel-image, and kernel-source sub
On Fri, 3 Nov 1995, Bill Mitchell wrote:
> The apparent missing defs I noticed are for kf20-kf29 (Shifted F1-F10,
> or f11-f20), kil1 (insert key) and kdel1 (delete key).
It looks like I picked the wrong Capnames off the terminfo(5)
man page for these last night. Should be kich1 inst
At a minimum, data/linux
and data/xterm should be defined to the keys available on the usual PK
keyboards, I'd expect.
It's very possible that I'm missing something here but, in my ignorance,
that's what it looks like to me.
[EMAIL PROTECTED] (Bill Mitchell)
Ian Jackson said:
> Supposing I don't trust anything. How am I to examine the source
> package ? For example, I might like to unpack it and do a diff
> against a source tree I have checked more thoroughly.
> [...]
> If I have a packaging format that I can extract using a standard tool
> that I k
> > > > Agreed. I don't think the location should be decided by individual
> > > > package maintainers, though they will be free to suggest a location.
> > >
> > > The Section field from the control file can be used for this.
> >
> > If the SECTION field is not going to reliably contain the sec
Michael Alan Dorman <[EMAIL PROTECTED]>
> Bill Mitchell pointed out that if we use totally 100% un-modified
> extra-virgin upstream sources, debian-driven updates to debian source
> packages become much smaller, since we're just changing the delta. [...]
You're givi
Ian Jackson <[EMAIL PROTECTED]> said:
> `Depends' lines won't stop you replacing an earlier version of a
> package whose dependencies were satisfied with a newer one shose
> dependencies aren't.
>
> This is necessary so that you can install or upgrade your system in
> any order. However, what we
Ian Jackson <[EMAIL PROTECTED]> said:
> >Somehow the FTP site maintainer's programs also need to know which
> >section (subdirectory) the files should go in. I suggest that this
> >information be provided by the `overrides' file on the FTP site, which
> >is already used by the npd
On Tue, 31 Oct 1995, James A. Robinson wrote:
> Now hold on a second there! What about packages put together from
> multiple sources? Say MH with Linux patchs? I don't want to deal
> with writing something that will be able to intelligently do the
> patchs needed and then make the source.
Tha
Michael Alan Dorman <[EMAIL PROTECTED]> said:
> I'll go further and say that I think that any approach that does not
> include as one of its goals the ability to work with totally virgin source
> archives is a total waste of time because it doesn't buy us enough to
> justify the work.
Ian Jackson <[EMAIL PROTECTED]>> said (quoting out of order):
> [...] we need to consider what our requirements are, and
> make some overall design decisions. I think we have several
> conflicting requirements.
> 2a. That upstream source should be unmodified.
> 3. All of the ways of unpacking o
On Mon, 30 Oct 1995, J.H.M.Dassen wrote:
> [...]
> Desirable goals for source packaging
>
> - Upstream sources should be used unmodified.
>[...]
> - Distribute wholly unmodified source
> - Have the source extracted and patches by a 'debianizer' script.
> Th
[EMAIL PROTECTED] (Martin Schulze) said:
> So bugfixes et cetera still go into a released release (eh published
> release). So we run into the great slackware problem that there are
> tons of version 2.2 (as an example).
>
> I don't agree to that. [...]
Wait a sec. I think we have a definition o
On Sat, 28 Oct 1995, Matthew Bailey wrote:
> AOUT -> RELEASED
> ELF -> CURRENT
I'd suggest DEVELOPMENT, or WORKING, or IN_PROGRESS, or somesuch
rather than CURRENT if these are to be visible to user-downloaders.
CURRENT is likely not to be taken as bleeding-edge-and-unfinished
by user-downloade
On Sun, 29 Oct 1995, eckes wrote:
> Package: gzip
>
> I think a zless is as usefull as zmore. The Slackware-implementation of
> zless is:
>
> ---
> #!/bin/sh
> for args
> do
> zcat $args | less
> done
Someone else (Ian J?) pointed out earlier that zmore uses whatever
file pager is specified
On Sun, 29 Oct 1995, Ian Jackson wrote:
> We need to decide what information the package maintainer needs to
> supply to the FTP site maintainer for the correct placement of the
> package.
>[...]
> I don't particularly care about how this is represented in the
> (machine-readable) dchanges forma
On Sun, 29 Oct 1995, Ian Jackson wrote:
> However, I'm wondering whether a more elegant and simple solution
> might just be for Bruce to run the cross-installation which a PATH
> environment variable that ensures that the version of
> start-stop-daemon it finds is a link to `true'.
This is the b
On Sat, 28 Oct 1995, Michael Alan Dorman wrote:
> > This should read "/usr/local/bin:/bin:/usr/bin", without the "."
>
> While we're at it, would it be appropriate to have xdm also set this as
> the default path?
>
Would it need /usr/bin/X11?
Bruce Perens <[EMAIL PROTECTED]>
> I think the situation I described could be named "cross-installation".
> There are other cases than building the base where one might want to
> install to a different filesystem than the one currently running. Thus
> perhaps CROSS_INSTALL=1 is the flag to use. If
[EMAIL PROTECTED] (Bruce Perens) said:
> I think we should agree on an environment variable that I can set to
> tell the pre- and post-inst scripts not to start of kill daemons.
> Would "DEBIAN_NO_DAEMONS=1;export DEBIAN_NO_DAEMONS"
> be an appropriate thing to use?
Should each individual maintai
Ian Murdock <[EMAIL PROTECTED]> said:
> You don't need the tags ("Date:", "Package:", "Version:", and
> "Description:"). It should be formatted something like this:
> [...]
Ian Jackson, would you care to take over dchanges, and implement this?
> [...]
> abc - children's alphabet tutor
>
Ian Murdock <[EMAIL PROTECTED]> said:
>[...]
> The md5sum output of each file should be included *verbatim*. This
> is very important. [...]
> The output of `ls -l' should be included immediately before the md5sum
> output. This allows users who don't have md5sum available to verify
> that, at l
H. One set of typos I made in my recent response to Ian's
requests/suggestions started me thinkin about the format of the
changes file "File" field. Currently, it looks like:
# File:
File: e2-2.0.beta-2.deb 372254 c2680f4e26f2fe948ff8693613fd2a53 binary/editors
File: e2-2.0.beta-2.diff.g
I'm taking these as statements of incremental changes desired to the
current dchanges-produced format.
Ian Jackson <[EMAIL PROTECTED]> said:
> 1) Can there be an option to include a pre-prepared piece of text
> given as a command line argument or on stdin or something as the
> change info ? This
Ian Murdock <[EMAIL PROTECTED]>
>We need to be able to feed the announcement to `md5sum -c', which
>expects.
>
> I agree completely. At the moment, I have to run a special script to
> convert the dchanges md5sum format into a format that md5sum -c can
> understand. This is a pain.
Bruce Perens <[EMAIL PROTECTED]> said:
> [EMAIL PROTECTED] said:
> [...]
> > The only thing I think I need to do this is a way to represent a
> > blank line in the dchanges format's "Changes" field.
>
> Didn't you do something like this for the description field in Debian
> packages?
Yes, some
This is being announced to debian-devel, not to debian-changes.
This is beta-test software -- do not put it in the distribution.
Please place this package in private/project/BETA.
This is for beta test by those debian developers who may be so inclined.
Date: Tue Oct 24 22:06:05 PDT 1995
Package:
Ian Jackson <[EMAIL PROTECTED]> said:
> Bill Mitchell writes ("Re: changes file format "):
> > [...]
> > I also reiterate my suggestion that we stop the practice
> > of maintainers announcing directly (and prematurely)
> > to debian-changes, and have t
Richard Kettlewell <[EMAIL PROTECTED]> said:
> Um, I was thinking more of arranging for them to be changed to another
> uid, or at least telling the sysadmin they exist - leaving them as
> they are risks trouble when some new user is created.
>
> If I leave the company I work for I'm sure they wo
> : * what about files owned by this user in other
> : directories? (Shared projects, etc.)
>
> We tend to leave them as-is, which I'm not sure is smart. On the other hand,
> a find from / is expensive on a system with lots of disk...
Finding the files and expungin
On Sun, 22 Oct 1995, Ian Jackson wrote:
> Bill Mitchell writes ("bc-1.03-8 uploaded"):
> > added /usr/doc/dc with dc.texinfo man Makefile
>[...]
> Why ? The texinfo file is a piece of source code and belongs in the
> source package.
Actually, I thought back
On Tue, 24 Oct 1995, James A. Robinson wrote:
> But Ian, almost _any_ format can be made machine readable -- but
> Bill's format is _easily_ machine readable -- you could slap together
> a whole bunch of ways to read it. I'm very much against going all out
> for "beauty" when you can have a nice
On Tue, 24 Oct 1995, Bruce Perens wrote:
> [EMAIL PROTECTED] said:
> > Are you saying it looks anywhere near as nice as mine ?
>
> Well, I think it looks awful, but I will accept your format simply
> to end this argument if you or someone else
> will write and maintain the parser for it and
> an
"Susan G. Kleinmann" <[EMAIL PROTECTED]> said:
> When running the command mandb -c, I got the message:
> Processing manual pages under /usr/man...
> mandb: warning: /usr/man/man1/dc.1: whatis parse for dc(1) failed
I'm going to try to reassign this bug report from dc to man.
When I tried to repro
The following is taken from an email message I received from
[EMAIL PROTECTED] I hope he doesn't object to my
posting his email and my responses to debian-devel. I
think points made here could usefully contribute to the changes
file format discussion.
> In article <[EMAIL PROTE
Just out of curiosity, does the following represent a horribly
formatted and human-unreadable package announcement? Except for
the lack of a Priority field, it passes the dchanges(1) syntax check.
> Date: Mon Oct 23 18:43:31 MET 1995
> Package: adduser
> Version: 1.94-2
> Description: Utilit
Anthony,
Thanks for the prompt response. I'd appreciate it if you'd copy
[EMAIL PROTECTED] on future emails regarding this, and retain
the Subject line intact so that our bug tracking system can handle
the email properly.
[EMAIL PROTECTED] said:
> The choice for AE to handle multibyte functions
Ian Jackson <[EMAIL PROTECTED]> said:
> Bruce Perens writes ("Re: ChangeLog format "):
> > Please make sure, whatever [alternative] upload announcement [...]
>
> My format is suitable, except for one piece of information which it
> doesn't contain: the subsection for the package. I'm not convinc
Ian Jackson <[EMAIL PROTECTED]>
> I think there are some people who are doing an awful lot of automatic
> copying of information from one place to another, with reformatting
> en-route ...
Could be. I don't think I'm one of them. If I were doing that, it'd
be no concern of yours.
> [...]
> I w
Ian Jackson <[EMAIL PROTECTED]>
> What precisely does dchanges take as input ?
I wondered why you'd ask this, until I discovered that the
dchanges packages wasn't umong the packages I'd downloaded.
After some searching around on ftp.debian.org, I located
it in project/experimental.
Here's a copy
Segmentation fault (core dumped)
root:/root#
Script done on Sun Oct 22 18:55:58 1995
[EMAIL PROTECTED] (Bill Mitchell)
On Sun, 22 Oct 1995, Ian Jackson wrote:
> There are two things here: the Changelog format and the announcement
> format. I think it is probably valuable to separate them.
Yes. I've been following a practice of cutting my most recent
ChangeLog entry out and using it verbatim in the package anno
On Sun, 22 Oct 1995, Nils Rennebarth wrote:
>[...]
> Could this be included in the base system?
>
> I'm willing to write a dialog based perl script modeled after the a2gs
> script to do papersize configuration.
>
> Any other ideas?
Someone -- Ian J. I think -- once fielded a package which se
ian-changes.
4. If desired, the very machine-readable package announcement uploaded
with the package might be translated into some other format deemed
to be more human-readable my the mechanized package-announcer,
and posted to debian-changes in that alternative format.
[EMAIL PROTECTED] (Bill Mitchell)
On Sat, 21 Oct 1995, Ian Jackson wrote:
> Ian Murdock writes ("ChangeLog format"):
> > Personally, I like Ian J.'s ChangeLog format--I think it satifies
> > both goals of being human-readable and machine-readable.
>
> Would it be helpful if I wrote a spec. saying what the format is, so
> that pe
On Sat, 21 Oct 1995, Ian Murdock wrote:
> [...] the only packages that
> don't need a context diff are packages written specifically by the
> Project for inclusion in the distribution, like dpkg.)
I've been taking the requirement for .diff.gz files in package
uploads as an absolute requirement.
the same thing in an xterm. I know that TERM=linux
doesn't work right in an xterm and it's necessary to set TERM=xterm,
but that's another issue (or at least I think it is).
I'm no X-windows jock, as must be apparent by now. Just reporting
unexpected behavior.
[EMAIL PROTECTED] (Bill Mitchell)
This follows up a debian-bugs posting with the Subject
"Re: Bug#1712: Tex has no version number texbin does"
Erick Branderhorst <[EMAIL PROTECTED]> said:
> It might be usefull to let the provides packages have the same version
> number as the providing package, or if a specific version number is
On Wed, 4 Oct 1995, Ian Jackson wrote:
[...]
> > For each file in the files list, find the deepest existing directory
> ^^^
>
> This is where the problem starts :-). Obviously this can be done
> fairly easily if you're willing to have the user download a list of
>
On Tue, 3 Oct 1995, Ian Jackson wrote:
> Erick Branderhorst writes ("Bug#1535: GPL gone LGPL exist"):
>[...]
> This is very interesting. The same thing has happened to my system.
>
> The file /usr/doc/copyright/GPL doesn't seem to be in any of the
> packages on the src.doc.ic.ac.uk mirror of ftp
On Tue, 3 Oct 1995, Bruce Perens wrote:
> [... good thinking snipped ...]
> Does this make sense? I can elaborate if you like.
One additional point occurs to me. Some packages (perl? others?)
consume significant space in postint processing. Size info
for this could be ballparked by the maintai
Let's try this again, filling in the Subject field instead of the
Cc field.
This bug is assigned to "nvi, elvis". Since elvis and nvi now use
update-alternatives, I've requested that this be reassigned to vim.
This bug is assigned to "nvi, elvis". Since elvis and nvi now use
update-alternatives, I've requested that this be reassigned to vim.
101 - 200 of 223 matches
Mail list logo
