On Mon, Mar 10, 2003 at 02:52:18PM -0500, sean finney wrote:
> > (Doesn't the stderr from CGI scripts go to the web server's error log
> > file anyway? I don't recall seeing a CGI script with its own log file
> > before, but I suppose it could make sense if a lot of data is being
> > logged.)
>
>
On Mon, Mar 10, 2003 at 02:52:18PM -0500, sean finney wrote:
> > (Doesn't the stderr from CGI scripts go to the web server's error log
> > file anyway? I don't recall seeing a CGI script with its own log file
> > before, but I suppose it could make sense if a lot of data is being
> > logged.)
>
>
On Sun, Sep 22, 2002 at 01:40:12PM -0600, Bob Proulx wrote:
> If you can avoid those shared libraries it would be best. Libraries
> should be either shared in /usr/lib or not shared at all. The halfway
> between place is not a mature methodology at this time and contains
> many problems.
Ignorin
On Sun, Sep 22, 2002 at 01:40:12PM -0600, Bob Proulx wrote:
> If you can avoid those shared libraries it would be best. Libraries
> should be either shared in /usr/lib or not shared at all. The halfway
> between place is not a mature methodology at this time and contains
> many problems.
Ignori
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time. Policy says they should live in
/usr/lib/packagename/, but I need to make them available for the runtime
linker.
I know of three w
On Sun, Sep 22, 2002 at 03:54:17AM -0400, David B Harris wrote:
> Ideally, there'd be some dead-project listing somewhere; you could ask
> your upstream to list the project there. Then interested parties can
> pick it up if they so desire.
There have been at least a few -- UFO and DOOSS seem to be
I'm working on a package containing several executables, whose common
functionality lives in a few shared libraries. They're linked in the
usual way at compile time. Policy says they should live in
/usr/lib/packagename/, but I need to make them available for the runtime
linker.
I know of three
On Sun, Sep 22, 2002 at 03:54:17AM -0400, David B Harris wrote:
> Ideally, there'd be some dead-project listing somewhere; you could ask
> your upstream to list the project there. Then interested parties can
> pick it up if they so desire.
There have been at least a few -- UFO and DOOSS seem to b
I've packaged David Many'e's "Quelcom" suite of MP3 and WAV editing and
utility apps; I'm interested in finding a sponsor for them.
Quelcom has some overlap with the sox package, especially as concerns
its operations on wav files. Where it differs is in its MP3 editing; it
can split and join mp3
I've packaged David Many'e's "Quelcom" suite of MP3 and WAV editing and
utility apps; I'm interested in finding a sponsor for them.
Quelcom has some overlap with the sox package, especially as concerns
its operations on wav files. Where it differs is in its MP3 editing; it
can split and join mp3
(Not having a great success rate with these requests, but I'm trying
again since no one's told me I'm doing anything wrong)
I've packaged sawfish-themes, the details of which don't really need
much explanation. It addresses the matter that except for the few
packaged with sawfish itself, there ar
(Not having a great success rate with these requests, but I'm trying
again since no one's told me I'm doing anything wrong)
I've packaged sawfish-themes, the details of which don't really need
much explanation. It addresses the matter that except for the few
packaged with sawfish itself, there a
On Sun, Aug 25, 2002 at 01:12:00AM +0200, Josip Rodin wrote:
> > Are arch-independent packages built sent to the buildd machines for
> > every architecture, then?
>
> Of course not, why would they be?
Er, originally I had it in mind that I'd seen per-arch changes files
propagated into the package
On Sun, Aug 25, 2002 at 12:07:04AM +0200, Josip Rodin wrote:
> It just uses your build machine's architecture string, but it doesn't affect
> anything. You might as well replace the arch string with foo in the file
> name, it wouldn't make a difference, I don't think :)
Are arch-independent packag
Something that's been vaguely prodding at me for a while -- when I build
an architecture-all package, the .deb produced is named
packagename_v-r_all.deb as I'd expect, but the build also makes a
packagename_v-r_{arch}.changes file for the architecture on which I
built the thing. Why is that? Am I
Fairly often I've seen ITPs or package sponsorship requests followed up
to by questions about redundancy against packages already in Debian.
Thus, I'm curious -- what degree of redundancy is acceptable or
desirable? As big as a Debian distribution is, there's unavoidable
overlap. It's easy to und
Fairly often I've seen ITPs or package sponsorship requests followed up
to by questions about redundancy against packages already in Debian.
Thus, I'm curious -- what degree of redundancy is acceptable or
desirable? As big as a Debian distribution is, there's unavoidable
overlap. It's easy to un
This is a small Perl module I had need of during a recent project at
work, but which wasn't in Debian.
Essentially it provides the comparison indicating that (e.g.)
2.10.1pl1-8 is greater than 2.9.8.1-4. Small, simple, perl-only.
Packages may be had from http://devin.com/debian/.
Package: libso
This is a small Perl module I had need of during a recent project at
work, but which wasn't in Debian.
Essentially it provides the comparison indicating that (e.g.)
2.10.1pl1-8 is greater than 2.9.8.1-4. Small, simple, perl-only.
Packages may be had from http://devin.com/debian/.
Package: libs
Greetings; I'm looking for a sponsor (and at some stage an advocate, but
first things first) for an adoption of the xcdroast package, recently
orphaned by Ishikawa Matsumi.
I've been using Debian since mid-slink, and have been making small
contributions throughout (bug reports, patches, stack trac
Greetings; I'm looking for a sponsor (and at some stage an advocate, but
first things first) for an adoption of the xcdroast package, recently
orphaned by Ishikawa Matsumi.
I've been using Debian since mid-slink, and have been making small
contributions throughout (bug reports, patches, stack tra
I'm trying to package up acme, a GNOME2 utility for making "multimedia"
keyboard buttons work.
One problem I've observed: acme uses GConf, which stores schema files
under /etc/gconf/. The schema files give the configuration structure
and default values, but aren't configuration files themselves,
I'm trying to package up acme, a GNOME2 utility for making "multimedia"
keyboard buttons work.
One problem I've observed: acme uses GConf, which stores schema files
under /etc/gconf/. The schema files give the configuration structure
and default values, but aren't configuration files themselves,
23 matches
Mail list logo
