On Feb 18, 2008 6:06 AM, Dave Jones [EMAIL PROTECTED] wrote:
On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote:
On 02/16/2008 06:53 AM, drago01 wrote:
Hi,
I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build
directly) on my laptop.
Hal detects two
On Mon, 2008-02-18 at 11:23 +0100, drago01 wrote:
Yeah, you need a new enough hal aparently, which I guess f8 didn't have.
F9 should be safe to be using just the sysfs stuff.
I have not tested rawhide on a laptop yet, but it seems that rawhide
still uses hal-0.5.10 (which is also the
On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote:
is there any reason why we can't just move %post to %posttrans?
%posttrans breaks the way we do bootloader config updating as it leaves
around no entries in the bootloader config after all the %preuns have
been processed. I looked at this a
On Mon, Feb 18, 2008 at 09:36:49AM -0500, Jeremy Katz wrote:
On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote:
is there any reason why we can't just move %post to %posttrans?
%posttrans breaks the way we do bootloader config updating as it leaves
around no entries in the bootloader
On Mon, Feb 18, 2008 at 09:49:44AM -0600, Matt Domsch wrote:
On Mon, Feb 18, 2008 at 09:36:49AM -0500, Jeremy Katz wrote:
On Sun, 2008-02-17 at 20:16 -0600, Matt Domsch wrote:
is there any reason why we can't just move %post to %posttrans?
%posttrans breaks the way we do bootloader
On Mon, Feb 18, 2008 at 11:25:40AM -0500, Kyle McMartin wrote:
On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote:
On 02/16/2008 06:53 AM, drago01 wrote:
Hi,
I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build
directly) on my laptop.
Hal detects two
On Sun, Feb 17, 2008 at 09:08:02PM -0500, Chuck Ebbert wrote:
On 02/16/2008 06:53 AM, drago01 wrote:
Hi,
I tested the kernel-2.6.24.2-3.fc8 (downloaded the x86_64 build
directly) on my laptop.
Hal detects two batteries because it looks in sysfs and in procfs for
the battery info. I
Matt Domsch ([EMAIL PROTECTED]) said:
https://bugzilla.redhat.com/show_bug.cgi?id=433121
DKMS would like to have the opportunity to run it's
auto-rebuilder/installer after a new kernel RPM has been installed,
without having to wait for a system restart to run it. Likewise, when
a kernel
On Mon, Feb 18, 2008 at 12:35:19PM -0500, Don Zickus wrote:
On Sat, Feb 16, 2008 at 09:53:26AM -0600, Matt Domsch wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=433121
DKMS would like to have the opportunity to run it's
auto-rebuilder/installer after a new kernel RPM has been
On Sat, Feb 16, 2008 at 09:53:26AM -0600, Matt Domsch wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=433121
DKMS would like to have the opportunity to run it's
auto-rebuilder/installer after a new kernel RPM has been installed,
without having to wait for a system restart to run it.
On Mon, Feb 18, 2008 at 01:13:35PM -0500, Don Zickus wrote:
On Mon, Feb 18, 2008 at 12:01:23PM -0600, Matt Domsch wrote:
On Mon, Feb 18, 2008 at 12:54:29PM -0500, Bill Nottingham wrote:
Matt Domsch ([EMAIL PROTECTED]) said:
Use triggers - this functionality already exists without
On Mon, Feb 18, 2008 at 12:45:05PM -0500, Bill Nottingham wrote:
Matt Domsch ([EMAIL PROTECTED]) said:
https://bugzilla.redhat.com/show_bug.cgi?id=433121
DKMS would like to have the opportunity to run it's
auto-rebuilder/installer after a new kernel RPM has been installed,
without
Matt Domsch ([EMAIL PROTECTED]) said:
Use triggers - this functionality already exists without kernel-specific
infrastructure.
a) LSB suggests triggers are evil.
Then triggers must be the right answer.
b) triggers don't tell me the version of the package that got
installed that
On Mon, Feb 18, 2008 at 11:48:41AM -0600, Matt Domsch wrote:
Also from a support perspective, it becomes more complicated to support
kernel installs when random user scripts can cause unknown behaviour.
This has been the argument against DKMS for 5 years now. However, in
those 5 years,
Jason L Tibbitts III ([EMAIL PROTECTED]) said:
MD == Matt Domsch [EMAIL PROTECTED] writes:
MD [...] there's no ordering guarantee between the two such that we
MD know kernel-devel is always installed before kernel.
It should be possible to have kernel-devel have Requires(post): kernel
Peter Jones wrote:
(Adding Panu to the Cc)
Jason L Tibbitts III wrote:
MD == Matt Domsch [EMAIL PROTECTED] writes:
MD [...] there's no ordering guarantee between the two such that we
MD know kernel-devel is always installed before kernel.
It should be possible to have kernel-devel have
PJ == Peter Jones [EMAIL PROTECTED] writes:
PJ That doesn't guarantee the right thing -- it's inverted. It makes
PJ it so that before kernel-devel's %post runs, kernel must be
PJ installed. What Matt needs is a guarantee that kernel-devel is
PJ installed (if it will be installed at all) before
On Mon, Feb 18, 2008 at 01:42:49PM -0600, Jason L Tibbitts III wrote:
PJ == Peter Jones [EMAIL PROTECTED] writes:
PJ That doesn't guarantee the right thing -- it's inverted. It makes
PJ it so that before kernel-devel's %post runs, kernel must be
PJ installed. What Matt needs is a guarantee
(Adding Panu to the Cc)
Jason L Tibbitts III wrote:
MD == Matt Domsch [EMAIL PROTECTED] writes:
MD [...] there's no ordering guarantee between the two such that we
MD know kernel-devel is always installed before kernel.
It should be possible to have kernel-devel have Requires(post): kernel
19 matches
Mail list logo
