On Tue, Oct 21, 2003 at 05:03:53PM -0500, Manoj Srivastava wrote:
> We just disallow some usage that has been explicitley stated to
> work. A gratuitous change, with no compelling use cases, or even a
> rationale beyond "why not?", hopefully shall not be accepted.
You keep on referencin
>> Ian Zimmerman <[EMAIL PROTECTED]> writes:
> Marcelo> namely, another tool can present the user with a more
> Marcelo> sensibly designed list
> But, with this server (and yes, I tried both 4.[01]) I keep
> experiencing minor pixel corruption with scrolling. So, I _want_
> (and I sure exp
>> Scott Dier <[EMAIL PROTECTED]> writes:
> Case Study
> --
>
> 'lilo' on the Open Projects Network came into #debian-devel puzzled
> as to which X server he was running, and if it was even a 4.x
> version. Later, it was figred out that he didn't choose the correct
> XFree86 serve
>> Wichert Akkerman <[EMAIL PROTECTED]> writes:
> A normal user who runs ifconfig, route or mkfs? That's about as
> likely as the pope suddenly switching to budaism.
Since the first two's default behaviour is to *query*, and since no
special privileges are needed in order to get a reply back,
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> gcc - The GNU C compiler.
> gcc-2.95 - The GNU C compiler.
> gcc-3.0 - The GNU C compiler.
> gcc272 - The GNU C compiler.
>
> IMO, there is room here for just a little bit of clarification.
*nod*
--
Marcelo | She'd even given
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> Description: Perl extensions for writing pRPC servers and clients
> (is "Perl" more canonical than "perl"?)
Both are. "Perl" is the name of the language, "perl" is the name of
the interpreter.
--
Marcelo | "?" he said.
[EMA
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> 1) There is more than one implementation of libGL available in Debian;
> bumping one to standard would require choosing one.
> 2) If Xlib is optional, I would be hard pressed to believe that libGL
> should be standard.
> 3) Surely we can be co
>> Anthony Towns writes:
> traceroute is where it is because that's where it is on every other
> UNIX
$ ls -l /usr/etc/traceroute
-r-sr-xr-x1 root sys22388 Jun 2 2000 /usr/etc/traceroute
$ ls -l /usr/contrib/bin/traceroute
-r-sr-xr-x 1 root bin 32768 Au
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> And the dependencies a package thus declared would thus depend on the
> build environment even more than they already do.
For the cases that concern this list I think an agreement on
'Build-Depends: ..., xlibmesa3-dev | libgl-dev' would do the
>> Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> I'd rather that be the official mechanism so we can reduce the
> number of dependency elemenets.
Sounds fair. What does dselect (in general, an apt front-end) when
there's no alternative with a higher priority? Wasn't that the reason
for the
Hi,
The section:
Defaults for satisfying dependencies - ordering
in particular the paragraph:
Therefore a dependency on a virtual package should contain a
concrete package name as the first alternative, so that this
is the default.
>> Herbert Xu <[EMAIL PROTECTED]> writes:
> On Mon, Apr 16, 2001 at 12:08:27PM +0200, Marcelo E. Magallon wrote:
> > > There is no alternative to setting the environment variable MESA_GLX_FX.
> >
> > Yes. What do you suggest I do? If you read REA
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> + The /usr/X11R6/ directory
> + hierarchy should be regarded as deprecated for all packages
> + except the X Window System itself, and those which use the
> + imake program it provides, in which case the packages
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> Package: debian-policy
> Version: 3.5.2.0
> Severity: wishlist
>
> This proposal does not change the intended meaning of the existing policy;
> it simply brings the wording of the existing policy (whose origins date
> back to very early ver
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> Have you checked lately to see how many programs within it *actually*
> depend on the X libraries?
Splitting xdvi off tetex-bin shouldn't be much of a problem. If memory
serves well, it's there because of an historical accident. Back when
D
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> Package: debian-policy
> Version: 3.5.2.0
> Severity: wishlist
>
> * /usr/X11R6 is part of the FHS, so it is wrong for Debian Policy to imply
> that it isn't; this fixes that
> * this still tells packages to get out of /usr/X11R6 if they
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> Package: debian-policy
> Version: 3.5.2.0
> Severity: wishlist
>
> * Explicitly forbids shipping /usr/X11R6/lib/X11/app-defaults/.
> * Makes the bit about X resources a separate paragraph, and adds an
> informative footnote about why thes
>> Ben Collins <[EMAIL PROTECTED]> writes:
> Yes, proposed updates do go into the pool.
Interesting. Which Packages file points to them? Certainly not
stable's (at least not for a while), certainly not unstable's (not
permanently, at least), and would think neither testing's. What's
left?
>> Sean 'Shaleh' Perry <[EMAIL PROTECTED]> writes:
> I can not find anything in the checklist about Build-Depends. I have
> been told it was 3.2.x, is this accurate?
3.1.0.0 according to the changelog.
--
Marcelo
Hi Siggi,
>> Siggi Langauf <[EMAIL PROTECTED]> writes:
> > Well, as I said the choice between native and non-native is simply
> > a choice of source distribuition formats, not of "status" (at least
> > IMHO).
>
> I don't quite get your point here...
"better" isn't an order relation for th
>> Brian May <[EMAIL PROTECTED]> writes:
> Jason> Does anyone know *why* libtool requires this? It strikes me
> Jason> as totally unnecessary for runtime linking on linux. Maybe
> Jason> someone should fix libltdl.
>
> Lets not get off-topic into a flame war over "why does libtoo
>> Herbert Xu <[EMAIL PROTECTED]> writes:
> > > and allow shlibs with different minor version numbers to be installed
> > > together by encoding it into the package name. Of course, we'll have
> > > to manage /usr/lib/libfoo.so.2 dynamically as well.
>
> > Break the second you run ldcon
>> Brian May <[EMAIL PROTECTED]> writes:
> If so, what is the problem with installing the unstable version of
> libl6? Oh, you explain it here.
>
> Ian> L-dev from unstable, but then when you compile S it ends up
> Ian> needing the L from unstable.
Ugh. I finally understand the in
>> Herbert Xu <[EMAIL PROTECTED]> writes:
> and allow shlibs with different minor version numbers to be installed
> together by encoding it into the package name. Of course, we'll have
> to manage /usr/lib/libfoo.so.2 dynamically as well.
Break the second you run ldconfig. Plus the fact tha
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> On Mon, Jan 22, 2001 at 02:02:44AM +0100, Marcelo E. Magallon wrote:
> > Just nitpicking, but I'd like to see this worded a bit different,
> > perhaps as a clarification in the sense that programs compile
Uhm. Sorry about the missing signature.
>> "Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> Just nitpicking, but I'd like to see this worded a bit different,
> perhaps as a clarification in the sense that programs compiled using
> Imakefiles will be
This is the message I intented to sign. My apologies again.
>> "Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> >> Branden Robinson <[EMAIL PROTECTED]> writes:
>
> > This policy revision is long overdue, since the transition away fro
>> Branden Robinson <[EMAIL PROTECTED]> writes:
>Packages using the X Window System should abide by the FHS
> + /usr/X11R6/man/ unless they use the imake program to
> + configure themselves before compilation.
Just nitpicking, but I'd like to see this worded a bit different
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> This policy revision is long overdue, since the transition away from the
> current policy is actually largely complete already.
I second this proposal.
--
Marcelo
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> +If the terminal emulator supports a command-line option of
> +the form "-e command", where this option causes a
> +new terminal window to appear running command, add
> +10 points.
> +If the terminal emu
Hi,
while trying to reproduce a bug against Window Maker, I had to install
gnome-panel. If one looks at the packages contents, one gets:
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/gnome-panel
/usr/share/doc/gnome-panel/copyright
/usr/share/doc/gnome-panel/changelog.gz
/usr/share/
>> Joey Hess <[EMAIL PROTECTED]> writes:
> > I would furthermore suggest that localization tasks have some extra
> > structure placed upon their names: e.g., task-language-zh,
> > task-language-ja, etc.
>
> I have some other ideas about those, they can just be automatically
> selected based
On Thu, Jun 10, 1999 at 02:02:35PM -0500, Chris Lawrence wrote:
> I further propose that the use of bzip2 be mandatory for newly uploaded
> source files
Upstream doesn't always provide .tar.bz2 packages.
Marcelo
Hi,
Where should I install X11 binaries? In /usr/bin/X11 or
/usr/X11R6/bin? If I have undestood this correctly, the idea is that
/usr/bin/X11 points to the current X11 release, i.e., if X11R7 comes
out, /usr/bin/X11 will point to /usr/X11R7/bin, right?
What happens with installed packages?
On Thu, May 06, 1999 at 05:34:46PM -0500, Ossama Othman wrote:
> As such, installing the `.la' files in `-dev' packages seems like a good
> idea, especially for static linking issues. Many developers do not
> include the `.la' files in the `-dev' packages. My proposal is to make
> packages that
On Tue, May 04, 1999 at 10:14:40PM -0700, Joey Hess wrote:
> > I suggest not using the term versioning to refer to sonames, it is
> > too easy to confuse it with symbol versioning.
>
> I used the term versioning because .la files contain 3 different version
> numbers.
yes, but those three numbe
On Tue, May 04, 1999 at 02:15:31PM -0500, Ossama Othman wrote:
>* Reverted my "correction" of the libltdl* package name. The soname
> of the libltdl libraries is currently 0.1.1, therefore the libltdl
> packages should be named libltdl0.1, according to current Debian
> policy.
On Wed, Nov 25, 1998 at 06:14:23PM -0600, [EMAIL PROTECTED] wrote:
> Arto Astala writes:
> > there was a related discussion about origin field in deb, so Debian
> > produced debs would have origin SPI
>
> Please choose something other than SPI. How about Debian?
Why not SPI?
[ Replies to debian-policy only please ]
Hi,
I'm struggling with WindowMaker 0.19.0 and I just noticed a "minor"
(yeah, right!) change in the way it parses configuration files at the source
code level. It will search for resources like this:
resourcePath/ext
arv[0]/ext
[ Manoj, do you want this on debian-policy or debian-devel? The ammount of
crossposting lately is making those lists even harder to read ]
> Secondly, Could this be made available on a web page somewhere?
Yes, please, Developer's Corner and/or DDP's pages seems like good places
to gather
On Mon, Jul 27, 1998 at 03:06:45PM +0200, Yann Dirson wrote:
> * Others ?
Source dependencies.
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On 16 Apr 1998, Stephen Zander wrote:
> I'm not sure that interpretation is valid. Documenation is
> written text, not software, and the copyright requirements &
> protections are much clearer under both common law & statutes.
> IANAL though.
I have the same questions. I (and another developer)
On Wed, 15 Apr 1998, Christian Schwarz wrote:
> So, the question is now whether a shared library *must* set
> SONAME or not. If it must do so, the gdk-imlib1 package has a
> bug (and probably others, too); otherwise Lintian has a bug (in
> which case it would be good to hear of a better solution
On 11 Apr 1998, Adam P. Harris wrote:
> I see four possible valid parties for closing bugs:
> * party is the maintainer
> * party is the submitter
> * party has been given permission by the maintainer to close the bug
> (i.e., the maintainer is soliciting support from another developer
>
On Wed, 4 Mar 1998, Ian Jackson wrote:
> Approval will not normally be granted except for the use of capital
> letters where there appear in an upstream package command name.
Was this approved? Christian?
I'm packaging Login.app, a graphical login prompt. The name of
the binary is Login.app, dot
On 29 Mar 1998, Ben Gertzfield wrote:
> 1) Copy /usr/share/libtool/lt* over the old lt*
that'd be: libtoolize --automake --force --copy
> 2) automake
> 3) aclocal
> 4) autoconf
> 5) build the package
Put all of this on the build target (or make a config-stamp
target, and make build depend on it
On Tue, 17 Mar 1998 [EMAIL PROTECTED] wrote:
> One of the irritating other things is that newer versions of libtool force
> -rpath.
Yes. And lintian generates a warning about that. Is it that
serious? I mean, should we, Debian, (again) patch libtool? It's
becoming a bit troubling to know we have
On 16 Mar 1998, Ben Gertzfield wrote:
> Do I remove the newer libtool from the upstream source and replace
> it with the current libtool in the Debian distribution?
add "libtoolize --force --copy" to debian/rules. This would make
your package source-depend on libtool. And automake maybe.
Definit
On 23 Feb 1998, Manoj Srivastava wrote:
> Marcelo> stuff like that. I modified it to use /etc/GNUstep/Defaults
> Marcelo> (sue me, I didn't ask here first -- now I realize I should
> Marcelo> have)
>
> Huh? There is an misunderstanding here. /etc/GNUstep/Defaults
> is great -- it is
On Sat, 21 Feb 1998, Marcus Brinkmann wrote:
> I assume that those files are useful to make debian packages more
> portable (?) and support auto{make,conf}.
More informative. More useful in a few cases (dlopen'ing). Not more
portable -- at least, I don't see how. libtool makes them after buildin
On Sat, 21 Feb 1998, Gregor Hoffleit wrote:
> I had packaged a previous snapshot, but ran into similar problems. I
> came up with the issues on debian-policy, but got no responses. I second
> your observations: GNUstep is not compatible with FHS/FSSTND and it has
> good reasons to do so. Making it
Seems like I managed to say everything on the subject... ;-)
Seriously, shouldn't the config files go in /etc/autofs/? It's
auto.master, and auto.misc right now, but I'd like to have auto.home for
several reasons, and /etc is becoming too crowded here.
I understand there's a "SUN does it this way
On Fri, 23 Jan 1998 [EMAIL PROTECTED] wrote:
> IMO, shared libraries should use `-lsomelib' for each library they directly
> depend on, not just `-lc'. For example, the LessTif shared library depends
> directly on Xt, Xext, X11 (and through them on other X libs). I have linked
> it "-lXt -lXext -l
On 14 Jan 1998 [EMAIL PROTECTED] wrote:
> > Is it necessary that we're allowed to change the content of documents in
> > main? I would like to package the standard documents from W3, but they
> > don't allow to change the content. And this makes sense, because this
> > documents are standard
54 matches
Mail list logo
