Bug 1071607 - udev rules located incorrectly on 64 bit x86
Summary: udev rules located incorrectly on 64 bit x86
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: isdn4k-utils
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-02 10:12 UTC by Paul Bolle
Modified: 2014-07-31 10:00 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-07-31 09:59:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Untested patch to make 40-isdn.rules show up at the right location (803 bytes, patch)
2014-03-02 10:12 UTC, Paul Bolle
no flags Details | Diff

Description Paul Bolle 2014-03-02 10:12:20 UTC
Created attachment 869593 [details]
Untested patch to make 40-isdn.rules show up at the right location

Description of problem:
40-isdn.rules ends up in the wrong location on 64 bit x86

Version-Release number of selected component (if applicable):
3.2-93

How reproducible:
Always

Steps to Reproduce:
1. N/A
2.
3.

Actual results:
On 64 bit x86 40-isdn.rules shows up at /usr/lib64/udev/rules.d/40-isdn.rules. udev ignores that file.

Expected results:
40-isdn.rules always shows up at /usr/lib/udev/rules.d/40-isdn.rules, where udev will use it.

Additional info:
0) I'll add a trivial, but untested, patch to fix this.

1) Note that the 40-isdn.rules is actually broken right now. A proper fix requires a (trivial) patch to the kernel. I've contacted one of the last people really working on isdn in the kernel to test my draft patch. If things work out as I hope I'll try to submit a new udev rules file for isdn4k-utils.

Comment 1 Paul Bolle 2014-03-02 10:20:25 UTC
Comment on attachment 869593 [details]
Untested patch to make 40-isdn.rules show up at the right location

Note how I've already included the changes to 40-isdn.rules! I wanted to submit those changes after getting a fix in the kernel. So feel free to enjoy the preview of those changes but only use the chunk that changes the spec file.

Comment 2 Than Ngo 2014-07-30 11:41:14 UTC
(In reply to Paul Bolle from comment #1)
> Comment on attachment 869593 [details]
> Untested patch to make 40-isdn.rules show up at the right location
> 
> Note how I've already included the changes to 40-isdn.rules! I wanted to
> submit those changes after getting a fix in the kernel. So feel free to
> enjoy the preview of those changes but only use the chunk that changes the
> spec file.

Paul, is it already fixed in the kernel?

Comment 3 Than Ngo 2014-07-30 11:42:37 UTC
feel free to reopen the bug again when it's fixed in kernel. thanks

Comment 4 Paul Bolle 2014-07-30 19:12:50 UTC
(In reply to Ngo Than from comment #2)
> (In reply to Paul Bolle from comment #1)
> > Comment on attachment 869593 [details]
> > Untested patch to make 40-isdn.rules show up at the right location
> > 
> > Note how I've already included the changes to 40-isdn.rules! I wanted to
> > submit those changes after getting a fix in the kernel. So feel free to
> > enjoy the preview of those changes but only use the chunk that changes the
> > spec file.
> 
> Paul, is it already fixed in the kernel?

See commit d1cadce15af8 ("isdn/capi: fix (middleware) device nodes"). That commit just entered mainline (in v3.16-rc1). That commit should allow to drop 40-isdn.rules entirely.

And if people still report issues with capi (middleware) devices nodes when running v3.16-rc1 (or later) I'd like to hear that.

Comment 5 Than Ngo 2014-07-31 09:19:43 UTC
Paul, have you checked if the fix is included in kernel-3.16.0-0.rc7.git1.1.fc22?

if yes, i will drop 40-isdn.rules entirely and rebuild it again

thanks

Comment 6 Than Ngo 2014-07-31 09:59:54 UTC
i even checked the kernel, your fix is already included in kernel-3.16.0-0.rc7.git1.1.fc22.

drop 40-isdn.rules entirely in isdn4k-utils-3.2-98
thanks for you report.


Note You need to log in before you can comment on or make changes to this bug.