Package: module-init-tools
Version: 3.2-pre9-3
Severity: normal
I have in a file in /etc/modprobe.d/
install snd modprobe --ignore-install snd $CMDLINE_OPTS
install snd-intel8x0 modprobe --ignore-install snd-intel8x0 $CMDLINE_OPTS
If I run
modprobe snd-intel8x0
then snd-intel8x0 g
Bastian Blank wrote:
> On Tue, Jul 05, 2005 at 03:59:23PM +0200, Thomas Hood wrote:
> > If the user installs a 2.6 kernel then he or she should probably use ALSA.
> > To use ALSA, the user should have alsa-base installed. Therefore it would
> > be appropriate if 2.6 kernel image packages Recommend
> wasn't there a meta sound package?
I don't know. Why do you ask?
--
Thomas
Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Keeping WEP keys in a file separate from /etc/network/interfaces
is a good idea, in my opinion. It would be useful if the user
could specify:
iface foo addrfam method
wireless-key-id bar
with the result being that the key named 'bar' would be looked
up in a configuration file, /etc/wireless-
tags 299674 wontfix
thanks
We certainly won't be blacklisting the snd_usb_audio by default.
Daniel Chen wrote:
> Perhaps we should add a note to the README regarding
> blacklisting via hotplug.
I will add something to the README. However, note that it is quite
possible that there will be no fur
I believe that this was fixed in 0.0.20040329-18:
Changes:
hotplug (0.0.20040329-18) unstable; urgency=high
.
* workaound fix to load firmware problem for sarge release.
closes: Bug#297481, Bug#299154
/sbin/hotplug may have potential problem in hotplug event multiplexing,
but
Just to provide updated information about this issue ...
The experimental version of ifupdown allows one to do
/etc/init.d/ifupdown up
instead of
ifup
which ensures that the ifup does not happen too early.
The experimental version of ifupdown also includes a hook script in
/etc/ifplu
> However, I just thought
> that it might be even better to create an if-pre-up.d script that
> unconditionally runs ifrename for each ifup command.
Are you suggesting that
ifup foo
do this?:
ifrename -i foo# Renames foo to bar
ifup bar
> Even without using the hotplug infras
As I wrote in #294180,
> It should be fine to do ifrename just before S:S40networking.
Are there any plans to add an ifrename initscript (at S:S40ifrename)?
AIUI an ifrename initscript is still needed in order to rename interfaces
that aren't hot plugged.
--
Thomas
Hood
--
To UNSUBSCRIBE, e
> On Wed, 9 Mar 2005, Adam Heath wrote:
> >>This is a bug in run-parts. It should reverse the order.
> >>
> >>Or you are not understanding how it works.
> >
> >reassign 298783 sysv-rc
> >thanks
>
> I don't understand. What is the bug? The order sysv-rc uses to
> run the scripts is the standard o
> Thomas Hood <[EMAIL PROTECTED]> writes:
> Why can't start-stop-daemon check the pidfile after stopping the
> daemon and remove it if left around?
I see nothing wrong with that behavior except for the fact that it
is different from the current behavior. The current behavior is
reasonable, so I
> +rmdir -p --ignore-fail-on-non-empty /etc/apm/suspend.d /etc/apm/resume.d
The rmdir shouldn't be necessary if the package includes these
two directories. (I can't check the package right now because I
am not at a Debian machine.) dpkg will rmdir them if they are empty.
--
Thomas
--
T
Only the force-reload method is mandatory. The reload method is not.
(Policy 9.3.2.)
--
Thomas
Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
It is almost a contradiction for a bug report to be rated both
grave and unreproducible. Can this be downgraded?
--
Thomas
Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mount has its shortcomings, but I think it is stretching it to
describe the reported behavior as a "secutiry hole".
It isn't likely that this problem would be allowed either to delay
the release or to force the removal of mount from the release.
Also, assuming the shortcoming exists in all version
martin f krafft wrote:
> Can a hook in /etc/hotplug.d stop /sbin/hotplug from executing the
> rest of the scripts? In that case, ifrename could just call
> /sbin/hotplug again, or submit a uevent to the PF_NETLINK socket,
> causing hotplug to call all hook again.
Call this 'option #4'.
Too ugly,
severity 295514 wishlist
severity 294111 wishlist
severity 267007 wishlist
severity 295520 wishlist
tags 245435 - wontfix
tags 267007 - wontfix
merge 294111 295514 245435
merge 267007 295520
thanks
> Probably not an option, if all goes well /sbin/hotplug will be replaced
> with a daemon listenin
Package: alsa-base
Version: 1.0.8-5
Severity: normal
We need to unmute the "Audigy A" channel.
See https://bugzilla.ubuntu.com/show_bug.cgi?id=6222 for
details.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Fuck no. You are the one who resorted to bureaucratic
> shennaigans to convince dpkg maintainers to change the way it works,
> rather than trying and convince them that your way is right.
No shenanigans here. The dpkg maintainer says that he wants guidance
from policy. He wrote:
Ac
I wrote:
> One case where /usr/bin/which won't work is in initscripts that
> run prior to /etc/rcS.d/S45mountnfs.sh.
This problem is solved by debianutils version 2.12.0, uploaded yesterday,
which moves which from /usr/bin/ to /bin/. See #295058. :)
--
Thomas
Hood
--
To UNSUBSCRIBE, email
> The following packages have unmet dependencies:
> alsa-base: Depends: alsa-utils (> 1.0.7-2) but 1.0.7-2 is to be
> installed
Thanks for the report.
alsa-utils 1.0.8-1 didn't make it into sid last night even though alsa-base
1.0.8-1 did.
The result is that alsa-base 1.0.8-1 is uninstalla
severity 289008 wishlist
thanks
I have discovered that this was a case of user error: I also had
an "install" declaration for the module in question.
If one has, e.g.:
alias allah god
options allah omnipotent=yes
install god modprobe --ignore-install god ; update-deities
and then do
> > For packages with maintainer scripts that do "invoke-rc.d restart" or
> > equivalent, the multiuser runlevel directories must contain either an
> > S or a K symlink. This will remain true even when #243159 is
> > implemented.
>
> Must this be so? As long as the no-S-and-K-links situation is o
> Therefore, I vote for changing the behavior of invoke-rc.d from 1) to
> 2), until something like "try-restart" is implemented.
Perhaps it would be better, as you suggest, if we saw this in the
absence of S and K symlinks:
invoke-rc.d stop -> stop
invoke-rc.d start -> (nothing)
than th
24 matches
Mail list logo
