Re: UPG and the default umask

2010-05-13 Thread Petter Reinholdtsen
[Santiago Vila] > Will be done in base-files 5.4. Great. This has been the default in Debian Edu for several years, and changing the default to work properly with UPG will remove the need for Debian Edu to edit the default umask. Btw, why is the umask set at all in base-files? It would be bett

Work-needing packages report for May 14, 2010

2010-05-13 Thread wnpp
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 607 (new: 10) Total number of packages offered up for adoption: 120 (new: 0) Total number of packages reques

Re: UPG and the default umask

2010-05-13 Thread Klaus Ethgen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Do den 13. Mai 2010 um 18:45 schrieb Aaron Toponce: > On 5/13/2010 3:48 AM, Santiago Vila wrote: > > Will be done in base-files 5.4. > > I just saw the change committed. Thank you very much! This is good news. > > http://bugs.debian.org/cgi-bin/

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

2010-05-13 Thread Stefano Canepa
On 7 May 2010 10:33, Paul Wise wrote: > On Fri, May 7, 2010 at 4:22 PM, Goswin von Brederlow > wrote: >> Stefano Zacchiroli writes: >>> The init.d world has changed quite a bit in recent years and might >>> change even more in the next, it is possible that for Squeeze+1 we'll >>> want to be els

Re: bindv6only again

2010-05-13 Thread Tollef Fog Heen
]] Salvo Tomaselli | > And handling bindv6only is absolutely trivial. | | Right, but there are many others sysctl options, why should the apps | deal with this particular one and not with the others? They should. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends a

Re: bindv6only again

2010-05-13 Thread brian m. carlson
On Thu, May 13, 2010 at 05:54:04PM +0200, Tollef Fog Heen wrote: > ]] Juliusz Chroboczek > Because it does not handle non-default values. This is just like an > application that didn't handle IFS or PATH being different from its > default value would be buggy. If it absolutely needs a given valu

Re: bindv6only again

2010-05-13 Thread Salvo Tomaselli
On Thursday 13 May 2010 18:39:46 Tollef Fog Heen wrote: > Why is this relevant? If you remove a POSIX-defined utility from $PATH, > your system is no longer POSIX-compliant, not to mention a fully-working > Debian system. Strange that now being POSIX-compliant is important but it isn't when we tal

Re: UPG and the default umask

2010-05-13 Thread Aaron Toponce
On 5/13/2010 3:48 AM, Santiago Vila wrote: > Will be done in base-files 5.4. I just saw the change committed. Thank you very much! This is good news. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434#25 -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O

Re: bindv6only again

2010-05-13 Thread Tollef Fog Heen
]] Salvo Tomaselli | On Thursday 13 May 2010 17:54:04 Tollef Fog Heen wrote: | > Because it does not handle non-default values. This is just like an | > application that didn't handle IFS or PATH being different from its | > default value would be buggy. | | Do you know what happens if you move

Re: bindv6only again

2010-05-13 Thread Juliusz Chroboczek
> | bindv6only=0 is assumed by both POSIX and RFC 3493. > > As the default value, yes. Not as the only possible value. Please stop repeating this legend, it is simply not true. POSIX 2008, Volume 2, Section 2.10.20 is extremely clear that AF_INET6 sockets can be used for IPv4: Applications

Re: bindv6only again

2010-05-13 Thread Michael Poole
Tollef Fog Heen writes: > ]] Juliusz Chroboczek > > | >> What if it is just installed from the tarball? > | > | > Then that person is still using buggy, non-free software. > | > | Proprietary, granted, but why buggy? > > Because it does not handle non-default values. This is just like an > ap

Re: bindv6only again

2010-05-13 Thread Salvo Tomaselli
On Thursday 13 May 2010 17:54:04 Tollef Fog Heen wrote: > Because it does not handle non-default values. This is just like an > application that didn't handle IFS or PATH being different from its > default value would be buggy. Do you know what happens if you move /bin/mkdir to /usr/bin/mkdir? SSH

Re: bindv6only again

