Rorik Peterson <[EMAIL PROTECTED]> wrote:
> I am one of the upstream developers of the nco package. We have
> been unable to contact via email the maintainer Brian Mays after
> several attempts beginning 2003/03/03, although db.debian.org reports
> activity as recent 200
Jamie Wilkinson wrote:
> As Brian has made it clear that he does not wish to follow either
> suggestion made by Dale Scheetz (splitting the package or changing the
> Depends:) to ensure all executables supplied in the package run as
> expected, ...
While I have stated that I do not like the idea
Lauri Tischler <[EMAIL PROTECTED]> wrote:
> pcmcia-modules for kernels 2.19 and 2.20 dont exist.
A set of pcmcia-modules-2.2.20 packages do exist. I uploaded a new set
of these packages yesterday to sid. As for the packages in woody, I
have no control over that. I wish the archive maintainers
> Sure ? Actually pcmcia-modules-2.2.18 depends on kernel-image-2.2.18...
The pcmcia-modules-2.2.18 package shipped with Debian depends on
kernel-image-2.2.18, but pcmcia-modules packages in general -- e.g., those
built locally by users to accompany their custom kernels --- do not have
this dep
Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> i'm running unstable and i can't get pcmcia-modules-2.2.18 to work
> with kernel-image-2.2.18. I always get unresolved symbols (script log
> attached). And I had the same problem with 2.2.18pre21 but 2.2.17 is
> ok. I didn't report it for 2.2.18pre21 b
> On 04 Sep 2000, Brian Mays <[EMAIL PROTECTED]> wrote:
> > Not quite. The FHS briefly mentions *System V's* runlevel 2 and
> > 3 (along with Berkley's multiuser state). It does not specify
> > anything about runlevels for Linux or any other OS.
Gerfr
> On 04 Sep 2000, Ethan Benson <[EMAIL PROTECTED]> wrote:
> > also debian believes in leaving the runlevel configuration to the
> > admin to define.
[EMAIL PROTECTED] (Gerfried Fuchs) wrote:
> Sure - but there is the FHS (I hope that I read it there) that
> defines what at least runlevel 2 and
Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> But the comment says the whole story, it is compatible with standard
> Adobe fonts, aka times which is what I had the problem with.
Jason - You would think so. Nevertheless, try it; it works. Therefore, I
must assume that the comment is incorrect.
Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> Right now there are 4 ways to produce PDF's (AFAIK)
[...]
> That said, my current favorite method is to use gs 6.0's ps2pdf, my
> documents all have eps figures!
>
> There are other problems however - ...
> Another problem is that the times font
> On Sat, Mar 11, 2000 at 11:44:39PM -0600, Manoj Srivastava wrote:
> > Why is it bad having a stable kernel installed as default,
> > and a 2.4-pre kernel, marked as extra, with warning in the long
> > description, also in the distribution?
[EMAIL PROTECTED] (Marcus Brinkmann) added:
John Lapeyre <[EMAIL PROTECTED]> wrote:
> In another thread, I am dealing with exactly this problem. My
> machine hangs with 2.0.37 and 2.2.x, but is OK with 2.0.36. But had
> to take a piece of driver code from 2.0.37. There are quite a few new
> issues arising from two gcc branches and
> [EMAIL PROTECTED] (Brian Mays) writes:
>> Once 2.2.12 makes it out of Incoming, we will have 8 kernel
>> versions in the unstable distribution? Do we REALLY need to
>> provide that many versions of the kernel??
>>>>> "Guy" == Gu
Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in
the unstable distribution? Do we REALLY need to provide that many
versions of the kernel??
I hate to complain, but every time a new version of the PCMCIA modules
is released, I have to build a set of packages for EACH of thes
Since the last "official" release of rxvt is so old and out-of-date
(it is a year and a half old), I have released the latest developer's
version of rxvt in a new package, called rxvt-beta. Rxvt users, please
help me test this package. It currently works with the new pty scheme
and utmp/wtmp form
> Adam Klein wrote:
>> Oh, fro the rxvt package? hmm. Do I need to incorporate those?
Marcelo E. Magallon wrote:
> Well, they are there for a reason, aren't they?
Some of the patches will not need to be added, unless you are also
planning to make a Kanji, Greek, or Chinese version of wterm.
Joey Hess wrote:
> > I think it's not necessary that a developer agree with the DFSG. It
> > should be enough that they indicate they understand it and will
> > abide by it in what they produce for debian.
Then, Chris Waters <[EMAIL PROTECTED]> wrote:
> Yes, but OTOH, it's a little hard to fatho
I ([EMAIL PROTECTED]) wrote:
> > With all due respect, if you think that there is no diversity of
> > opinion in Debian, then you haven't been around here for very long.
[EMAIL PROTECTED] (Ossama Othman) responded:
> I was referring to the fact that many of the developers strongly felt
> that I
[EMAIL PROTECTED] (Ossama Othman) wrote:
> If used properly, diversity of opinion should only help Debian.
With all due respect, if you think that there is no diversity of opinion
in Debian, then you haven't been around here for very long.
> Those with opinions that differ from the mainstream sh
[EMAIL PROTECTED] (Joey Hess) wrote:
> Hm, non-debian does have its good points.
It has some potential problems, too. It could imply that the packages
found there are not built by Debian volunteers, or that they do not
adhere to Debian's policy standards, or that they are not supported by
Debian
[EMAIL PROTECTED] (Alexander E. Apke) wrote:
> Now that debian is going to be using a nonstandard terminfo entry
> for xterms, can the default colors be setup like a normal linux console,
> black background with white foreground.
> I liked this when the xterm was setup this way a whil
I intend to package two new debs: xruskb and netenv.
Package: xruskb
Version: 1.5.3-1
Description: An X localized keyboard switch and autolock.
Xrus is a utility for switching the keyboard mode between different
layouts. While it is intended for switching between latin and russian
keybo
[EMAIL PROTECTED] (David A. van Leeuwen) wrote:
> I'd opt for a `shutdown' button on the XDM login screen.
> Right now there isn't a simple way of bringing the machine down---as
> far as i know. Even ctrl-alt-del doesn't work in XFree86.
> Of course, care should be taken that this can be done o
Andreas Jellinghaus <[EMAIL PROTECTED]> writes:
> If these copyright issues are still relevant - you will find the email
> of the xvt author about changing the copyright to gpl in the kdebase
> copyright file (because kdebase include kvt, and this way xvt code).
The new upstream maintainers must
Paul Slootman <[EMAIL PROTECTED]> writes:
> rxvt 2.4.5 was announced on New Year's Day. As the current hamm package of
> rxvt is still 2.20, it would be great if the new version is available.
> There have been many improvements; I notice the difference immediately
> when I happen to use 2.20 inst
Yann Dirson <[EMAIL PROTECTED]> writes:
> Adam P. Harris writes:
> > I think that /etc/ppp/ip-up and /etc/ppp/ip-down should use
> > 'run-parts' against, say, the directories /etc/ppp/ip-{up,down}.d/.
> >
> > This would allow, for instance, MTA packages to ship little scripts to
> > flush th
>>>>> Brian Mays wrote:
>> This is the rxvt maintainer here. Rxvt has many optional
>> compile-time features, one of which is the behavior of the
>> backspace key. Normally, I avoid modifying as many of the
>> "upstream"
Stephen Zander <[EMAIL PROTECTED]> writes:
> Further in my attempts to setup up a Thinkpad 760CD...
>
> When attempting to load the ibmtr_cs.o mdules under the standard
> 2.0.30 kernel, I get the folliowing unresolved symbols.
>
> netif_rx_R9117ffb8
> dev_alloc_skb_R24e337ab
> dev_kfree_skb_R7a6
no xterm-color entry -- the color
John> xterm has been in X for years)
Don't tell me ... tell the xbase maintainer. Debian's xterm does not
set TERM=xterm-color.
[ stuff omitted ]
>>>>> "Brian" == Brian Mays <[EMAIL PROTECTED]> writes:
Kai Henningsen <[EMAIL PROTECTED]> writes:
> One thing that I have missed in this debate so far: a lot of the
> configurations relevant to this discussion should really be adjustable per
> user.
Ideally, yes. I guess so many of us have single-user systems that
this point tends to get overloo
=?iso-8859-1?Q?Nicol=E1s_Lichtmaier?= <[EMAIL PROTECTED]> writes:
> I see a `config package' as a package that includes/modifies other
> packages conffiles. Using packages for this is ignoring the concept of a
> package. What if you remove one of these packages? What if some programs
> whose file
This is why changing the default prompt for everyone is not a good
idea. You guys can't even agree on what you want the new prompt to
be. And if you want my personal preference, any prompt longer than
'$ ' is too long. If I want to know what directory I'm in, I just
pwd.
Instead of arguing back
>>>>> "Brian" == Brian Mays <[EMAIL PROTECTED]> writes:
Brian> rxvt (and rxvt-xpm) always exports the variable "COLORTERM"
Brian> so that programs can check for color support.
>>>>> "John" == John Goerzen <[EMA
>From the original bug report by John Goerzen <[EMAIL PROTECTED]>:
> rxvt-xpm, at least, is setting TERM to be xterm. It should be set to
> "rxvt". Debian's termcap/terminfo (as well as that of every other Linux and
> many other modern OSs as well) has an rxvt entry, and it should be used in
> t
Package: gs
Version: 4.01-4
The `-g' flag, which is described below, does not produce the intended
effect.
>From the man page:
> -gnumber1xnumber2
> Equivalent to -dDEVICEWIDTH=number1 and -dDEVICE-
> HEIGHT=number2. This is for the benefit of devices
>
Package: dpkg-dev
Version: 1.4.0
The `-u' option in the dpkg-genchanges script has not yet been
implemented.
>From the man page:
-uuploadfilesdir
Look for the files to be uploaded in uploadfilesdir
rather than .. (dpkg-genchanges needs to find
> Rob Browning writes:
Rob> I'm trying to decide if this is a bug in mt, or my relative
Rob> inexperience with tape drives. If it's a bug I'll report it,
Rob> and it'll probably have to go to the upstream maintainers.
Rob> # mt --file /dev/nst0 tell
Rob> mt: /dev/nst0: Fu
-BEGIN PGP SIGNED MESSAGE-
Format: 1.5
Date: Fri, 23 Aug 1996 22:51:53 -0400
Source: maplay
Binary: maplay
Architecture: source i386
Version: 1.2-1
Distribution: unstable
Urgency: low
Maintainer: Brian Mays <[EMAIL PROTECTED]>
Description:
maplay - An MPEG Audio Player.
C
-BEGIN PGP SIGNED MESSAGE-
Format: 1.5
Date: Sat, 24 Aug 1996 08:07:03 -0400
Source: netcdf-perl
Binary: netcdf-perl
Architecture: source i386
Version: 1.1-1
Distribution: unstable
Urgency: low
Maintainer: Brian Mays <[EMAIL PROTECTED]>
Description:
netcdf-perl - A perl extensi
I've noticed that version 2.0.7 of the kernel packages, i.e.,
kernel-headers, kernel-image, and kernel-source, for the i386 have
been sitting in Incoming for about a month. There are no .changes
files for these packages, which is probably the reason that they have
not been transferred out of the I
es in the
/usr/src/linux directory. This target provides a way to compile the
kernel modules without using the kernel-source package.
--
Brian Mays
40 matches
Mail list logo
