urther discussion can best be carried on in the upstream Bugzilla ticket.
Arising from the discussion in that ticket an effort has begun better
to describe the desired behavior of getaddrinfo(). Initial results can
be seen here: http://sourceware.org/glibc/wiki/NameResolver
--
Thomas Hood
--
To
e
doing so.
So perhaps the more pertinent question is, what safeguards does Debian have
against infiltration?
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: htt
Op 8 aug. 2013 17:49 schreef "Tom H" het volgende:
> The output below is from Debian Sid with libnss-myhostname installed [...]
> [root@debdeb:/etc]# cat hostname
> debdeb
> [root@debdeb:/etc]# cat hosts
> 127.0.0.1 localhost
> [root@debdeb:/etc]# getent hosts 127.0.1.1
> 192.168.1.250 debdeb
T
Op 7 aug. 2013 10:33 schreef "Wouter Verhelst" het
volgende:
> Historically, "localhost" has always been "127.0.0.1". It feels wrong to
> change that, simply because "localhost" starts showing up in places it
> was never meant to show up in.
To clarify, no one is proposing that 'localhost' be ass
.g.,
'localhost' appearing in log files) then I'd like to see the
malfunctioning packages fixed in advance of the transition from
127.0.1.1 to 127.0.0.1. And before making this potentially disruptive
change, I'd like to see evidence that the current practice actually
causes problem
nameserver replies that the hostname does not exist: EAI_FAIL
> - The nameserver doesn't reply, or replies with a temporary failure: EAI_AGAIN
> - You used AI_NUMERICHOST or AI_NUMERICSERV and didn't give a number:
> EAI_NONAME
Further discussion can best be carried on in the upstre
On Mon, Jul 8, 2013 at 8:23 AM, Helmut Grohne wrote:
> Here are my results:
>
>
> Making resolv.conf empty
> Results of looking up www.google.com: status = -11, errno = 111
> Results of looking up a bogus name: status = -11, errno = 111
> Writing nameserver option to reso
It looked to me as if #582916 and roughly duplicate #671789 could have been
fixed in libc6 2.17-7 which it includes two commits
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cfde9b463d63092ff0908d4c2748ace648e2ead8
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3d04f5db20c8f0d1ba3
On Sun, Jul 7, 2013 at 2:41 PM, Kurt Roeckx wrote:
> A related bug is #582916
>
Thanks. Besides that, #671789 and #713799 are also probably related.
The latter was closed by the 2.17-7 release which is the most recent in
unstable;
I should be testing with that version rather than with the whee
Continuing on from the "boot ordering and resolvconf" thread;
cc:ed to Helmut in case this gets filtered again; bcc:ed to
683...@bugs.debian.org since this is relevant for how that
issue is addressed...
Executive summary: The getaddrinfo() returns different values
depending on the OS and on nsswit
have different findings and I think we should
get to the bottom of this difference since it is relevant for
how we think about ntpd bug report #683061.
Helmut Grohne wrote:
> On Sun, Jun 30, 2013 at 10:40:03PM +0200, Thomas Hood wrote:
> > A problem is that getaddrinfo() doesn't distin
le were dynamically updating /etc/hosts in 1999 but I hope that
no one has to do that any longer. :)
--
Thomas Hood
etworkManager and dnsmasq-base by
default: NetworkManager runs an instance of dnsmasq as a
forwarding nameserver.
But there is no need to introduce new restrictions and policy
unless, perhaps, it does turn out that large numbers of libc
resolver clients need to be modified, which so far as I know is
not the case.
--
Thomas Hood
blob;f=man/resolvconf.8
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d43cc2.4030...@gmail.com
Tollef Fog Heen wrote:
> I think changing /etc/resolv.conf automatically is broken at all.
What's the malfunction?
> We should have a generated /run/resolv.conf that's overridden by the
> settings in /etc/resolv.conf (if it exists). This allows you to have a
> consistent set of domains searched
Helmut Grohne wrote:
> All that I am aiming for is to declare one of the following practises
> as broken:
>
> * Treating an empty /etc/resolv.conf as a permanent error or failing
>to discover changes in /etc/resolv.conf later on.
> * Changing /etc/resolv.conf during startup of a local dns ca
> In addition resolvconf does not properly support mode (A), due to the
> "local forwarding nameserver is running" requirement. It can leave
> /etc/resolv.conf empty until the name server is actually started.
Well, you are right that resolvconf was designed to support mode B,
and only supports mo
nameservers and reconfigures them based on input from DHCP clients,
ifup and NetworkManager. Support for bind9 and unbound could easily be added
(see
bug report #483098).
--
Thomas Hood
resolvconf maintainers
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subjec
to.
Can someone please give me the golden clue?
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5110dcec.4010...@gmail.com
files, and so on.
Or do you see some other approach as more compatible and consistent?
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caj
On Sun, Feb 26, 2012 at 17:24, Goswin von Brederlow wrote:
> Maybe the solution isn't event base or dependency based. Maybe the
> right solution is event based and dependency based.
In one sense this is obviously right. Any solution has to respond to
various kinds of events and has to be able to
On Fri, Feb 24, 2012 at 20:17, Steve Langasek wrote:
> On Thu, Feb 23, 2012 at 11:58:08AM +0100, Goswin von Brederlow wrote:
>
>> Upstart also does not support Should-Start which makes it impossible to
>> provide corect init scripts for a number of services. For example autofs
>> will not work if
On Thu, Feb 23, 2012 at 11:58, Goswin von Brederlow wrote:
> Upstart also does not support Should-Start which makes it impossible
> to provide correct init scripts for a number of services. For example
> autofs will not work if it uses nis because nis is not started before
> autofs. Due to the lac
s systemd which in turn starts service daemons. Does this make
any sense, and if so, what would be the advantages and disadvantages
of this?
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...
bash
script will not necessarily run faster if it has to be rewritten
to run on sh. This is especially true if ${//}s are replaced by
pipes to sed.
--
Thomas Hood
Resolvconf 1.49, which makes use of /run instead of /lib/init/rw for
storing run-time data, has just been uploaded to experimental. Those
testing the experimental initscripts package (2.88dsf-13.4) are
invited to test this experimental resolvconf package along with it.
--
Thomas Hood
resolvconf
> This is not to say we couldn't remove it on startup though.
You should not remove /lib/init/rw on the next reboot. If the
upgrade stops due to an error then the system might be rebooted
before the upgrade is continued. /lib/init/rw needs to remain
present until all packages using it have bee
char *saved_names[MAX_NESTED_LINKS + 1];
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dab404a.9080...@gmail.com
lib/init/rw at
least until the wheezy version of its postinst runs.
But this occurs after initscripts's postinst runs. And that is the last
chance initscripts has to eliminate /lib/init/rw in wheezy. So I
conclude that initscripts should only eliminate /lib/init/rw in
wheezy+1.
--
Thomas
s and other pitfalls should I watch out for?
3. What is an appropriate name for the trigger?
4. Does anything have to be approved or discussed on a particular
mailing list or can I go ahead and introduce the trigger and then
ask the maintainers of caching nameservers to make use of it?
--
T
I just realized that I misunderstood Roger Leigh's posting and so
my previous message was mostly superfluous. My apologies.
1. His statement "but you have to mount many more to be able to
break your system" was correct (and can be made more explicit by
adding "... by filling them all").
2. His p
First of all, thanks to Roger Leigh for leading this effort.
Roger Leigh wrote:
> Proposal:
> Switch the default for all tmpfs mounts from 50% to 20%; it's
> still very large, but you have to mount many more to be able to
> break your system.
He should have said "... but you have to mount *and f
maintained[1]. If openresolv is truly a drop-in replacement for
resolvconf then migration from resolvconf to openresolv would be one way of
solving this undermaintenance problem.
What further pros and cons do people see out there?
[0]http://roy.marples.name/projects/openresolv/wiki/OpenResolvRea
need to warn the administrator that he should (presumably)
re-implement his changes in the new file? If so, what is the best way
to warn him? Should debconf notes be used?
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe"
.
Please see http://lists.debian.org/debian-glibc/2005/06/msg00173.html
for one of the earlier discussions about this issue.
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debi
Peter Samuelson wrote:
> Looks like you just need to wait 4 more days. Lenny isn't frozen yet,
> not for optional packages.
OK, thanks. (I was under the impression that some sort of intervention
was required in order to undo a removal.)
--
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
quest from the DDs
on the resolvconf maintenance team. I hope that some DD who reads d-d can
take care of ushering resolvconf back into testing.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
: critical.
Therefore I am seeking an interim maintainer of thinkpad and tpctl, preferably
someone who would like to carry on as co-maintainer with Martin.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
2004-07-12
> FD checks completeness of report Approved on 2006-02-21 by Marc
> Brockschmidt (he)
> DAM Approval Approved on 2006-03-20 by Joerg Jaspert
> (joerg)
--
Thomas Hood
of Debian as a problem. However, you always have
the
option of participating in some other project, such as Ubuntu, which does
recognize
contributions other than package maintenance.)
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rded as elementary politeness in some spheres, but
Debian's social norms are not the same as those of everyday life.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
y more projects
like Foo in the future. Not within Debian, anyway.
Purely hypothetical case, but it could happen.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
l have to manually remove conffiles in their maintainer scripts
> until at least etch+1 by my reckoning. Is this correct?
Again, postrms should not remove files that are currently conffiles.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
x27;t forget to set ownership and permissions.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
My guess is that there may be other packages out there that need to be
reviewed with respect to the granting or non-granting of the GPL version
option.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
imal.
Thus if upstream's concern is that users not have a stripped down python,
then Debian provides a stripped down "python-minimal" instead.
--
Thomas Hood
icated back directly to the Debian
> developers responsible for that package in Debian and record the patch
> URL in the debian bug system.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
http://marc.theaimsgroup.com/?l=debian-devel&m=113768382100129&w=2
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
me
# Rename it to the temporary name.
# Then try several times to rename it to new name
Now "trying several times", etc., may work, but it's a kludge. There are
sound ways of resolving contention for a shared resource.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMA
> In any case I am hoping to see python-minimal included in Debian.
I now see that it is already in sid. :)
$ apt-cache madison python-minimal
python-minimal |2.3.5-5 | http://ftp.nl.debian.org sid/main Packages
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
looks at its properties, and...
* Kernel creates eth1
* ...tries to rename it to 'eth1', but that name is taken
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
re that python-minimal be
Essential: yes in Debian.
In any case I am hoping to see python-minimal included in Debian.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
base in regarding this to be a candidate for release to unstable.
Again, TIA for testing it.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
your package. I have seen changes in some packages
that looked gratuitious, but then I have been comforted by the thought
that the perpetrators of gratuitous changes are the ones who have to pay
the price for it, because they have to carry such changes forward.
--
Thomas Hood
--
To UNSUBSCR
uld everyone be happy then? I doubt it.
[0] Here: http://ubuntu.com/ubuntu/relationship?highlight=%28debian%29
there's a claim that "they send their bugfixes to the Debian developers
responsible for that package in debian and record the patch URL in the
debian bug system."
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
be suitable
for Debian.
I agree that it would be nice if Ubuntu developers tried to get their
changes into sid. It is certainly not their responsibility to do so,
but in my experience Ubuntu developers have been very cooperative when
they have been approached. So I don't see a big problem.
--
Th
ded.
:)
As pointed out by Peter Samuelson, this dir should be removed by the postrm on
purge. I would advise not including /var/run/foo in the package since it is
superfluous and its presence could hide a bug in your directory-creation code.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
Would it be useful if the initscript that clears /var/run also created
a directory hierarchy under /var/run?
(There are different ways of implementing thus, but we can talk about
details if this feature is deemed worthwhile.)
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
e simultaneously.
I'd call it the "obscure the point game", because the pairs of statements
were meant to illustrate a difference in attitude, not a set of absolute
contradictions. But I think you know that. Because you are really playing
another game, which I'll dub &qu
e current NM process would
regard those points as weaknesses in Debian's defenses, which should be closed
rather than advertized.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mprehensive listing of all the Debian _maintainers_
accompanied
with a list of packages they maintain", instead of "...developers..." (which
would
also be more accurate since non-DD maintainers are already listed). And so on.
Reword with the principle in mind that there are many contributors to Debian
who are
not Debian Developers®.
--
Thomas Hood
here
should be
room for different kinds of projects, including exclusive hobby clubs.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
recommendations about how documentation relationships should be reflected
in package dependencies?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> A new version of sysvinit is being prepared for release to experimental.
OK, sysvinit 2.86.ds1-8 is now in incoming. TIA for testing it. ;)
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
m trying
to modify an existing feature (to make it compatible with a read-only
root filesystem) without altering its behavior any more than necessary.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Henrique de Moraes Holschuh wrote:
> How well that works with /var in a separate partition?
It should work fine because S55bootmisc.sh runs after S45mountnfs.sh.
--
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
plete: DELAYLOGIN=yes
No-login mode never: rm -f /var/lib/initscripts/nologin ; DELAYLOGIN=no
No-login mode always: touch /var/lib/initscripts/nologin ; DELAYLOGIN=no
Anyone see any problems with this scheme? Any better ideas?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [
never: DELAYLOGIN=no
No-login mode always: rm -f /etc/nologin ; :> /etc/nologin
Anyone see any problems with this scheme? Any better ideas?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
r things
can be done to help individual maintainers fix more bugs and fix them
better?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
re feeling in a conspiracy-theorist mood then
> I'd suggest that those who are promoting team maintainance are trying
> to gain power while evading responsibility.
Well, you do suggest it here. And what you suggest makes no sense, so
let's not rule out the possibility that you are
vel.
That's less of a burden than that imposed by many another Debian rule.
Fortunately for your position, it probably won't take arguments to kill
this idea.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
stellar job that they need a babysitter is a bit... insulting.
This is not a fair characterization of what the introduction of
a two-maintainer rule would be doing. No one should be insulted
by general rule changes designed to make Debian work better.
--
Thomas Hood
--
To UNSUBSCRI
litary package ownership has made some
Debian packages into bastions of untended bugs.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> > Tmpfs memory can be swapped out, so is this even a hypothetical
> > problem?
>
> Maybe it isn't on Linux. I wasn't aware tmpfs could be swapped out.
>
> That still leaves the question of just which features we want to require
> from our non-Linux kernels for basic operation, I guess.
Yes,
Gabor Gombas wrote:
> ... I'd like to have a check for /run (or /lib/run or whatever)
> being empty at the end of the boot process
The new mountvirtfs prints such warnings for all the "virtual"
filesystems.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
nowing that their programs face special storage
problems is shifted onto the sysvinit maintainers and admins who
have to ensure that writable space is shoved under /var/run by
the time any of the H tries to write there.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Any other defenders of /lib/run? Of /run?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Anthony Towns wrote:
> Developers have been known not to be completely familiar with policy,
> but it's admins and upstream programmers that I'm particularly
> thinking of.
I don't see any problems arising from rampant /run use by _admins_.
They are always free to do what they want with their syst
'run' rather than 'lib'. Hence R should
be /run.
Briefly, if R is like /var/run except that it supports programs
needed to boot the system and run commands on the root filesystem,
then it should be another "run" directory, but at the top level.
Here's another possible argument:
Putting R in /lib spoils the otherwise read-only
character of that directory.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
So, has anyone tested the new packages?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ot occur until the filesystem underlying
/run is mounted read-write and programs must not use /run before the
cleaning has been completed; it would probably be easier to drop the
cleanliness-at-boot guarantee and let programs clean out their own
stale files.
--
Thomas Hood
--
To UNSUBSCRI
eryone agrees that /run is to be used only for those very
few purposes for which /var/run cannot be used. If there are worries
about abuse then I would suggest the addition of a sentence to Policy
forbidding such abuse.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
ore than "-policy support" would be an
> appropriate claim if Manoj had said it looked okay.
Agreed. Fortunately, I didn't claim that.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ble by hiding it in /lib
> alongside /lib/modules.
The problem is that some people find /lib/run uglier than /run. ;)
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
INIT_VERBOSE=yes kernel parameter. Is the boot more verbose?
Any glitches in any of the messages?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
does involve some work.
There is a new upstream release candidate out now (1.0.11rc1) and I would
like to take the opportunity to go through the process with the new
volunteer.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Cont
I seek co-maintainers for:
mwavem
thinkpad, tpctl
resolvconf
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The ALSA packaging team needs help. We really need someone with expertise
in programming for the ALSA library. If you are able to help us, please
contact us at [EMAIL PROTECTED]
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Troubl
tories.
"! -xtype d" in the absence of "-L" matches everything except directories
and symbolic links to directories. Thus IIUC the latter eliminates the need
for the former.
I am cc:ing this to debian-devel in order to solicit opinions.
Please reply to [EMAIL PROTECTED], not to t
lure_msg "Foo
failed." ; fi
Is this what I should do, or is there another solution I am overlooking; or
do we need more functions; or does the whole system need to be reworked?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
directories
and symbolic links to directories. Thus IIUC the latter eliminates the need
for the former.
I am cc:ing this to debian-devel in order to solicit opinions.
Please reply to [EMAIL PROTECTED], not to the list.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
lication breaks if 'localhost.localdomain' is included on the
127.0.0.1 line in /etc/hosts.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
revert.
However, I think that applications should work properly whether
/etc/hosts contains
127.0.0.1 localhost.localdomain localhost
or
127.0.0.1 localhost
especially considering the fact that the sarge installer writes
/etc/hosts with the former.
--
Thomas Hood
--
To UNSUBSCRIBE, em
> That did it, unloaded the snd-intel8x0 and 8x0m and then reloaded i810_audio
> and things worked again.
i810_audio is an OSS module, not an ALSA module. You fixed sound by switching
from ALSA to OSS.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
For backward compatibility that behavior should
probably be preserved.
When a final decision has been made about how hot plug blacklisting
will be implemented in the future, please file a bug report against
alsa-base explaining what changes need to be made, if any.
--
Thomas Hood
--
To UNSUBSCR
following files which might
appropriately be kept in a subdirectory of /run/.
/etc/nologin
/etc/mtab
/etc/network/run/ifstate
/etc/resolvconf/run/*
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Andreas Metzler wrote:
> Thomas Hood <[EMAIL PROTECTED]> wrote:
> [command -v]
> > It is not even useful as a which(1) replacement. Whereas "which"
> > prints the pathname of the first executable file on the PATH,
> > "command -v" prints the pat
Marco d'Itri wrote:
> Andreas Metzler wrote:
> > Thomas Hood wrote:
> > > Is there anything else which dash supports but posh does not?
> > command -v
>
> Which is the well known which(1) replacement, and basically mandatory
> in a sane Debian shell. I keep
ard for people to find updates.
> To change it know is just silly political correctness.
I think that the kernel packaging team members should be able to do
their work without being insulted.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubsc
;.) If you
agree then it would be helpful to mention this in #294962.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 254 matches
Mail list logo
