On Sep 17, Bill Allombert wrote:
> Does not that would break users expectation that the system image contains
> /var
> before the first boot ?
I am not aware of such expectations.
> A lot of things in /var are caches that are mostly instance-independent and
> can
> be prefilled, but for that,
On Sep 17, Russ Allbery wrote:
> (I am a little confused by this wording, but I think what you're saying is
> that /usr is encrypted and read-only, and /var is recreated on each boot.
> That at least is my understanding of the pattern that you're trying to
> enable.)
The general idea is to be abl
On Sep 10, Enrico Zini wrote:
> I like this. I'd say that even if a license is shorter than 25 lines I'd
> appreciate to be able to link to it instead of copypasting it.
Me too.
> I like to be able to fill the license field with a value, after checking
> that the upstream license didn't diverge
On Jun 13, Bill Allombert wrote:
> Conversely, sometimes I need to use chroots to test init scripts.
> start-stop-daemon should not refuse to run in a chroot if policy-rc.d allows
> it.
I suggest that you try systemd-nspawn for this purpose.
--
ciao,
Marco
signature.asc
Description: PGP signa
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
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 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 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 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 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 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 Nov 14, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> So, what features do we settle on? we can either standardize
> on, well, a standard: POSIX/SUSv3, -- but there are things we use
> that come from XSI. I guess we could standardize on SUSv3 +XSI
> shells. Would still make local il
On Nov 07, Andreas Barth <[EMAIL PROTECTED]> wrote:
> I agree -a/-o should be replaced, but I don't think we really consider
No, they should NOT be replaced. There is no sensible reason to not use
them.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Nov 06, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Russ's patch is no good, at least, it does not address the problems I
> have raised in the past.
It's still better than what we have now, and solving parts of the
problems is still better than waiting for the ultimate policy change
which
On Nov 06, Mike Hommey <[EMAIL PROTECTED]> wrote:
> > + the -a and -o test operators
> > + must be supported
> Why is that needed ?
Because every modern shell which is not designed to be broken supports
them, and since they are in widespread use everywhere there is no reason
to no su
On Nov 06, Russ Allbery <[EMAIL PROTECTED]> wrote:
> Yes, a lot of people did fix it, but I'm afraid there are still a lot
> left. We can remove the requirement, but my understanding is that dash
> supports it, which means that it's probably not creating bugs in practice
> (posh isn't really desi
On Oct 26, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> FWIW, I strongly disagree with these changes. The solution is to bring
> the release policy in line with the real policy, not the opposite.
Yes, and let's forget about this "reality" bullshit...
--
ciao,
Marco
signature.asc
Description:
On Jan 06, Nathanael Nerode <[EMAIL PROTECTED]> wrote:
> Good point. Let's amend policy to require that a _pic.a library be provided
> for any static-only library; it seems to be an unreasonable omission. I
> wouldn't consider a library package which can't be used by any shared library
> to be
On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
> > To prepare for the eventual removal of makedev, I propose that packages
> Er, why is makedev being removed? Please clue me in.
"Eventual" is the key word here.
Because /eventually/ it will not be needed anymore (at least by most
users, which th
To prepare for the eventual removal of makedev, I propose that packages
currently depending on it will add an alternative dependency to udev.
Also, policy should be amended accordingly.
The affected packages are:
alevt
camstream
cdrecord
dvb-utils
fbset
gnupg
gnupg2
irda-utils
isdnutils-base
joys
> > > What I want is for any change in the default handling of UID and GID
> > > ranges in NIS to be made in other parts of Debian too.
As long as you do not expect that NIS-served system users and groups
will work too... This is a recipe for a disaster on udev systems,
because they will not be av
On Nov 28, Bill Allombert <[EMAIL PROTECTED]> wrote:
> Opinions ?
Looks good.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sep 23, Bill Allombert <[EMAIL PROTECTED]> wrote:
> > - permit building of static libraries with -fPIC (I don't think this
> >has any reason to be forbidden, does it?)
> They are certainly no good reason to _allow_ it. This breaks common
Actually I am almost sure that there are some situat
On Sep 18, Loïc Minier <[EMAIL PROTECTED]> wrote:
> Would someone please sched some light on the origins of this
> requirement? If this requirement is only to save memory in most cases,
> would it be reasonable to permit building with -fPIC by changing this
> "must" in a "should"?
Not quite.
On Aug 18, "Carlos Z.F. Liu" <[EMAIL PROTECTED]> wrote:
> My unofficial package, xfonts-wqy, is such a font covered complete CJK
> Unified Ideographics. Many people use this font in Mozilla Firefox to
> display CJK web page. They told me that this gzipped pcf font cause a
> 2 or 3 second high CPU
On Jun 12, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> to say the target should be
> "patched", rather than "source". For reference, the proposal as it now
> reads follows; as always, I'm looking for seconds.
I object. If the standard "patched" target exists then README.source
On May 13, Christian Schoenebeck <[EMAIL PROTECTED]> wrote:
> packages in future. On some packages it's really not that easy to trace back
> the original upstream source, because not every maintainer is adding that to
> the copyright or README.Debian file.
Then open bugs on these packages, do no
On Apr 23, Russell Coker <[EMAIL PROTECTED]> wrote:
> Every package has certain expectations about device node names. Since devfs
> is now considered as a bad idea the naming scheme should be as well.
No, it should not.
Almost every package supports it and there is no reason to remove the
suppor
On Mar 29, Roger Leigh <[EMAIL PROTECTED]> wrote:
> - - the traditional device names should be used by default
This is basically something which only concerns the maintainers of udev
and makedev, so I don't think it's useful to define it in policy
considering that there is an agreement that to do
On Mar 26, Roger Leigh <[EMAIL PROTECTED]> wrote:
> Is there a project-wide policy for support for devfs (and devfs-style,
> e.g. udev devfs.rules) device naming?
No, but nearly all packages support both conventions.
> I'm asking because of obstruction (from upstream) regarding the
> application
On Mar 11, Martin Pitt <[EMAIL PROTECTED]> wrote:
> I wholeheartedly agree and second this proposal. Also, /home should be
> root:root 0755 instead of root:staff 2775; it is only confusing and
> actually does not do anything useful.
Agreed.
--
ciao,
Marco
signature.asc
Description: Digital sig
On Aug 07, Bill Allombert <[EMAIL PROTECTED]> wrote:
>I would like to remember that this is not a policy proposal but a
>request from the base-files maintainer to discuss it there the
>proposal to add /run to base-files.
>
>This proposal get one second so far. I am sure it will get more secon
On Jul 28, Thomas Hood <[EMAIL PROTECTED]> wrote:
>or are being moved to /var/run/ . The problem with using /var/
>is that some people mount /var/ over the network. Yet in the
>end we really want to remove these files from /etc/. If /run/
>is not made available then these files will need t
On Jul 21, Martin Godisch <[EMAIL PROTECTED]> wrote:
>I'm still waiting for the inetd packages providing inetd-superserver,
>which they should do some day as Marco said, and for policy legalizing
I'm still waiting for somebody interested in rewriting update-inetd, and
I'm not holding my breath.
I second this, it is a major problem for prelink too.
--
ciao, |
Marco | [762 aruWjrVgtrEiY]
pgpbMMb0uIB7z.pgp
Description: PGP signature
On Apr 29, Thomas Hood <[EMAIL PROTECTED]> wrote:
>> it makes all systems more complex
>Complexity is increased by adding /run/ ... which in turn
>allows us to decrease the complexity of /etc/.
By what metric? You are adding a bunch of symlinks and weird things like
the proposed resolv.conf han
On Apr 29, Jamie Wilkinson <[EMAIL PROTECTED]> wrote:
>Do you think having programs write to /etc is a bad thing?
Yes.
>Where would you put /etc/mtab, to keep /etc sacrosanct?
I would teach mount to follow the /etc/mtab. Actually, I remember that
somebody already did this as he wrote about it o
On Apr 29, Steve Langasek <[EMAIL PROTECTED]> wrote:
>> I fully agree. I remember providing an alternative solution for all or
>> most of the problems which /run should solve, so I'm firmly opposed to
>> create this new, unneeded directory, which is nothing more than a
>> gratuitous change fro
On Apr 28, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> I think it is premature to tatify into policy an action that
> has not been fully decided upon, and has not yet had all the kinks
> ironed out yet.
>
> While I understand the use cases presented for /run; I am not
> yet conv
On Apr 28, Santiago Vila <[EMAIL PROTECTED]> wrote:
>If we are going to extend the FHS we should modify our own policy at least.
Do we have a consensus on /run? I don't think so.
--
ciao, |
Marco | [665 agG/r/pCLQ3L.]
On Mar 23, Marco d'Itri <[EMAIL PROTECTED]> wrote:
>inetd-superserver, already planned by the *-inetd cospiracy effort.
>
>For the transition, I will make the next netbase package provide
>inetd-superserver until /usr/sbin/update-inetd will be moved
>somewhere els
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
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:
>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 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 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
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 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
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 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 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:
>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 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 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 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 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 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 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 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 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 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 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 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 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, 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, 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, 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, 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, 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 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 Feb 03, [EMAIL PROTECTED] wrote:
>What workable alternative would there be to using
>/usr[/local]//(bin|lib|include)?
/usr/lib//...
--
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 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 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 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 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 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 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 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 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 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 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 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 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 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 Apr 24, Santiago Vila <[EMAIL PROTECTED]> wrote:
>I'm looking for seconds for this proposal.
Seconded.
--
ciao,
Marco
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 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 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 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 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 Oct 02, Raul Miller <[EMAIL PROTECTED]> wrote:
> `Non-free' contains packages which are not compliant with the DFSG.
Seconded.
--
ciao,
Marco
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 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, 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 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 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 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, 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 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
1 - 100 of 147 matches
Mail list logo
