* Russ Allbery:
> Samuel Henrique writes:
>
>> I suggest making it more explicit by adding an example to it and
>> explicitly writing the precedence of them, I did some tests with dpkg
>> --compare-versions to confirm and found out that that is (n being a
>> number):
>> "~ - n + ." eg.: 1.0~0-1
* Steve Langasek:
>> Harden flags set AND ENFORCED on build environment(harden package)
>
> There is no way to "enforce" the use of hardening flags.
There is a way, involving multiple steps:
1. Put -grecord-gcc-switches into the hardening flags.
2. Make debuginfo packages mandatory.
3. Make fu
* Simon McVittie:
> On 23/08/15 11:31, Florian Weimer wrote:
>> For example, shipping i386 binaries instead of amd64 binaries is not
>> acceptable, even though these programs might run with the default
>> Debian kernel.
>
> This does not match current practice in al
Package: debian-policy
It seems to me that a requirement is missing from the policy that
binaries (DSOs and executables) which are intended to run on the host
must be located in a binary package, and the architecture of the
binary package must match the DSO/executable architecture.
For example, s
* Russ Allbery:
> Clearly no one else in the world is worrying about this; there's lots of
> GPLv2-only software out there and all the distributions are happily
> distributing binaries built with current GCC without worrying about this.
> I'm not sure to what extent we can use that as an excuse, t
* Lucas Nussbaum:
> It might be a good idea to forbid name conflicts, since some tools don't
> consider that they are totally different namespaces.
There's also the related issue that some binary packages have different
source packages on different architectures (and different versioning
schemes)
* Lucas Nussbaum:
> It might be a good idea to forbid name conflicts, since some tools don't
> consider that they are totally different namespaces.
There's also the related issue that some binary packages have different
source packages on different architectures (and different versioning
schemes)
* Russ Allbery:
> Andreas Barth <[EMAIL PROTECTED]> writes:
>> * Florian Weimer ([EMAIL PROTECTED]) [070630 10:16]:
>
>>> But do we really want to license everything which is "GPL version 2 or
>>> later" under the GPL version 3?
>
>>>
* Santiago Vila:
> + file. Packages should not refer to GPL and LGPL symlinks in
> + that directory since different, incompatible versions of these
> + licenses have been published by the Free Software Foundation,
> + hence using the symlinks could lead to ambiguit
* Lucas Nussbaum:
> Such a machine looks a bit strange (6 CPUs vs 256 MB RAM). I think that
> usually, modern SMPs have "enough" memory to handle what all their CPUs
> can do.
I'm not sure. 512 MB per execution unit is not too uncommen and may
cause problems for C++ packages (or MLton).
--
To
* Ian Jackson:
> To restore a package in state `triggered' to `installed', dpkg will
> run the postinst script:
>postinst triggered " ..."
Is this completely POSIX-conforming if there are many triggers?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble
retitle 336342 Clarify permitted epoch values
thanks
* Florian Weimer:
> Package: debian-policy
> Version: 3.6.2.1
> Severity: normal
>
> In section 5.6.12, the permitted epoch values are not specified
> precisely. Large epochs tend to cause problems for some tools, for
>
Package: debian-policy
Version: 3.6.2.1
Severity: normal
In section 5.6.12, the permitted epoch values are not specified
precisely. Large epochs tend to cause problems for some tools, for
example dpkg, whose behavior is even architecture-specific. There
might be other problems throughout the too
Joey Hess wrote:
> - Any others?
In the default configuration, web servers shall bind to localhost only
(okay, that's are more general policy issue affecting all network
services).
th such issues, but feedback
from GNAT distributors was not overwhelming, that's why it never
emerged from draft status.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
/adainclude/MODULE' directories. Additional linker
input files (e.g. static `.a' libraries) used by code in these
directories are stored here as well.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Previously Florian Weimer wrote:
> > Is it acceptable to put source files for non-C-related languages
> > (such as Python, Perl, Ada, Java, and so on) in subdirectories
> > under /usr/include?
>
> I'ld say no. T
Julian Gilbey <[EMAIL PROTECTED]> writes:
> On Wed, Nov 21, 2001 at 11:18:20AM +0100, Florian Weimer wrote:
> > Is it acceptable to put source files for non-C-related languages
> > (such as Python, Perl, Ada, Java, and so on) in subdirectories
> > under /usr/include?
Is it acceptable to put source files for non-C-related languages
(such as Python, Perl, Ada, Java, and so on) in subdirectories
under /usr/include?
It does make some sense, but I don't like this idea. Policy doesn't
seem to cover this issue.
--
Florian Weimer
ss of changing the section.
In addition, there are some architectures where all code is position
independent, so -fPIC is a noop, and others, where -fPIC is less
efficient then -fpic.
OTOH, the additions look okay to me.
> If the original submitter (Florian Weimer) objects to the above lang
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Previously Florian Weimer wrote:
> > Wouldn't it be nice if each general file management tool
> > (command line or text-based or graphical file manager)
> > supports 64 bit files (with 64 bit inode values or size
>
Package: debian-policy
Version: 3.5.6.0
Severity: wishlist
Wouldn't it be nice if each general file management tool
(command line or text-based or graphical file manager)
supports 64 bit files (with 64 bit inode values or size
greater than 2 GB) even on 32 bit architectures?
For ordinary applicat
his could be rectified -- with Unicode 3.1, they have the code
> space to represent each major representation of the character set.
IMHO, a better mechanism are Unicode 3.1 language tags, see:
http://www.unicode.org/unicode/reports/tr27/#tag
--
Florian Weimer[EMAIL P
urse ,these languages use the standard object file formats. They
simply do not support shared libraries well (think of the fragile base
class problem, or the effect of certain forms of name mangeling).
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Package: debian-policy
Version: 3.5.4.0
Severity: wishlist
In section 11.2, it is mandated that every library provides a static
and a shared version. I don't think this is appropriate, as there
are programming languages whose shared library support is still
evolving.
The whole discussion in thi
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Package which have a DFSG-compliant license and don't use a patented
> algorithm will be allowed in main (as happens right now).
Which algorithms qualify as "patented"? Those for which are patent
exists, or those where the patent owner has published
26 matches
Mail list logo
