On Sep 09, Sean Whitton wrote:
> 1. Is the 'should not' for the /etc/default practice too strong? I
No, because it cannot be supported in a sane way by systemd units.
It should even be "must not".
--
ciao,
Marco
signature.asc
Description: PGP signature
I can see there are some daemons (like junkbuster and maybe syslogd)
which runs as root even if they could run as a non priviledged user.
What about adding a policy statement to outlaw that?
A --user option could be added to start-stop-daemon.
--
ciao,
Marco
On Oct 30, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> To prevent having to use epochs for every new upstream version, the
> version number should be changed to the following format in such
> cases: `1996-05-01', `1996-12-24'. It is up to the maintainer whether
What about 960501?
On Dec 07, Thomas Roessler <[EMAIL PROTECTED]> wrote:
>> 30433 mutt: Mutt doesn't create the user's mail file as dictated by
>> policy manual
[...]
>The reason for this is simple: From a least-privilege point of view,
>the one and only privileged operation a MUA ever needs to perform is
>lo
reassign 31441 debian-policy
thanks
Looks like this is not a bug in mutt, so I'll reassign it to the policy
package.
--
ciao,
Marco
On Feb 09, Shaleh <[EMAIL PROTECTED]> wrote:
>Seems like a good idea. Maybe we can even get a Debian BSD someday (= The
>BSD's could use a nice packager like dpkg.
AFAIK the do not want to use it because it is GPLed.
--
ciao,
Marco
On Mar 28, Martin Schulze <[EMAIL PROTECTED]> wrote:
> - critical security fix:2 days.
I think those fixes should be uploaded as fast as possible by anyone
willing, if a remote root exploit for some package like apache or ssh
is published users can't just shut down their machines fo
Users' $PATH is set in different places: /etc/profile, /etc/login.defs
and different programs (login, ssh) read it from different files.
Should we estabilish a policy on this issue?
--
ciao,
Marco
On Apr 28, Balazs Scheidler <[EMAIL PROTECTED]> wrote:
>I have posted a logrotation proposal on -devel which I copy here too (with
>some slight modifications), so that the required policy modifications can be
>made.
Seconded. It's about time we design a consistent way of managing logs.
--
c
Package: debian-policy
On May 06, Joseph Carter <[EMAIL PROTECTED]> wrote:
>No. Contrib gets two types of packages: Those packages that require
>linking with non-free software and those packages that cannot be built
>from the source package without installing non-free software. In theory
I
On May 09, Julian Gilbey <[EMAIL PROTECTED]> wrote:
>(1) That section 3.1 of the policy be rewritten replacing every
>reference to "FSSTND" by the equivalent reference to "FHS".
Seconded.
--
ciao,
Marco
On May 09, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>There is a slight problem though: utmp. Currently only root can update
>the utmp. To solve this I propose we create an utmp group and put in
>policy that programs that want to modify the utmp should be setgid utmp
>instead of setuid root (
On May 09, Joseph Carter <[EMAIL PROTECTED]> wrote:
>Do we consider things like libgif3g candidates for non-us/main? That's
>currently sitting on NON-FREE because of the stupid patent on lzw! IMO
>that's just like wrong or something. =>
We should. If your country has silly patent laws it's
On May 08, William Brioschi <[EMAIL PROTECTED]> wrote:
> In addition, the packages in "main"
> * must not require a package outside of "main" for compilation or
> execution (thus, the package may not declare a "Depends" or
> "Recommends" relationship on a non-main package),
On May 10, Joseph Carter <[EMAIL PROTECTED]> wrote:
>Being that logrotate is my package, I second the proposal. Note the
Will logrotate be an essential package?
--
ciao,
Marco
On May 10, Joel Klecker <[EMAIL PROTECTED]> wrote:
>That is not correct, the UNIX98 pty interface in glibc 2.1 does not
>require a 2.2 kernel. grantpt() can use BSD ptys and the pt_chown
>program in the absence of kernel support for UNIX98 ptys.
So that means if I have /dev/pts I can chmod -s
On May 10, Joey Hess <[EMAIL PROTECTED]> wrote:
>Unfortunatly this change really makes no difference. Being patented _is_
>being "encumbered by legal issues". You've just removed an example of a
Encumbered in which country? In many countries (including the one
where non-us.debian.org resides) s
On May 12, Richard Stallman <[EMAIL PROTECTED]> wrote:
>Which country is that? If it is in Europe, I am afraid
>the situation may be about to change.
I know that.
>I'd like to know RMS' opinion on the issue: why should I suffer from
>silly laws of other countries?
>What, precisely,
On May 20, "Karl M. Hegbloom" <[EMAIL PROTECTED]> wrote:
> I've noticed that there is currently a `uucp' group, a `dip' group,
> and a `dialout' group. Do we really need all three? What is the
Yes. uucp is used by the UUCP program, dialout owns the modem device and
dip can start pppd and dip.
n May 21, "Karl M. Hegbloom" <[EMAIL PROTECTED]> wrote:
>>> `minicom' is group owned by `uucp'.
>Marco> This is wrong. BTW, it's not even sgid, so I see no reason
>Marco> to chown the binary to the uucp group.
> Should it be `chgrp dialout', with o-x? Or root.root, o+x, and rely
On May 30, Joey Hess <[EMAIL PROTECTED]> wrote:
>Software depending on non-US (#37251)
> * Stalled for 1 week.
> * Proposed on 06 May 1999 by Marco d'Itri; seconded by Gordon
>Matzigkeit, Joseph Carter, Chris Waters and Davide G. M. Salvett.
> * Propo
On May 30, Julian Gilbey <[EMAIL PROTECTED]> wrote:
>In other words, is it OK to announce the move to FHS on
>-devel-announce so that developers can start making the necessary
>changes to their packages?
We should wait for FHS 2.1, some of the changes in 2.0 like /var/state
will be removed.
-
On Jun 05, Joey Hess <[EMAIL PROTECTED]> wrote:
>Software depending on non-US (#37251)
> * Stalled for 2 weeks.
> * Proposed on 06 May 1999 by Marco d'Itri; seconded by Gordon
>Matzigkeit, Joseph Carter, Chris Waters and Davide G. M. Salvett.
> * Propo
On Jun 06, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>> * Proposal to allow software that depends on software in non-us into
>> main (currently restricted to contrib).
>> ( This may be unnecessary given the recent re-org of non-us. )
>
>I'm not sure I like this one. This would mea
forwarded 39030 [EMAIL PROTECTED]
thanks
On Jun 07, Thomas Osterried <[EMAIL PROTECTED]> wrote:
>we neither had chaching-problems, locking-problems nor data-corruption
>etc before. but now, we have had a complete data loss.
I remember a maybe similar problem related to the attribute caching
of
On Jun 07, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>I disagree here. Personally I would be very annoyed if I got a
>CD (an official CD even) and then discover that there are packages
>in main that don't work. The frustration that can gave greatly
>outweighs the fact that you save people a
On Jun 07, Ruud de Rooij <[EMAIL PROTECTED]> wrote:
>> Maybe you don't pay for download time or/and have good cheap ISPs in
>> your country.
>If download costs are a problem, buy a non-US CD from a European CD
>vendor.
There aren't cheap vendors.
>Shipping CD's with broken dependencies is not
On Jun 08, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>+ The files /var/run/utmp, /var/log/wtmp and
>+ /var/log/lastlog should be installed writeable by group
>+ utmp. Programs who need to modify those files should be installed
>+ install setgid utmp.
Why lastlog too?
On Jun 30, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> capitalization of The X Window System in section heading. Any other
> flaws? Shall I renumber it to 3.0.0.0 and send it along?
Did you look at the FHS 2.1 draft? Some of the new things in FHS 2.0
like /var/state have been removed from the s
On Jul 02, Brian May <[EMAIL PROTECTED]> wrote:
>Another problem is setting the environment variables, eg MAIL and
>MAILDIR in one place for a system wide policy.
>
>Comments?
I think programs should look in $MAIL for a mbox mailbox.
Maybe in $MAILDIR too for a maildir mailbox, I don't know.
On Jul 03, joost witteveen <[EMAIL PROTECTED]> wrote:
>When the translating of menus comes up, gnome/kde automatically also
>come up as they already have translations. So, why not use those?
>Well, for the above mentioned reasons: "cross-package" communication
>is pour to say the least in de
On Jul 06, joost witteveen <[EMAIL PROTECTED]> wrote:
>But for now, I hope you like the progress being made so far.
I don't. You haven't replied to my concerns.
--
ciao,
Marco
On Jul 08, joost witteveen <[EMAIL PROTECTED]> wrote:
>> Very, very bad. Most gnome/kde programs already have translations. Do
>> you plan to override them? Or do you plan to prune unneeded translations
>> from the menu package?
>I don't plan to do anything with them. They sit in their own
On Jul 09, Joey Hess <[EMAIL PROTECTED]> wrote:
>* keeping the translations in the hands of the developers, and in the
> package it comes from, where it really belongs in the long run
Agreed. I would have no objections to a scheme with translations in
/usr/lib/menu/ files.
--
ciao,
Marco
On Jul 10, joost witteveen <[EMAIL PROTECTED]> wrote:
>> It should not need duplicate data for these program but get the needed
>> information from the native menu entry which comes with the package.
>Please bear in mind that the menu system was designed when all
>window managers available di
On Aug 26, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
>> But only fcntl() locking is not enough, because Linux 2.0.* doesn't
>> support this over NFS and then we have no locking over NFS.
>
>And linux 2.2.x with a userland server also does not support fcntl
>locking, it generates an annoying
On Aug 27, Philip Hands <[EMAIL PROTECTED]> wrote:
>mbox format mail is not safe over NFS even if there is locking.
Is not safe if there is a crash, but otherwise it works.
>So perhaps we should mandate that all mail programs should be capable
>of using Maildir format, which is NFS safe witho
On Aug 27, Joseph Carter <[EMAIL PROTECTED]> wrote:
>Don't you even... (I use that sort of system here on this machine, but it
>should NOT be the default!) Before you even consider that solution you
>need to address people who don't have a ~ to put a mailbox in (ie a mail
On debian every user
On Aug 27, Seth R Arnold <[EMAIL PROTECTED]> wrote:
>Please forgive someone new to debian -- the benefits of moving to Maildir
>format for NFS-based systems seems obvious, if it removes lock-contention
>problems. However, wouldn't that mean mutt would be the only mailreader
>supplied with Debi
On Sep 19, Joseph Carter <[EMAIL PROTECTED]> wrote:
>I think the practice of using static IDs should be deprecated (and
>packages doing it should get lintian warnings..) I disagree with banning
Please provide a rationale. Some of my packages need a static ID (64000
is assigned, the only one assi
On Sep 20, Brian May <[EMAIL PROTECTED]> wrote:
>What packages need a ID that could be shared over NFS? ie what
>packages *need* a static ID?
The packages related to fidonet. The suite needs both a news server and
a modem, so it's not an uncommon setup to run ifcico on the machine with
the mode
On Sep 20, Joseph Carter <[EMAIL PROTECTED]> wrote:
>And my home directory could be NFS stored---does that mean that uid/gid
>1000 should always and forever belong to knghtbrd on every system?
If your site has NFS mounted home directories then all user accounts
are be created by the admin with
On Sep 20, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
>> >Please provide a rationale. Some of my packages need a static ID (64000
>> >is assigned, the only one assigned so far) because their spool could
>> >need to be NFS shared.
>
>static user id´s are a _problem_ with nfs, not a help.
>
On Oct 02, Raul Miller <[EMAIL PROTECTED]> wrote:
> `Non-free' contains packages which are not compliant with the DFSG.
Seconded.
--
ciao,
Marco
On Nov 15, Richard Braakman <[EMAIL PROTECTED]> wrote:
>We'll have to find another place for packages that are patent-encumbered
>in weird ways, if any show up.
All packages using LZW (used by the GIF format) or RSA.
--
ciao,
Marco
On Jan 23, Nicolás Lichtmaier <[EMAIL PROTECTED]> wrote:
>> Http_proxy and web clients (#54524)
> Nobody else want this? I thought we all agreed on this one...
I'd like to see that in policy, but only if the programs use $no_proxy
as well.
--
ciao,
Marco
On Feb 06, Lazarus Long <[EMAIL PROTECTED]> wrote:
>Package: mutt
>Version: 1.1.2-1
>Severity: critical
Please stop harrassing me or I'll have to killfile you AND automatically
close all bug reports you open.
--
ciao,
Marco
On Mar 28, Santiago Vila <[EMAIL PROTECTED]> wrote:
>The /var/log directory should have permissions 2775 (group-writable and
>set-group-id) and be owned by root.adm.
>
>Rationale: root.adm is a better default than root.root.
This isn't a rationale, it's more like a joke.
Please explain the pur
On Apr 05, "Thomas Bushnell, BSG" <[EMAIL PROTECTED]> wrote:
>I think it should be a requirement that Debian maintainers have email
>addresses which accept all validly formatted email, at least in
>response to bug-reporting discussions. Is this controversial?
Yes.
--
ciao,
Marco
On Apr 24, Santiago Vila <[EMAIL PROTECTED]> wrote:
>I'm looking for seconds for this proposal.
Seconded.
--
ciao,
Marco
On Nov 01, Bill Allombert wrote:
> Is there alternative documents describing the interfaces for packages to
> interoperate with systemd, and transition documents available for packagers
> and
> users that need to adapt to the new system ?
Partially.
I have been working on https://etherpad.fr/p/
On Aug 27, Guillem Jover wrote:
> Disallowing such compatibility symlinks means that those programs
> can no longer be moved between directories w/o possibly breaking
> things that use absolute pathname, which should be considered a bug
> in Debian, but is something that still happens. And local
On Aug 27, Russ Allbery wrote:
> I wanted to open this discussion, but it's not clear whether we're ready
> yet to actually merge this patch.
We are now: there are less than 10 packages left which have not been
fixed, all of them with patches
I am attaching a revised text.
--
ciao,
Marco
diff
On Jan 24, Jakub Wilk wrote:
> I couldn't find bugs for these packages:
Thank you. Hopefully now that the lintian check has been merged we
should not get many new bugs...
> * yp-tools + hostname:
I opened #812532, looks like my development/check-contents script is
buggy since it missed this on
On Jan 24, Marco d'Itri wrote:
> > I wanted to open this discussion, but it's not clear whether we're ready
> > yet to actually merge this patch.
> We are now: there are less than 10 packages left which have not been
> fixed, all of them with patches
We are dow
On May 03, Josh Triplett wrote:
> While this doesn't make PIC absolutely free, it does eliminate almost
> all of the cost, to the point that it no longer seems worthwhile to
> build without -fPIC. Apart from that, building *all* code with -fPIC
> (including both programs and libraries) helps wit
On May 08, Brian May <[EMAIL PROTECTED]> wrote:
>I don't think the other options are required or needed. However, some
>way to override these defaults on a per user baisis is important
>(eg in case a user needs a non-default location for some reason).
We have it:
For MUAs: $MAIL.
For MTAs: ~/.
On May 11, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>> This is good, if you can survive if the package doesn't get on every
>> official Debian CD set.
>My favourite, stresses freedom and keeps the archive consistent.
This is not about freedom, maybe about stupid laws of the country where
mas
On May 15, Richard A Nelson <[EMAIL PROTECTED]> wrote:
>I just realized that the sendmail update I made this weekend
>8.11.0.Beta1 should probably be removed from its home in US/Extra/Mail
>because the source (and binary) has hooks for SASL and TLS.
Mutt >= 1.1 has TLS and Kerberos hooks too.
On May 15, Richard A Nelson <[EMAIL PROTECTED]> wrote:
>But, yes, 8.11.0.Beta1 *IS* linked against libssl09 ;-{
This is bad, because then the sendmail package depends on something
outside main.
(mutt does not.)
--
ciao,
Marco
On May 16, Julian Gilbey <[EMAIL PROTECTED]> wrote:
>I'll make a fetchmail-ssl package if noone else wants to; I'm using a
>locally compiled copy myself right now.
Look at the dlopen trick I implemented for the mutt woody package.
--
ciao,
Marco
On Jun 20, Julian Gilbey <[EMAIL PROTECTED]> wrote:
>Where do we go from here? Do we steam ahead and make it policy or
>what?
Yes, please.
--
ciao,
Marco
On Aug 17, Santiago Vila <[EMAIL PROTECTED]> wrote:
>Now that potato has been released, I propose that we start deprecating
>the /usr/doc compatibility symlinks, at the same time we make
>using /usr/share/doc a nearly-release-goal for woody.
Seconded.
--
ciao,
Marco
On Aug 19, John Ackermann <[EMAIL PROTECTED]> wrote:
>I heartily agree with Daniel's plea. Eveb a simple listing of what
>configuration files the package uses (and where they are), and where it
>stores data (i.e., does it use space in /var) would be a big help.
less /var/lib/dpkg/info/.list
On Sep 21, Joey Hess <[EMAIL PROTECTED]> wrote:
>Using an existing group like bin could cause problems. It's possible
>systems exist that have users in the bin group and don't expect them to
>suddenly be able to edit every file on the system. (What is the bin
I don't agree. Being the owner of s
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.
Actually, dh_strip does more than install -s:
foreach (@executables) {
doit("strip","--remove-section=.comment","--remove
On Jan 11, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Programs which use patented algorithms that have a restrictied
> license must also be stored on "non-us", since that is located in a
> country where it is not allowed to patent algorithms.
But is it non-US/main or non-US/non-free?
On Jan 11, Drake Diedrich <[EMAIL PROTECTED]> wrote:
> Due to the dilligence of our security agencies the blacklisted 7 are not
>on the Internet (the official US govt line IIRC). At the very least it
>appears They've made it difficult to get IP numbers and DNS names if you're
>blacklisted.
On Jan 12, Peter S Galbraith <[EMAIL PROTECTED]> wrote:
>> What's weird about that?
>
>In tcsh:
>
>$ mh
>/usr/bin/mh: Permission denied.
So tcsh is broken. Big news.
--
ciao,
Marco
On Jan 19, Julian Gilbey <[EMAIL PROTECTED]> wrote:
>I guess that it should be an optional package; there's no reason for
>policy to be installed on a default system. What do others think?
I agree, the policy document is only needed by debian developers.
--
ciao,
Marco
On Feb 03, [EMAIL PROTECTED] wrote:
>What workable alternative would there be to using
>/usr[/local]//(bin|lib|include)?
/usr/lib//...
--
ciao,
Marco
On May 14, Julian Gilbey <[EMAIL PROTECTED]> wrote:
>You can always keep the old changelogs in the source package only.
We have archive.debian.org for the old things. As long as the entries
are archived in a released distribution I think it's fine to snip them
and save the disk space of all our u
On Jun 01, Cesar Eduardo Barros <[EMAIL PROTECTED]> wrote:
>Ask the IETF. They seem to like UTF8 a lot.
Because it's ASCII-compatible. This is not relevant.
>Ask Linus too. The UTF8 support is in the kernel since, what, 2.0.x?
Because it's ASCII-compatibile. This is not relevant.
UTF-8 maybe b
On Jun 01, Josip Rodin <[EMAIL PROTECTED]> wrote:
>Nice things these general tendencies... in my country we still have problems
>using ISO 8859-2 because Windows 1250 has polluted everything. Adding
>another one to the pile is likely to screw things up even more.
This is the reason we can't ju
On Jun 01, Radovan Garabik <[EMAIL PROTECTED]> wrote:
>[*] I'd like to type naive properly, with i-diaeresis, but I just cannot,
>since it is not in ISO-8859-2 encoding my console is switched to
I'm not arguing about this. I agree that in a perfect world everybody
would be using unicode, encoded
On Jun 01, Roland Mas <[EMAIL PROTECTED]> wrote:
>> Most people (with the possible exception of part of the CJK
>> community) do not want to use unicode yet, deal with it.
>
>Excuse me? "With the possible exception of the CJK community"? What
>about people speaking (and writing/typing) Arab
On Jun 01, Roland Mas <[EMAIL PROTECTED]> wrote:
>now we miss the euro sign too. The transition to Latin-9
>(ISO-8859-15, with the euro and the missing characters) is *already*
>causing *major* nerve breakage amongst people.
Right. It's already bad when broken applications don't work well with
On Jun 01, Arto Jantunen <[EMAIL PROTECTED]> wrote:
>> I'm not arguing about this. I agree that in a perfect world everybody
>> would be using unicode, encoded as UTF-8 or UTF-16. My point is that
>> there is too much broken software to switch now to UTF-8.
>What we are talking about here is a
On Jun 01, Radovan Garabik <[EMAIL PROTECTED]> wrote:
>> >using ISO 8859-2 because Windows 1250 has polluted everything. Adding
>> >another one to the pile is likely to screw things up even more.
>> This is the reason we can't just switch the terminals to UTF-8, there
>> are way too many pr
On Jun 03, Radovan Garabik <[EMAIL PROTECTED]> wrote:
>2) Require using utf8 in debian control files (debian/changelog,
>debian/control,
> Packages). This is not such a great change as it seems, since it will mean
> only replacement of a few characters in a few packages (currently using
On Jun 03, Radovan Garabik <[EMAIL PROTECTED]> wrote:
>If, for whatever reason (such as upstream author's or maintainer's
>names, foreign language package description and similar), you need to
>use characters outside 7 bit ASCII range in control files, these
>characters must be encoded using U
On Jun 04, Radovan Garabik <[EMAIL PROTECTED]> wrote:
>> >If, for whatever reason (such as upstream author's or maintainer's
>> >names, foreign language package description and similar), you need to
>> >use characters outside 7 bit ASCII range in control files, these
>> >characters must be
On Jun 06, Radovan Garabik <[EMAIL PROTECTED]> wrote:
>but: JIS is japanese only, UCS-4 is global
>UCS-4 can (and will) be easily expanded, there are no technical
>problems in adding characters to this encoding
Please explain, why the fuck can't you stop trying to force UTF-8 on
communities wh
On Jun 08, Radovan Garabik <[EMAIL PROTECTED]> wrote:
>TELL ME HOW IN THE HELL I CAN WRITE A MAIL WITH WORDS FROM
>HUNGARIAN, SLOVAK, RUSSIAN AN JAPANESE TOGETHER
You and him configure your MUAs to use some unicode encoding and deal
with any resulting problem which may happen.
No need to for
On Aug 19, Cesar Eduardo Barros <[EMAIL PROTECTED]> wrote:
> eximconfig) and all the MUAs must be able to grok it without needing any
> manual configuration
Are you offering to be the one which will patch everything and make the
upstream maintainers merge maildir support? And don't forget PO
On Aug 19, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>>(it usually is not, and it definitely is not for
>>tipical POP servers).
>Still, deleting messages from a mbox-style mailbox means copying
>the entire mailbox usually at least twice. That can cause a heavy
A tipical POP user downl
On Feb 13, Robert Millan <[EMAIL PROTECTED]> wrote:
>What do you think on having paclages
>include a license tag?
Please provide a rationale for your proposal.
--
ciao,
Marco
On Jul 20, Joey Hess <[EMAIL PROTECTED]> wrote:
>So would anyone murder me if the code in debhelper to make postinst
>scripts manage /usr/doc links just went missing? This would of course
Please do.
(What about /usr/info <-> /usr/share/info ?)
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EM
On Jul 28, Branden Robinson <[EMAIL PROTECTED]> wrote:
>I am seeking seconds for this proposal.
Seconded.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Jan 04, Colin Walters <[EMAIL PROTECTED]> wrote:
>In summary, UTF-8 is the *only* sane character set to use for
>filenames.
True, but does not work in reality for too many people, so this cannot
be made mandatory.
> Major upstream software for Debian like GNOME is moving
>towards requiring
On Jan 04, Robert Bihlmeyer <[EMAIL PROTECTED]> wrote:
>Considering old standards broken because a newer one exists is just
>ridiculous.
Agreed.
>> I've noticed that UTF-8 sometimes makes zsh unhappy, [...]
>
>That's quite an understatement. The commandline editor can't deal with
>multibyte
On Jan 04, Colin Walters <[EMAIL PROTECTED]> wrote:
>> We may want a BOM, at the start, though.
>
>We don't need one for UTF-8. That's another one of the great things
>about it.
What do you know about international environments? Maybe you do not need
a BOM because your native language needs j
On Jan 05, Julian Gilbey <[EMAIL PROTECTED]> wrote:
>Maybe ask on the FHS list for comments, too?
This is outside FHS-domain. But I think that a so big change from
standard UNIX practice would be so stupid that if accepted I would
probably leave debian.
Recent programs do not have user-editable c
On Jan 06, Jochen Voss <[EMAIL PROTECTED]> wrote:
>Because a lot of programs is affected, it would gain us much, if we
>could move this as deep as into libc or even into the kernel. I
>remember there are some questions about character sets in the kernel
>configuration. Are there file-systems
I think that policy needs two small corrections to reflect current
practices wrt shared libraries and PIC code:
- what is PIC library needs to be correctly defined: compiling with
-fPIC is not enough to have PIC code, the object MUST NOT have a
TEXTREL section either [any other symbols need to
On Feb 08, Bill Allombert <[EMAIL PROTECTED]> wrote:
>> - libraries can contain short sections of non-PIC code on architectures
>> which allow this [i386 is OK, any other?] if this allows a
>> significant speed increase.
>
>This should be expended to cover the case of assembly files/ __asm
On Mar 09, Claudio Cattazzo <[EMAIL PROTECTED]> wrote:
>Do you think Italian translation of the Policy would be useful?
No, it's wasted time. Developers are supposed to know english anyway.
I think your time would be spent better at translating something useful
to our users.
--
ciao,
Marco
On Mar 23, Martin Godisch <[EMAIL PROTECTED]> wrote:
>Hence, I'm proposing a new virtual package name "internet-server" (or
>something like that).
inetd-superserver, already planned by the *-inetd cospiracy effort.
For the transition, I will make the next netbase package provide
inetd-superserv
On Mar 23, Martin Godisch <[EMAIL PROTECTED]> wrote:
>One more question, please: What package do you suggest as a non-virtual
>alternative? Thanks!
openbsd-inetd, because it's supposed to take the place of netkit-inetd
(it's basically a traditional BSD-style inetd with a few extra
features).
--
On Mar 23, Martin Godisch <[EMAIL PROTECTED]> wrote:
>Will inetd-superserver provide both, the super-server and update-inetd?
>Or will inetd-superserver provide the super-server only, and I have to
>check for existence of an update-inetd program? What do I have to depend
>on when my package ju
1 - 100 of 147 matches
Mail list logo