2010-05-13 Thread Tollef Fog Heen
]] Juliusz Chroboczek | >> What if it is just installed from the tarball? | | > Then that person is still using buggy, non-free software. | | Proprietary, granted, but why buggy? Because it does not handle non-default values. This is just like an application that didn't handle IFS or PATH be

Re: bindv6only again

2010-05-13 Thread Salvo Tomaselli
On Thursday 13 May 2010 15:33:42 Juliusz Chroboczek wrote: > Proprietary, granted, but why buggy? bindv6only=0 is assumed by both > POSIX and RFC 3493. I agree with you, but in this mailing list apparently the word "standard" might mean many many things. You might say "standard" meaning "i will

Re: bindv6only again

2010-05-13 Thread Juliusz Chroboczek
>> What if it is just installed from the tarball? > Then that person is still using buggy, non-free software. Proprietary, granted, but why buggy? bindv6only=0 is assumed by both POSIX and RFC 3493. --jch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "un

Re: UPG and the default umask

2010-05-13 Thread Russ Allbery
Aaron Toponce writes: > On 5/13/2010 3:34 AM, Philipp Kern wrote: >> Doesn't that lead to "great fun" if you activate NIS or similar means >> to sync unix users and groups on such systems, if they aren't set up to >> use UPG too? So that would need a big fat warning in the release notes >> and s

Re: UPG and the default umask

2010-05-13 Thread Russ Allbery
Philipp Kern writes: > On 2010-05-13, Lucas Nussbaum wrote: >> On 13/05/10 at 09:34 +, Philipp Kern wrote: >>> Doesn't that lead to "great fun" if you activate NIS or similar means >>> to sync unix users and groups on such systems, if they aren't set up >>> to use UPG too? >> How would that

Re: UPG and the default umask

2010-05-13 Thread Aaron Toponce
On 5/13/2010 3:34 AM, Philipp Kern wrote: > On 2010-05-13, Charles Plessy wrote: >> If no stronger objections against a change from 022 to 002 is raised, would >> you >> agree changing base-files so that /etc/profile uses 002 on new systems? > > Doesn't that lead to "great fun" if you activate N

Re: UPG and the default umask

2010-05-13 Thread Philipp Kern
On 2010-05-13, Lucas Nussbaum wrote: > On 13/05/10 at 09:34 +, Philipp Kern wrote: >> On 2010-05-13, Charles Plessy wrote: >> > If no stronger objections against a change from 022 to 002 is raised, >> > would you >> > agree changing base-files so that /etc/profile uses 002 on new systems? >>

Re: UPG and the default umask

2010-05-13 Thread Santiago Vila
On Thu, 13 May 2010, Charles Plessy wrote: > found 248140 5.3 > thanks > > Dear Santiago, > > You probably have seen the discussion about user private groups on > debian-devel this week: > http://lists.debian.org/msgid-search/4be830c8.5050...@gmail.com The > core argument is that since user priv

Re: UPG and the default umask

2010-05-13 Thread Lucas Nussbaum
On 13/05/10 at 09:34 +, Philipp Kern wrote: > On 2010-05-13, Charles Plessy wrote: > > If no stronger objections against a change from 022 to 002 is raised, would > > you > > agree changing base-files so that /etc/profile uses 002 on new systems? > > Doesn't that lead to "great fun" if you a

Re: UPG and the default umask

2010-05-13 Thread Andrei Popescu
On Thu,13.May.10, 09:34:15, Philipp Kern wrote: > On 2010-05-13, Charles Plessy wrote: > > If no stronger objections against a change from 022 to 002 is raised, would > > you > > agree changing base-files so that /etc/profile uses 002 on new systems? > > Doesn't that lead to "great fun" if you a

Re: UPG and the default umask

2010-05-13 Thread Philipp Kern
On 2010-05-13, Charles Plessy wrote: > If no stronger objections against a change from 022 to 002 is raised, would > you > agree changing base-files so that /etc/profile uses 002 on new systems? Doesn't that lead to "great fun" if you activate NIS or similar means to sync unix users and groups o