On Mon, Mar 02, 2015 at 07:37:06PM +0100, Bill Allombert wrote:
> On Sun, Mar 01, 2015 at 05:59:39PM +0100, Yann Dirson wrote:
> > Package: debian-policy
> > Severity: wishlist
> >
> > Following the short discussion starting at [1], I'm submitting the
> >
Package: debian-policy
Severity: wishlist
Following the short discussion starting at [1], I'm submitting the
following list of virtual packages, to facilitate the declaration of
protocol compatibility between boardgame AI engines, boardgame GUI's
and protocol adapters:
* cecp-game-engine
* cecp-g
een threads enabled version of
ii kaffe-pthreads2:1.1.5-3 A POSIX threads enabled version of
kaffe recommends no packages.
-- no debconf information
--
Yann Dirson<[EMAIL PROTECTED]> |
Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux:
unning
just "make boot" succeeds with exit code 0, with -q I get:
biglook-alpha[1092]$ make -q boot; echo $?
>>> gtk
make: *** [boot] Erreur 1
2
=> obviously some command is run
=> make.info says for exit code 2: "It will print messages describing the
particular errors.&
have seen that running
"build" under fakeroot results in failure, because it modifies the build
environment in a way maybe not foreseen (which may be a bug but that's
another story).
--
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-rel
he
rules file, or to attempt to use build-arch and parse the output if
that failed - none of these alternatives seem reasonable to me.
Or did I miss something ?
[please CC me on followup]
--
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMA
hey shall in time. Policy is not documentation
> for dpkg and apt.
So it looks like this bug was file on the correct package in the first
place...
--
Yann Dirson <[EMAIL PROTECTED]> http://www.alcove.com/
Technical support managerResponsable de l'assist
of the former
"build" rule (which would not be as accurate), or we could have some
"build-all" target on which both "build" and "build-indep" (which
would complicate stuff, maybe with no good reason)
Do you think this is solid enough to be turned into
=français, LC_CTYPE=français
Versions of packages debian-policy depends on:
ii fileutils 4.1-10 GNU file management utilities
--
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> | Support Debia
e behaviour of the hint_optimize algorithm, which acts
that way if a submenu has too many items.
> I do feel
> that if we're going to do something about our categories, it should be
> a little broader in scope.
That's reasonable I think.
> Frankly, I'm more wo
4.1-7 GNU file management utilities.
--
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux:
Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity
ht
Package: debian-policy
Version: N/A; reported 2001-11-16
Severity: normal
I propose that we add a section under the "documentation" chapter, to
request a minimum of coherence and sanity of PostScript files.
My problem is that some maintainers (probably for paper-saving
reasons, which in itself is
On Thu, Apr 12, 2001 at 10:08:09AM +0100, Julian Gilbey wrote:
> Yann Dirson wrote:
> > Joey suggested:
> >
> > Here is one way we could reword policy:
> >
> > | 2.3.6. The base system
> > --
> > |
> > | The base system
On Thu, Apr 05, 2001 at 11:03:00PM +0100, Julian Gilbey wrote:
> > There is an occurence of this in in
> > section
>
> Is the problem that it should be "GNU General Public Licence" instead?
Sure, just like all other occurences - only this one is incorrect.
--
Yann
Package: debian-policy
Version: 3.5.2.0
Severity: normal
There is an occurence of this in in
section
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux bylbo 2.2.18+lvm+reiserfs #1 Thu Apr 5 00:40:42 CEST 2001 i586
Versions of packages debian-policy depend
You must not place any packages into the `base' section before this has
been discussed on the `debian-devel' mailing list and a consensus about
doing that has been reached.
Why not getting rid of the 3rd paragraph altogether ? It becomes
obsolete if the "base"
On Thu, Nov 02, 2000 at 10:52:31AM +0900, Masato Taruishi wrote:
> At Wed, 1 Nov 2000 23:17:07 +0100,
> Yann Dirson wrote:
>
> > As of now, I don't think a single patch package (including mines)
> > behaves correctly in all these areas. I have started a
> > `d
On Thu, Nov 02, 2000 at 10:52:31AM +0900, Masato Taruishi wrote:
> At Wed, 1 Nov 2000 23:17:07 +0100,
> Yann Dirson wrote:
>
> > As of now, I don't think a single patch package (including mines)
> > behaves correctly in all these areas. I have started a
> > `d
ead of the 'debian-patch' you used - it just
seems more natural to me. Again, comments welcomed.
revision 1.4
date: 2000/11/02 00:22:34; author: dwitch; state: Exp; lines: +11 -9
Changed debian/APPLIED_* to debian-patches/APPLIED_*
Regards,
--
Yann Dirson<[EMAIL PROTE
On Tue, Oct 03, 2000 at 02:54:38PM -0700, Joey Hess wrote:
> Yann Dirson wrote:
> > > Actually, dh_strip does more than install -s:
> > >
> > > foreach (@executables) {
> > >
> > > doit("strip","--remove-section=.c
On Mon, Oct 02, 2000 at 12:58:53AM +0200, Wichert Akkerman wrote:
> Previously Yann Dirson wrote:
> > This is usually wrong, as automake Makefiles also use INSTALL for
> > non-binary files.
>
> Afaik it uses INSTALL_DATA for non-binary files.
You're right. However:
On Sun, Oct 01, 2000 at 05:28:01PM +0200, Marco d'Itri wrote:
> On Sep 30, Yann Dirson <[EMAIL PROTECTED]> wrote:
>
> >Also, packages using debhelper may just call dh_strip and don't need
> >to care about adding -s flag to install.
> Actuall
Package: debian-policy
Version: 3.2.1.0
Severity: normal
Section 4.1 tells to use something like:
INSTALL = install
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL += -s
endif
This is usually wrong, as automake Makefiles also use INSTALL for
non-binary files. I tried this and got
Yann Dirson writes:
> Joey Hess writes:
> > No, there are references to base in policy.
>
> Ah yes, how did I miss it ... ? Looks like it's just defined the way
> it is not used, so throwing it out may not be a big deal :)
>
> > See my post to debian-p
2.1.7. Subsections
"The packages in the _main_, _contrib_,
and _non-free_ sections are grouped further into _subsections_ to
simplify handling of them".
This is also true for "non-US", I think ?
2.3.2. The maintainer of a package
"If the maintainer of a package quits from the Debian project t
ht of using them in France. Such hardware
was labeled "for export only". Nice, eh ?
In short: if we're going to build a *general* framework, Oliver's
suggestion suits me fine.
--
Yann Dirson | Stop making M$-Bill richer & richer,
t least, not for dealing with prerelease issues. They will still be
needed when upstream change their numbering scheme in an incompatible
way, which is anyway the reason they exist for ...
--
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email: <[EMAIL
_1
* foo_2 has to be downgraded as well
> /section/ is used to mean one of main, contrib, non-free or non-us.
That seems to conflict with current usage (Section:
{admin,math,...}). I think some of us refer to this as
"distribution"... maybe some other word should be found ?
--
Yann Dir
Jules Bean writes:
> On Mon, 27 Jul 1998, Yann Dirson wrote:
>
> >
> > * DTM support (Definitive Type Manager, formerly Debian Type Manager)
> >
> > Federico di Gregorio: (La)TeX support is not yet ready.
>
> Is there a URL for this one?
Don'
dpkg(8) should go into package dpkg, for
> example?
That's what I meant. I think it would be consistent.
--
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMA
rge networks of Debian (eg easier
centralized control/maintenance/install of 20+ Debian machines)
* Package descriptions in several languages.
Needs dpkg support ? Or only dslect/apt support ?
* Others ?
--
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-em
Raul Miller writes:
> Yann Dirson <[EMAIL PROTECTED]> wrote:
> > Hey, could someone please explain what a *negative* meaning would be
> > good for ? I think I already argumented against that earlier in this
> > tread (or was it a private mail to Jason ?), but so f
gative* meaning would be
good for ? I think I already argumented against that earlier in this
tread (or was it a private mail to Jason ?), but so far I read no
arguments *in favor of* this.
Now that I'm back, I'll happilly go on summarizing pros and cons, but
that'll still need som
es on other archs, sent to the maintainers (I
remember receiving at least 1), but it seems to have been dropped ?
Maybe an archive of compilation logs could be kept somewhere ? That
would also have the benefit of easily seeing how much one's package
have been compiled on other archs.
--
Yann
> so, I think we need to fix the policy.
Hm, does anyone knows what is VISUAL exactly intendend for ? I'm
thinking of some setting like `EDITOR=ed' and `VISUAL=vi'. If it's
really what was meant for a use of VISUAL, I'd say it's not needed any
more ...
--
Yann
`manpages' and
`manpages-' packages, but in their relevant binary packages.
* DTM support (Definitive Type Manager, formerly Debian Type Manager)
- Federico: do you think it's feasible ?
* Others ?
--
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer &
Jason Gunthorpe writes:
> If any of you recall my proposal and request for a Revision file, since
> there were no objections can we make this happen?
Hm, I don't... can you point us to the initial proposal ?
Regards,
--
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bil
27;m not
sure we need that, as we have a know number of dists to update, and we
can write: 1.1-9~1bo << 1.1-9~2hamm << 1.1-9 - I don't think we are
still updating rex, are we ?
However, I think having the following could prove useful, and may be
more intuitive:
1.1~1 &l
es to dpkg. If someone can
do it soon, I'd say let's go for it ASAP.
--
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | mor
pkg --compare-versions 2.0pre1 '<<' 2.0.0 && echo yes || echo no
yes
This case is already covered in latest summary, too.
--
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email: <[EMAIL PROTECTED]> | support Deb
ry's proposal, adding an optional numeric
argument to the `~':
Eg: 1.0pre => 1.0~pre
1.0alpha=> 1.0~1alpha
1.0beta => 1.0~1beta
1.0 => 1.0
`~' followed by no numeric would be equivalent to `~0'. Th
tending them so that they can
> apply to subcomponents (the advantage here is that a subepoch reflects
> more accurately the versioning problem and, as soon as a more major
> version change occurs, the subepoch can be discarded).
Well, maybe you're right. Both mechanisms may b
case of this one, where by
giving "X1-k:" you mean "Xk = 1", and "Xi = 0 for i not in {1,k}"
Pro: - non-persistent epoch for version sublevels
- not found a plausible numbering sequence that could not be
handled. Please help me to find one. Even the
nd myself
I could not find a [1] in the text.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | more powerful, more stabl
ng to deb-policy, so warn your
CC: - I only added it in mine so that people who raised an interest in
such issues in the previous thread read it]
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Deb
ct-logical dep as well.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | more powerful, more stable !
http://www
n lpr' giving the english manpage
for lprng's lpr...
I think we should instead make it policy to include all section 1
manpages, including translated ones, into the relevant binary
packages. I can see that as a meaningful goal for slink.
--
Yann Dirson <[EMAIL PROTECTED]>
al', this could go there--but since
> we don't do a lot of programming ourselves, we'll probably never have such
> a manual.
Unfortunately, you're probably right :(
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email:
would simplify the handling of this problem.
Also, i think lintian will make it possible to automate the
mass-reporting.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian
his except for Christian, but I saw no
objections to its use.
What do other think ?
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]
ld be run
in an environment where LC_ACC is set to a fixed value,
preferably "C", or all locale-influent variables (see the output of
"locale") are unset.
IMHO, this should be made Policy ASAP.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer &
Kai Henningsen writes:
> Bad idea. You forget that du -S only has _directory_ names.
Ah, yes, I did. I was convinced .du files had size info for every
file.
However, if we use .md5sums files, .list files will be useless. A
more generic and standardized format would be better.
--
Yann Dir
Yann Dirson writes:
> > Let's embrace open standards and open-ended architectures as deeply as we
> > can.
>
> Yep, I didn't think of that, but it's much nicer.
But OTOH, using SGML or XML will probably take more disk-space than
would be strictly necessary
contents ?
And it's not because we don't have it for other similar mechanisms
that these mechanisms wouldn't benefit for such an improvement
themselves. Some generic support for this type of thing would be
nice.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop
ontrol files instance the data that
> way.
>
> Let's embrace open standards and open-ended architectures as deeply as we
> can.
Yep, I didn't think of that, but it's much nicer.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill rich
s:
* to put them in experimental only, unless otherwise necessary
* to use the "2.0.6.pre2.0.7-3" style of numbering, for homogeneity
purpose
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> |
Manoj Srivastava writes:
> Hi,
> >>"Yann" == Yann Dirson <[EMAIL PROTECTED]> writes:
>
> Yann> Manoj Srivastava writes:
> >> Hi, "Luiz" == Luiz Otavio L Zorzella <[EMAIL PROTECTED]>
> >> writes:
> >>
> Lu
e a symlink to somewhere else.
Ah yes. Then we should better officially state which dirs can be
symlinks to other places, and which can be safely traversed by
relative paths. Otherwise paragraph 3.3.5 in the policy manual may be
quite inadequate.
--
Yann Dirson <[EMAIL PROTECTED]> |
with {pre,alpha,beta}-like numbering. It is
perfectly sane to distinguish between "it's in testing stage" and
"it's released software", and we should IMHO support such a thing.
Anyone against that ?
--
Yann Dirson <[EMAIL PROTECTED]> | Stop m
1st lines defines what info is contained in the
file. As policy will be involved, it would maybe be more interesting
to list a file-format-version number on this 1st line.
Comments, anyone ?
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
et put the solution into the policy
> document yet (we do have an implementation).
Why ? I know that Installed-size: will get fooled if we can one day
exclude dirs from installation, but it doesn't seem to matter for now ?
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-B
anything about the
quite common case where a lib is in /lib/, and its dev link in
/usr/lib/.
On my installation, all such links are relative, so I suppose it's not
a mistake from me, and it is probably a lintian bug, or is there
really a reason of using absolute links there ?
--
Yann D
ll as many apps just using the X
interface in section "x11" (qps, asmodem ...)
[Note: I'm off for ~10 days]
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debi
other packages.
Yes, it is FSSTND compliant, as long as there are links to all dirs
under /usr/share, and that no app uses /usr/share directly.
How do you understand that ?
Should I set up /usr/lib/kbd/* links to /usr/share/ again ?
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making
Will Lowe writes:
> On Fri, 30 Jan 1998, Yann Dirson wrote:
>
> > [6.3] "The directory /usr/share typically contains
> > architecture-independent files such as man-pages, timezone, terminfo
> > information, etc."
> [...]
> > As of this time, w
ersonnally don't see any good in those links, except for
compatibility purposes. But I may well be missing some important
point.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/
ackages.debian.org" addresses, which I
find damnly useful !
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | more
d not be done as I did till
now (ie. using doc/comerr2/ for package comerr2g).
I now think that the policy itself should not be changed in this
respect, but it may be a good idea to add a recommendation about the
use of symlinks to allow duplication.
--
Yann Dirson <[EMAIL PROTECTED]>
such as Ian Jackson,
> who use multiple addresses to filter e-mail.
So do I.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]>
this "g" ?
But it will cause a problem when there are libc5-compat packages that
do not depend on their libc6 counterpart [I think it is allowed ?].
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED
r so I've been told here before.
This raises a question I've thought for several days now: is there a
mean of asking the system what shared libs are currently loaded ?
I thought of a /proc entry, but could not find one.
Such a thing would surely be useful to detect/verify such
assump
Christian Schwarz writes:
> On Thu, 22 Jan 1998, Yann Dirson wrote:
>
> [snip]
> > Yes, but that's not what I meant. The issue is about the lib's
> > minor/pl rev. numbers (in the case of what I call a non-standalone
> > lib[1], which is not the case of
[EMAIL PROTECTED] writes:
> On Fri, Jan 16, 1998 at 08:36:39PM +0100, Yann Dirson wrote:
> >
> > If I get no objections, e2fsprogs_1.10-11 will be shipped with
> > comerr{2g,g-dev}_2.0-1.10-11.
>
> It was my convincement that policy said that library's bi
Christian Schwarz writes:
>
> [Sorry for the late reply.]
>
> On Fri, 16 Jan 1998, Yann Dirson wrote:
>
> > Hi there,
> >
> > Some upstream packages (eg. e2fsprogs) contain shared libraries which
> > can be debian-packaged in their own packag
Rob Browning writes:
> The packages can use update-alternatives here to make sure that when
> magicfilter's uninstalled, lprng's printcap comes back.
If this is done, I'd think diversions are a better way to do that.
--
Yann Dirson <[EMAIL PROTECTED]> |
0-11 will be shipped with
comerr{2g,g-dev}_2.0-1.10-11.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | more powerful, more
Christian Schwarz writes:
> However, I'm still looking for volunteers that could me with some design
> issues of doc-base. (I already have one volunteer.) So if someone is
> intrested, please drop me a note.
I _may_ find some time to think about it - I'll let you know
Santiago Vila Doncel writes:
> Yann Dirson wrote:
> > I remember there once was some discussion about whether/where to
> > install HTML docs created from .texi files. If I remember well, we
> > mostly agreed that we should install them in a subdirectory of the
>
made policy.
What's the current status of this ?
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | m
Enrique Zanardi writes:
> On Fri, 5 Dec 1997, Yann Dirson wrote:
> > I guess translated manpages should be included in the relevant
> > packages, with probably a notice as to which version of the software
> > they document.
>
> The con is that packages get v
with probably a notice as to which version of the software
they document.
Should there be a policy set up on this issue on debian level ? It is
IMHO a problem which should be (and probably already has been) raised
on a higher level (translating teams, I think).
Has anyone clues on this subject ?
"/'
mv libtool-2 libtool
chmod 755 libtool
;;
esac
=
This just causes libtool to replace the -rpath setting by a inofensive
define, and everthing seems to work well. My piece of code may surely
be improved though.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-
..)
>
> Yes, I prefer something like `xfonts-path { --add | --remove }' tool, which
> would edit appropriate config files and restart appropriate daemons.
But it should IMHO be able to handle `xfs' configuration as well. See
issues in my previous mail in debian-devel ("problem
stuff, ie. /usr/local/. In the latter
case, I think the proper place to put them would be /usr/local/share/
as well.
I think section 3.1.2 of the policy manual would be in favor of the
latter.
What to others think ?
--
Yann Dirson <[EMAIL PROTECTED]>| Stop making M$-Bill richer &am
84 matches
Mail list logo
