[Cooker] [Bug 5568] [gdb] gdb continuously stopping for SIG32 events
http://qa.mandrakesoft.com/show_bug.cgi?id=5568 --- Additional Comments From [EMAIL PROTECTED] 2003-18-09 21:58 --- It appears that something still isn't right: Thread 6 (Thread 65541 (LWP 25107)): #0 0x40be3006 in nanosleep () from /lib/i686/libc.so.6 No symbol table info available. #1 0x in ?? () No symbol table info available. Thread 5 (Thread 49156 (LWP 25106)): #0 0x40be3006 in nanosleep () from /lib/i686/libc.so.6 No symbol table info available. #1 0x in ?? () No symbol table info available. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: MythTV (http://www.mythtv.org) is a multi-threaded application. When debugging in gdb, gdb keeps raising SIG32 events, making it difficult to run / debug the application. Additionally, it appears that gdb does not always capture all thread stacks when a backtrace is performed. Not all versions of gdb created by Mandrake have had these issues when debugging multi-threaded applications, but because the segfaults are rare, it is difficult to remember exactly which gdb packages have had issues, and which don't. 5.3-25 definately has an issue with SIG32 events.
[Cooker] [Bug 5286] [devfsd] devfs creating incorrect entries for lirc
http://qa.mandrakesoft.com/show_bug.cgi?id=5286 --- Additional Comments From [EMAIL PROTECTED] 2003-17-09 21:48 --- Is this a clue? I saw this right after I had rm -rf /dev/lirc and then mknod /dev/lirc c 61 0 Sep 17 14:43:43 frontend devfsd[98]: error calling: unlink in GLOBAL Sep 17 14:43:43 frontend last message repeated 3 times Sep 17 14:43:56 frontend devfsd[98]: error copying: /dev/lirc to /lib/dev-state/lirc Sep 17 14:44:07 frontend devfsd[98]: error copying: /dev/lirc to /lib/dev-state/lirc [EMAIL PROTECTED] dev-state]# cd lirc [EMAIL PROTECTED] lirc]# ls -l total 12 drwxr-xr-t2 root root 4096 Aug 4 23:49 0/ drwxr-xr-t2 root root 4096 Aug 4 23:49 61/ drwxr-xr-t2 root root 4096 Aug 4 23:49 c/ I don't know where the above came from, but I'm assuming that's where the bad device is coming from. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: Running lirc0.7.0pre2 (self compiled because it's not in contrib) to support Hauppauge PVR-250 remote. lirc_i2c is the device driver. After rebooting, these are the entries in /dev: [EMAIL PROTECTED] mythtv]# ls -l /dev/li* srw-rw-rw-1 root root0 Sep 5 02:58 /dev/lircd= prw-r--r--1 root root0 Sep 5 02:58 /dev/lircm| /dev/lirc: total 0 drwxr-xr-x1 root root0 Sep 5 02:58 0/ drwxr-xr-x1 root root0 Sep 5 02:58 61/ drwxr-xr-x1 root root0 Sep 5 02:58 c/ Note that the /dev/lirc directory has three _files_ in it, rather than creating the correct character device. According to the lirc0.7.0pre2 docs, the correct device would be created with mknod /dev/lirc c 61 0
[Cooker] [Bug 5568] [gdb] gdb continuously stopping for SIG32 events
http://qa.mandrakesoft.com/show_bug.cgi?id=5568 --- Additional Comments From [EMAIL PROTECTED] 2003-16-09 18:34 --- Which files need to be installed from Gwenole's directory to test this? -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: MythTV (http://www.mythtv.org) is a multi-threaded application. When debugging in gdb, gdb keeps raising SIG32 events, making it difficult to run / debug the application. Additionally, it appears that gdb does not always capture all thread stacks when a backtrace is performed. Not all versions of gdb created by Mandrake have had these issues when debugging multi-threaded applications, but because the segfaults are rare, it is difficult to remember exactly which gdb packages have had issues, and which don't. 5.3-25 definately has an issue with SIG32 events.
[Cooker] [Bug 5568] [gdb] gdb continuously stopping for SIG32 events
http://qa.mandrakesoft.com/show_bug.cgi?id=5568 --- Additional Comments From [EMAIL PROTECTED] 2003-16-09 19:17 --- I was able to get gdb to run without the SIG32 interruptions, so at least that part works. I will see if I can get a test case on the not showing all thread stacks issue. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: MythTV (http://www.mythtv.org) is a multi-threaded application. When debugging in gdb, gdb keeps raising SIG32 events, making it difficult to run / debug the application. Additionally, it appears that gdb does not always capture all thread stacks when a backtrace is performed. Not all versions of gdb created by Mandrake have had these issues when debugging multi-threaded applications, but because the segfaults are rare, it is difficult to remember exactly which gdb packages have had issues, and which don't. 5.3-25 definately has an issue with SIG32 events.
[Cooker] [Bug 5758] [qt3-common] New: qmake is creating Makefile with strip even if DEBUG is defined
http://qa.mandrakesoft.com/show_bug.cgi?id=5758 Product: qt3-common Component: program Summary: qmake is creating Makefile with strip even if DEBUG is defined Product: qt3-common Version: 3.1.2-14mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: program AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] MythTV (http://www.mythtv.org) has a top-level settings.pro that has CONFIG += debug defined. Qmake creates the sub-Makefiles for the various components of Myth. QMake should not strip a binary if it's been compiled for debug, because that makes it fairly useless. ### Install install_target: @$(CHK_DIR_EXISTS) $(INSTALL_ROOT)/usr/local/bin/ || $(MKDIR) $(INSTALL_ROOT)/usr/local/bin/ -$(COPY) $(QMAKE_TARGET) $(INSTALL_ROOT)/usr/local/bin/$(QMAKE_TARGET) -strip $(INSTALL_ROOT)/usr/local/bin/$(QMAKE_TARGET) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 5568] [gdb] gdb continuously stopping for SIG32 events
http://qa.mandrakesoft.com/show_bug.cgi?id=5568 --- Additional Comments From [EMAIL PROTECTED] 2003-15-09 20:42 --- From what I've been told on #mythtv by the developer, doing the nostop doesn't fix the actual issue, which is that gdb should be working correctly in the first place. The nostop merely hides the issue and causes problems later on. This severely impacts the ability to debug the multi-threaded application. Debian (distro of MythTV developer) doesn't have this issue. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: MythTV (http://www.mythtv.org) is a multi-threaded application. When debugging in gdb, gdb keeps raising SIG32 events, making it difficult to run / debug the application. Additionally, it appears that gdb does not always capture all thread stacks when a backtrace is performed. Not all versions of gdb created by Mandrake have had these issues when debugging multi-threaded applications, but because the segfaults are rare, it is difficult to remember exactly which gdb packages have had issues, and which don't. 5.3-25 definately has an issue with SIG32 events.
[Cooker] [Bug 5568] [gdb] New: gdb continuously stopping for SIG32 events
http://qa.mandrakesoft.com/show_bug.cgi?id=5568 Product: gdb Component: program Summary: gdb continuously stopping for SIG32 events Product: gdb Version: 5.3-25mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: program AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] MythTV (http://www.mythtv.org) is a multi-threaded application. When debugging in gdb, gdb keeps raising SIG32 events, making it difficult to run / debug the application. Additionally, it appears that gdb does not always capture all thread stacks when a backtrace is performed. Not all versions of gdb created by Mandrake have had these issues when debugging multi-threaded applications, but because the segfaults are rare, it is difficult to remember exactly which gdb packages have had issues, and which don't. 5.3-25 definately has an issue with SIG32 events. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 5413] [mandrake_theme] New: Can not install: conditional binary operator expected
http://qa.mandrakesoft.com/show_bug.cgi?id=5413 Product: mandrake_theme Component: packaging Summary: Can not install: conditional binary operator expected Product: mandrake_theme Version: 0.0.6-1mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] installing /var/cooker/csociety-ftp.ecn.purdue.edu/pub/Mandrake-devel/cooker/i586/Mandrake/RPMS/mandrake_theme-0.0.6-1mdk.noarch.rpm starting installing packages using process 0 for executing transaction created transaction for installing on / (remove=0, install=0, upgrade=1) adding package mandrake_theme-0.0.6-1mdk.noarch (id=9139, eid=9139, update=1, file=/var/cooker/csociety-ftp.ecn.purdue.edu/pub/Mandrake-devel/cooker/i586/Mandrake/RPMS/mandrake_theme-0.0.6-1mdk.noarch.rpm) Preparing...## 65:mandrake_theme ## /var/tmp/rpm-tmp.70383: line 4: conditional binary operator expected /var/tmp/rpm-tmp.70383: line 4: syntax error near `/usr/share/mdk/backgrounds//default.png' /var/tmp/rpm-tmp.70383: line 4: `if [[ readlink /usr/share/mdk/backgrounds//default.png == Mandrake.png ]]; then rm -f /usr/share/mdk/backgrounds//default.png;fi' error: %preun(mandrake_theme-0.0.5-1mdk) scriptlet failed, exit status 2 -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 5416] [bootloader-utils] New: File conflicts between bootloader-utils and kernel-utils
http://qa.mandrakesoft.com/show_bug.cgi?id=5416 Product: bootloader-utils Component: packaging Summary: File conflicts between bootloader-utils and kernel-utils Product: bootloader-utils Version: 1.6-1mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] [EMAIL PROTECTED] mythtv]# rpm -qa|grep rpm rpm-4.2-16mdk urpmi-4.4-33mdk rpm-helper-0.9-1mdk gurpmi-4.4-33mdk rpmdrake-2.1-35mdk rpm-build-4.2-16mdk rpmtools-4.5-13mdk 5 installation transactions failed: file /sbin/installkernel from install of bootloader-utils-1.6-1mdk conflicts with file from package kernel-utils-1.1-1mdk file /usr/share/loader/common.pm from install of bootloader-utils-1.6-1mdk conflicts with file from package kernel-utils-1.1-1mdk file /usr/share/loader/lilo from install of bootloader-utils-1.6-1mdk conflicts with file from package kernel-utils-1.1-1mdk -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 5422] [groff-for-man] New: Circular conflict between groff and groff-for-man on file andoc.tmac
http://qa.mandrakesoft.com/show_bug.cgi?id=5422 Product: groff-for-man Component: packaging Summary: Circular conflict between groff and groff-for-man on file andoc.tmac Product: groff-for-man Version: 1.19-3mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] file /usr/share/groff/1.19/tmac/andoc.tmac from install of groff-for-man-1.19-3mdk conflicts with file from package groff-1.19-2mdk file /usr/share/groff/1.19/tmac/andoc.tmac from install of groff-1.19-3mdk conflicts with file from package groff-for-man-1.19-2mdk -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 5286] [devfsd] devfs creating incorrect entries for lirc
http://qa.mandrakesoft.com/show_bug.cgi?id=5286 --- Additional Comments From [EMAIL PROTECTED] 2003-07-09 04:46 --- [EMAIL PROTECTED] mythtv]# rm -rf /dev/lirc [EMAIL PROTECTED] mythtv]# ls -l /dev/li* srw-rw-rw-1 root root0 Sep 5 02:58 /dev/lircd= prw-r--r--1 root root0 Sep 5 02:58 /dev/lircm| [EMAIL PROTECTED] mythtv]# shutdown -r now After reboot: [EMAIL PROTECTED] mythtv]$ su [EMAIL PROTECTED] mythtv]# ls -l /dev/li* srw-rw-rw-1 root root0 Sep 6 15:00 /dev/lircd= prw-r--r--1 root root0 Sep 6 15:00 /dev/lircm| /dev/lirc: total 0 drwxr-xr-x1 root root0 Sep 6 15:00 0/ drwxr-xr-x1 root root0 Sep 6 15:00 61/ drwxr-xr-x1 root root0 Sep 6 15:00 c/ [EMAIL PROTECTED] mythtv]# So, _something_ is creating these files rather than the character device at major 61, minor 0. Is makedev.d/mandrake the culprit? -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: Running lirc0.7.0pre2 (self compiled because it's not in contrib) to support Hauppauge PVR-250 remote. lirc_i2c is the device driver. After rebooting, these are the entries in /dev: [EMAIL PROTECTED] mythtv]# ls -l /dev/li* srw-rw-rw-1 root root0 Sep 5 02:58 /dev/lircd= prw-r--r--1 root root0 Sep 5 02:58 /dev/lircm| /dev/lirc: total 0 drwxr-xr-x1 root root0 Sep 5 02:58 0/ drwxr-xr-x1 root root0 Sep 5 02:58 61/ drwxr-xr-x1 root root0 Sep 5 02:58 c/ Note that the /dev/lirc directory has three _files_ in it, rather than creating the correct character device. According to the lirc0.7.0pre2 docs, the correct device would be created with mknod /dev/lirc c 61 0
[Cooker] [Bug 5286] [devfsd] devfs creating incorrect entries for lirc
http://qa.mandrakesoft.com/show_bug.cgi?id=5286 --- Additional Comments From [EMAIL PROTECTED] 2003-07-09 07:47 --- Created an attachment (id=758) -- (http://qa.mandrakesoft.com/attachment.cgi?id=758action=view) Per instructions. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: Running lirc0.7.0pre2 (self compiled because it's not in contrib) to support Hauppauge PVR-250 remote. lirc_i2c is the device driver. After rebooting, these are the entries in /dev: [EMAIL PROTECTED] mythtv]# ls -l /dev/li* srw-rw-rw-1 root root0 Sep 5 02:58 /dev/lircd= prw-r--r--1 root root0 Sep 5 02:58 /dev/lircm| /dev/lirc: total 0 drwxr-xr-x1 root root0 Sep 5 02:58 0/ drwxr-xr-x1 root root0 Sep 5 02:58 61/ drwxr-xr-x1 root root0 Sep 5 02:58 c/ Note that the /dev/lirc directory has three _files_ in it, rather than creating the correct character device. According to the lirc0.7.0pre2 docs, the correct device would be created with mknod /dev/lirc c 61 0
[Cooker] [Bug 5286] [devfsd] devfs creating incorrect entries for lirc
http://qa.mandrakesoft.com/show_bug.cgi?id=5286 --- Additional Comments From [EMAIL PROTECTED] 2003-07-09 07:49 --- [EMAIL PROTECTED] mythtv]$ ls /dev apm_bios@ md0@md137@ md176@ md214@ md253@ md62@ mixer@ ptyc2@ ptyed@ ptyr8@ ptyu3@ ptywe@ ptyz9@ tty1@ tty49@ audio@ md1@md138@ md177@ md215@ md254@ md63@ mouse@ ptyc3@ ptyee@ ptyr9@ ptyu4@ ptywf@ ptyza@ tty10@ tty5@ cdrom@ md10@ md139@ md178@ md216@ md255@ md64@ nullptyc4@ ptyef@ ptyra@ ptyu5@ ptyx0@ ptyzb@ tty11@ tty50@ cdrom0@md100@ md14@ md179@ md217@ md26@ md65@ portptyc5@ ptyp0@ ptyrb@ ptyu6@ ptyx1@ ptyzc@ tty12@ tty51@ cdroms/md101@ md140@ md18@ md218@ md27@ md66@ ppp ptyc6@ ptyp1@ ptyrc@ ptyu7@ ptyx2@ ptyzd@ tty13@ tty52@ consolemd102@ md141@ md180@ md219@ md28@ md67@ psaux@ ptyc7@ ptyp2@ ptyrd@ ptyu8@ ptyx3@ ptyze@ tty14@ tty53@ cpu/ md103@ md142@ md181@ md22@ md29@ md68@ ptmxptyc8@ ptyp3@ ptyre@ ptyu9@ ptyx4@ ptyzf@ tty15@ tty54@ cua/ md104@ md143@ md182@ md220@ md3@md69@ pts/ptyc9@ ptyp4@ ptyrf@ ptyua@ ptyx5@ ram0@tty16@ tty55@ cua0@ md105@ md144@ md183@ md221@ md30@ md7@ pty/ptyca@ ptyp5@ ptys0@ ptyub@ ptyx6@ ram1@tty17@ tty56@ discs/ md106@ md145@ md184@ md222@ md31@ md70@ ptya0@ ptycb@ ptyp6@ ptys1@ ptyuc@ ptyx7@ ram10@ tty18@ tty57@ dsp@ md107@ md146@ md185@ md223@ md32@ md71@ ptya1@ ptycc@ ptyp7@ ptys2@ ptyud@ ptyx8@ ram11@ tty19@ tty58@ dvd@ md108@ md147@ md186@ md224@ md33@ md72@ ptya2@ ptycd@ ptyp8@ ptys3@ ptyue@ ptyx9@ ram12@ tty2@ tty59@ fb/md109@ md148@ md187@ md225@ md34@ md73@ ptya3@ ptyce@ ptyp9@ ptys4@ ptyuf@ ptyxa@ ram13@ tty20@ tty6@ fb0@ md11@ md149@ md188@ md226@ md35@ md74@ ptya4@ ptycf@ ptypa@ ptys5@ ptyv0@ ptyxb@ ram14@ tty21@ tty60@ fd@md110@ md15@ md189@ md227@ md36@ md75@ ptya5@ ptyd0@ ptypb@ ptys6@ ptyv1@ ptyxc@ ram15@ tty22@ tty61@ floppy/md111@ md150@ md19@ md228@ md37@ md76@ ptya6@ ptyd1@ ptypc@ ptys7@ ptyv2@ ptyxd@ ram2@tty23@ tty62@ full md112@ md151@ md190@ md229@ md38@ md77@ ptya7@ ptyd2@ ptypd@ ptys8@ ptyv3@ ptyxe@ ram3@tty24@ tty63@ hda@ md113@ md152@ md191@ md23@ md39@ md78@ ptya8@ ptyd3@ ptype@ ptys9@ ptyv4@ ptyxf@ ram4@tty25@ tty7@ hdb@ md114@ md153@ md192@ md230@ md4@md79@ ptya9@ ptyd4@ ptypf@ ptysa@ ptyv5@ ptyy0@ ram5@tty26@ tty8@ hdb1@ md115@ md154@ md193@ md231@ md40@ md8@ ptyaa@ ptyd5@ ptyq0@ ptysb@ ptyv6@ ptyy1@ ram6@tty27@ tty9@ hdb2@ md116@ md155@ md194@ md232@ md41@ md80@ ptyab@ ptyd6@ ptyq1@ ptysc@ ptyv7@ ptyy2@ ram7@tty28@ ttyS0@ hdb5@ md117@ md156@ md195@ md233@ md42@ md81@ ptyac@ ptyd7@ ptyq2@ ptysd@ ptyv8@ ptyy3@ ram8@tty29@ urandom hdb6@ md118@ md157@ md196@ md234@ md43@ md82@ ptyad@ ptyd8@ ptyq3@ ptyse@ ptyv9@ ptyy4@ ram9@tty3@ usb/ ide/ md119@ md158@ md197@ md235@ md44@ md83@ ptyae@ ptyd9@ ptyq4@ ptysf@ ptyva@ ptyy5@ raminitrd@ tty30@ usbmouse@ initctl| md12@ md159@ md198@ md236@ md45@ md84@ ptyaf@ ptyda@ ptyq5@ ptyt0@ ptyvb@ ptyy6@ random tty31@ vc/ initrd@md120@ md16@ md199@ md237@ md46@ md85@ ptyb0@ ptydb@ ptyq6@ ptyt1@ ptyvc@ ptyy7@ raw/ tty32@ vcc/ input/ md121@ md160@ md2@md238@ md47@ md86@ ptyb1@ ptydc@ ptyq7@ ptyt2@ ptyvd@ ptyy8@ rd/ tty33@ vcs@ kmem md122@ md161@ md20@ md239@ md48@ md87@ ptyb2@ ptydd@ ptyq8@ ptyt3@ ptyve@ ptyy9@ rdvd@tty34@ vcs1@ lirc md123@ md162@ md200@ md24@ md49@ md88@ ptyb3@ ptyde@ ptyq9@ ptyt4@ ptyvf@ ptyya@ root tty35@ vcs2@ lircd= md124@ md163@ md201@ md240@ md5@md89@ ptyb4@ ptydf@ ptyqa@ ptyt5@ ptyw0@ ptyyb@ root.old@tty36@ vcs3@ lircm| md125@ md164@ md202@ md241@ md50@ md9@ ptyb5@ ptye0@ ptyqb@ ptyt6@ ptyw1@ ptyyc@ rtc@ tty37@ vcs4@ log= md126@ md165@ md203@ md242@ md51@ md90@ ptyb6@ ptye1@ ptyqc@ ptyt7@ ptyw2@ ptyyd@ scsi/tty38@ vcs5@ loop/ md127@ md166@ md204@ md243@ md52@ md91@ ptyb7@ ptye2@ ptyqd@ ptyt8@ ptyw3@ ptyye@ sequencer@ tty39@ vcs6@ loop0@ md128@ md167@ md205@ md244@ md53@ md92@ ptyb8@ ptye3@ ptyqe@ ptyt9@ ptyw4@ ptyyf@ sequencer2@ tty4@ vcs7@ loop1@ md129@ md168@ md206@ md245@ md54@ md93@ ptyb9@ ptye4@ ptyqf@ ptyta@ ptyw5@ ptyz0@ shm/ tty40@ vcsa@ loop2@ md13@ md169@ md207@ md246@ md55@ md94@ ptyba@ ptye5@ ptyr0@ ptytb@ ptyw6@ ptyz1@ snd/ tty41@ vcsa1@ loop3@ md130@ md17@
[Cooker] [Bug 5286] [devfsd] New: devfs creating incorrect entries for lirc
http://qa.mandrakesoft.com/show_bug.cgi?id=5286 Product: devfsd Component: devfsd Summary: devfs creating incorrect entries for lirc Product: devfsd Version: 1.3.25-32mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: devfsd AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Running lirc0.7.0pre2 (self compiled because it's not in contrib) to support Hauppauge PVR-250 remote. lirc_i2c is the device driver. After rebooting, these are the entries in /dev: [EMAIL PROTECTED] mythtv]# ls -l /dev/li* srw-rw-rw-1 root root0 Sep 5 02:58 /dev/lircd= prw-r--r--1 root root0 Sep 5 02:58 /dev/lircm| /dev/lirc: total 0 drwxr-xr-x1 root root0 Sep 5 02:58 0/ drwxr-xr-x1 root root0 Sep 5 02:58 61/ drwxr-xr-x1 root root0 Sep 5 02:58 c/ Note that the /dev/lirc directory has three _files_ in it, rather than creating the correct character device. According to the lirc0.7.0pre2 docs, the correct device would be created with mknod /dev/lirc c 61 0 -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3356] [drakxtools-newt] Can not upgrade due to file collision with msec
http://qa.mandrakesoft.com/show_bug.cgi?id=3356 --- Additional Comments From [EMAIL PROTECTED] 2003-03-19 23:54 --- Thanks. Apologies for being a bonehead and not even checking if msec was the problem. Am I correct in assuming that if I run urpmi -v --auto-select it will automatically upgrade all packages that I have installed if there is a newer version of the package in a local cooker mirror (and if I've used urpmi.addmedia local.cooker file://path)? --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: Installation failed: file /usr/lib/libDrakX/security/help.pm from install of drakxtools-newt-9.1-25mdk conflicts with file from package msec-0.38-1mdk
[Cooker] [Bug 3358] [lirc] lirc not correctly creating symlinks for serial devices
http://qa.mandrakesoft.com/show_bug.cgi?id=3358
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEEDINFO|UNCONFIRMED
--- Additional Comments From [EMAIL PROTECTED] 2003-03-18 15:38 ---
Directly specifying the DEVICE=/dev/ttyS0 works. Can the inline documentation in the
/etc/sysconfig/lirc file be expanded a little to include that as a possibility? I
posted a
recommended lirc file that was more verbose in the various options available, such as
telling
the user where the 3rd party modules were, etc.
So, in your comment #2 where you said that devfs would automatically create the device
when
the driver loads, that's true in all cases except for direct serial access because the
Mandrake
kernel has serial compiled into the source, correct?
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: UNCONFIRMED
creation_date:
description:
I have a pinnacle systems dumb IR receiver which connects to the COM1 / COM2 serial
port.
The example /etc/sysconfig/lircd file gives the user no indication that they need to
create a
symlink between the actual tty device and the /dev/lirc entry.
Here's a working example:
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=pinsys
# Hardware driver module to load
HWMOD=serial
# The device node that communicates with the IR device.
# with devfs enabled
DEVICE=/dev/lirc/1
snip
[EMAIL PROTECTED] dev]# ls -l /dev/lirc/1
lr-xr-xr-x1 root root 10 Mar 15 21:48 /dev/lirc/1 - /dev/ttyS1
It took me about 2 hours to figure this out. I recommend that the lircd file be a
little more
verbose with examples.
Here is an updated /etc/sysconfig/lircd file that I think explains things better.
(Note that the symlink is created correctly when manually installing lirc from a
tarball because
the lirc configure program does this as a part of the installation process)
[EMAIL PROTECTED] sysconfig]# cat lircd
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=UNCONFIGURED
# Hardware driver module to load
# Choices are:
# serial
# lirc_serial (for home-brew serial port IR receivers)
# lirc_parallel
# etc. See /lib/modules/{kern-version}/kernel/3rdparty/lirc for a
# list of modules.
HWMOD=UNCONFIGURED
# The device node that communicates with the IR device.
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc/ entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc/0
# or as root# ln -sf ttyS0 lirc/serial
# If you are using devfs, use one of the following and create the symlink
# as shown above
# DEVICE=/dev/lirc/0
# DEVICE=/dev/lirc/serial
# Without devfs:
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc
# DEVICE=/dev/lirc
# Serial port for the receiver (for serial driver)
# COM1 (/dev/ttyS0)
#COM_PORT=/dev/ttyS0
#DRIVER_OPTS=irq=4 io=0x3f8
# COM2 (/dev/ttyS1)
#COM_PORT=/dev/ttyS1
#DRIVER_OPTS=irq=3 io=0x2f8
# COM3 (/dev/ttyS2)
#COM_PORT=/dev/ttyS2
#DRIVER_OPTS=irq=4 io=0x3e8
# COM4 (/dev/ttyS3)
#COM_PORT=/dev/ttyS3
#DRIVER_OPTS=irq=3 io=0x2e8
[Cooker] [Bug 3358] [lirc] lirc not correctly creating symlinks for serial devices
http://qa.mandrakesoft.com/show_bug.cgi?id=3358
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEEDINFO|UNCONFIRMED
--- Additional Comments From [EMAIL PROTECTED] 2003-03-18 15:59 ---
OK - If you're going to be changing the inline documentation in the
/etc/sysconfig/lirc file for the case where the user is using a serial port IR
receiver that doesn't require a kernel driver, then this bug can be closed out.
Many thanks.
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: UNCONFIRMED
creation_date:
description:
I have a pinnacle systems dumb IR receiver which connects to the COM1 / COM2 serial
port.
The example /etc/sysconfig/lircd file gives the user no indication that they need to
create a
symlink between the actual tty device and the /dev/lirc entry.
Here's a working example:
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=pinsys
# Hardware driver module to load
HWMOD=serial
# The device node that communicates with the IR device.
# with devfs enabled
DEVICE=/dev/lirc/1
snip
[EMAIL PROTECTED] dev]# ls -l /dev/lirc/1
lr-xr-xr-x1 root root 10 Mar 15 21:48 /dev/lirc/1 - /dev/ttyS1
It took me about 2 hours to figure this out. I recommend that the lircd file be a
little more
verbose with examples.
Here is an updated /etc/sysconfig/lircd file that I think explains things better.
(Note that the symlink is created correctly when manually installing lirc from a
tarball because
the lirc configure program does this as a part of the installation process)
[EMAIL PROTECTED] sysconfig]# cat lircd
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=UNCONFIGURED
# Hardware driver module to load
# Choices are:
# serial
# lirc_serial (for home-brew serial port IR receivers)
# lirc_parallel
# etc. See /lib/modules/{kern-version}/kernel/3rdparty/lirc for a
# list of modules.
HWMOD=UNCONFIGURED
# The device node that communicates with the IR device.
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc/ entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc/0
# or as root# ln -sf ttyS0 lirc/serial
# If you are using devfs, use one of the following and create the symlink
# as shown above
# DEVICE=/dev/lirc/0
# DEVICE=/dev/lirc/serial
# Without devfs:
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc
# DEVICE=/dev/lirc
# Serial port for the receiver (for serial driver)
# COM1 (/dev/ttyS0)
#COM_PORT=/dev/ttyS0
#DRIVER_OPTS=irq=4 io=0x3f8
# COM2 (/dev/ttyS1)
#COM_PORT=/dev/ttyS1
#DRIVER_OPTS=irq=3 io=0x2f8
# COM3 (/dev/ttyS2)
#COM_PORT=/dev/ttyS2
#DRIVER_OPTS=irq=4 io=0x3e8
# COM4 (/dev/ttyS3)
#COM_PORT=/dev/ttyS3
#DRIVER_OPTS=irq=3 io=0x2e8
[Cooker] [Bug 3358] [lirc] lirc not correctly creating symlinks for serial devices
http://qa.mandrakesoft.com/show_bug.cgi?id=3358 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED --- Additional Comments From [EMAIL PROTECTED] 2003-03-17 17:12 --- Then it appears that devfs is broken, or something else. devfsd-1.3.25-23mdk Before installing lircd: [EMAIL PROTECTED] dev]# ls -l /dev/li* srw-rw-rw-1 root root0 Mar 15 10:35 /dev/lircd= /dev/lirc: total 0 [EMAIL PROTECTED] dev]# urpmi lirc installing /var/cooker/ftp.orst.edu/.1/mandrake-devel/cooker/cooker/Mandrake/RPMS/lirc-0.6.6-1mdk.i586.rpm Edited /etc/sysconfig/lirc to use pinsys, serial and COM2: # Customized setings for lirc daemon # The hardware driver to use, run lircd --driver=? for a list DRIVER=pinsys # Hardware driver module to load HWMOD=serial # The device node that communicates with the IR device. # with devfs enabled DEVICE=/dev/lirc/1 #DEVICE=/dev/lirc/serial # without devfs #DEVICE=/dev/lirc # Serial port for the receiver (for serial driver) # COM1 (/dev/ttyS0) #COM_PORT=/dev/ttyS0 #DRIVER_OPTS=irq=4 io=0x3f8 # COM2 (/dev/ttyS1) COM_PORT=/dev/ttyS1 DRIVER_OPTS=irq=3 io=0x2f8 save # /etc/rc.d/init.d/lircd start Starting Linux Infrared Remote Control daemon: [ OK ] /var/log/messages: Mar 17 09:58:09 backend2 lircd 0.6.6[7173]: lircd(any) ready Mar 17 09:58:09 backend2 lircd: lircd startup succeeded [EMAIL PROTECTED] dev]# ls -l li* srw-rw-rw-1 root root0 Mar 15 10:35 lircd= lirc: total 0 [EMAIL PROTECTED] dev]# [Note that there is no symlink in /dev/lirc/1 back to ttyS1] [EMAIL PROTECTED] mythtv]$ irw [Immediately returns] Mar 17 10:00:10 backend2 lircd 0.6.6[7173]: accepted new client on /tmp/.lircd Mar 17 10:00:10 backend2 lircd 0.6.6[7173]: readlink() failed for /dev/lirc/1 Mar 17 10:00:10 backend2 lircd 0.6.6[7173]: No such file or directory Mar 17 10:00:10 backend2 lircd 0.6.6[7173]: could not create lock files Mar 17 10:00:10 backend2 lircd 0.6.6[7173]: caught signal [EMAIL PROTECTED] dev]# /etc/rc.d/init.d/lircd status lircd dead but subsys locked [EMAIL PROTECTED] dev]# cd lirc [EMAIL PROTECTED] lirc]# ls -l total 0 [EMAIL PROTECTED] lirc]# ln -sf ../ttyS1 1 [EMAIL PROTECTED] lirc]# ls -l total 0 lr-xr-xr-x1 root root8 Mar 17 10:02 1 - ../ttyS1 [EMAIL PROTECTED] lirc]# /etc/rc.d/init.d/lircd restart Stopping Linux Infrared Remote Control daemon: [FAILED] Starting Linux Infrared Remote Control daemon: [ OK ] [EMAIL PROTECTED] lirc]# [EMAIL PROTECTED] mythtv]$ irw 001a 00 middle PinnacleSysPCTVRemote 003f 00 Chan+Play PinnacleSysPCTVRemote 002f 00 Power PinnacleSysPCTVRemote Mar 17 10:08:49 backend2 lircd 0.6.6[7366]: accepted new client on /tmp/.lircd Mar 17 10:08:49 backend2 lircd 0.6.6[7366]: could not create lock file /var/lock/LCK..1 Mar 17 10:08:49 backend2 lircd 0.6.6[7366]: File exists Mar 17 10:08:49 backend2 lircd 0.6.6[7366]: tts/1 is locked by PID 7366 [ie, it works.] So, I maintain that something is not correct; lirc did not work until I manually created the symlink in /dev/lirc/ from /dev/ttyS1 to /dev/lirc/1 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: I have a pinnacle systems dumb IR receiver which connects to the COM1 / COM2 serial port. The example /etc/sysconfig/lircd file gives the user no indication that they need to create a symlink between the actual tty device and the /dev/lirc entry. Here's a working example: # Customized setings for lirc daemon # The hardware driver to use, run lircd --driver=? for a list DRIVER=pinsys # Hardware driver module to load HWMOD=serial # The device node that communicates with the IR device. # with devfs enabled DEVICE=/dev/lirc/1 snip [EMAIL PROTECTED] dev]# ls -l /dev/lirc/1 lr-xr-xr-x1 root root 10 Mar 15 21:48 /dev/lirc/1 - /dev/ttyS1 It took me about 2 hours to figure this out. I recommend that the lircd file be a little more verbose with examples. Here is an updated /etc/sysconfig/lircd file that I think explains things better. (Note that the symlink is created correctly when manually installing lirc from a tarball because the lirc configure program does this as a part of the installation process) [EMAIL PROTECTED] sysconfig]# cat lircd # Customized setings for lirc daemon # The hardware driver to use, run lircd --driver=? for a list DRIVER=UNCONFIGURED # Hardware driver module to load # Choices are: # serial # lirc_serial (for home-brew
[Cooker] [Bug 3361] [lirc-remotes] lirc-remotes v0.6.5 not the most current set of remotes available
http://qa.mandrakesoft.com/show_bug.cgi?id=3361 --- Additional Comments From [EMAIL PROTECTED] 2003-03-17 17:19 --- Sorry - wasn't sure of the correct procedure. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: the remotes.tar.bz2 file on http://www.lirc.org has remotes as recent as 2003-02-03. The packaged lirc-remotes file is very out of date.
[Cooker] [Bug 3358] [lirc] lirc not correctly creating symlinks for serial devices
http://qa.mandrakesoft.com/show_bug.cgi?id=3358
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEEDINFO|UNCONFIRMED
--- Additional Comments From [EMAIL PROTECTED] 2003-03-17 18:48 ---
lirc_serial is apparently used for custom hardware that is attached to the COM ports;
when I
change serial in /etc/sysconfig/lirc to lirc_serial and restart lirc, devfs creates a
device in
/dev/lirc/ called serial, so that works ok, and lsmod shows lirc_serial loaded.
[EMAIL PROTECTED] dev]# ls -l li*
srw-rw-rw-1 root root0 Mar 15 10:35 lircd=
lirc:
total 0
crw---1 root root 61, 0 Dec 31 1969 serial
[EMAIL PROTECTED] dev]#
Mar 17 11:30:23 backend2 kernel: lirc_serial: auto-detected active high receiver
Mar 17 11:30:23 backend2 lircd 0.6.6[11247]: lircd(any) ready
Mar 17 11:30:23 backend2 lircd: lircd startup succeeded
[EMAIL PROTECTED] mythtv]$ irw
immediately exits
Mar 17 11:30:41 backend2 lircd 0.6.6[11247]: accepted new client on /tmp/.lircd
Mar 17 11:30:41 backend2 lircd 0.6.6[11247]: could not reset tty
Mar 17 11:30:41 backend2 lircd 0.6.6[11247]: caught signal
I don't believe that lirc_serial is the proper device driver for my hardware, and the
device that
it creates is a different major than ttyS1:
[EMAIL PROTECTED] dev]# ls -l ttyS1
lr-xr-xr-x1 root root5 Mar 15 04:33 ttyS1 - tts/1
[EMAIL PROTECTED] dev]# cd tts
[EMAIL PROTECTED] tts]# ls -l 1
crw-rw1 mythtv tty4, 65 Dec 31 1969 1
[EMAIL PROTECTED] tts]#
Note: the kernel that I'm using has standard serial manipulation built-in, not as a
module.
Linux backend2 2.4.21-0.13mdk #1 Fri Mar 7 06:31:12 CET 2003 i686 unknown unknown
GNU/Linux
Again, if I change lirc_serial to serial and create the symlink manually in lirc
everything works
again. The pinnacle doesn't use custom hardware, so lirc_serial isn't the correct
driver.
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: UNCONFIRMED
creation_date:
description:
I have a pinnacle systems dumb IR receiver which connects to the COM1 / COM2 serial
port.
The example /etc/sysconfig/lircd file gives the user no indication that they need to
create a
symlink between the actual tty device and the /dev/lirc entry.
Here's a working example:
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=pinsys
# Hardware driver module to load
HWMOD=serial
# The device node that communicates with the IR device.
# with devfs enabled
DEVICE=/dev/lirc/1
snip
[EMAIL PROTECTED] dev]# ls -l /dev/lirc/1
lr-xr-xr-x1 root root 10 Mar 15 21:48 /dev/lirc/1 - /dev/ttyS1
It took me about 2 hours to figure this out. I recommend that the lircd file be a
little more
verbose with examples.
Here is an updated /etc/sysconfig/lircd file that I think explains things better.
(Note that the symlink is created correctly when manually installing lirc from a
tarball because
the lirc configure program does this as a part of the installation process)
[EMAIL PROTECTED] sysconfig]# cat lircd
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=UNCONFIGURED
# Hardware driver module to load
# Choices are:
# serial
# lirc_serial (for home-brew serial port IR receivers)
# lirc_parallel
# etc. See /lib/modules/{kern-version}/kernel/3rdparty/lirc for a
# list of modules.
HWMOD=UNCONFIGURED
# The device node that communicates with the IR device.
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc/ entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc/0
# or as root# ln -sf ttyS0 lirc/serial
# If you are using devfs, use one of the following and create the symlink
# as shown above
# DEVICE=/dev/lirc/0
# DEVICE=/dev/lirc/serial
# Without devfs:
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc
# DEVICE=/dev/lirc
# Serial port for the receiver (for serial driver)
# COM1 (/dev/ttyS0)
#COM_PORT=/dev/ttyS0
#DRIVER_OPTS=irq=4 io=0x3f8
# COM2 (/dev/ttyS1)
#COM_PORT=/dev/ttyS1
#DRIVER_OPTS=irq=3 io=0x2f8
# COM3 (/dev/ttyS2)
#COM_PORT=/dev/ttyS2
#DRIVER_OPTS=irq=4 io=0x3e8
# COM4 (/dev/ttyS3)
#COM_PORT=/dev/ttyS3
#DRIVER_OPTS=irq=3 io=0x2e8
[Cooker] [Bug 3358] [lirc] lirc not correctly creating symlinks for serial devices
http://qa.mandrakesoft.com/show_bug.cgi?id=3358
--- Additional Comments From [EMAIL PROTECTED] 2003-03-17 22:24 ---
More information:
From a fresh reboot.
Mar 17 11:57:00 backend2 lircd 0.6.6[2568]: lircd(any) ready
Mar 17 11:57:00 backend2 lircd: lircd startup succeeded
Mar 17 11:57:00 backend2 lircd 0.6.6[2568]: accepted new client on /tmp/.lircd
Mar 17 11:57:00 backend2 lircmd: lircmd startup succeeded
Mar 17 11:57:00 backend2 lircd 0.6.6[2568]: readlink() failed for /dev/lirc/serial
Mar 17 11:57:00 backend2 lircd 0.6.6[2568]: No such file or directory
Mar 17 11:57:00 backend2 lircd 0.6.6[2568]: could not create lock files
Mar 17 11:57:00 backend2 lircd 0.6.6[2568]: caught signal
[EMAIL PROTECTED] dev]# ls -l li*
srw-rw-rw-1 root root0 Mar 17 05:50 lircd=
prw-r--r--1 root root0 Mar 17 11:52 lircm|
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=pinsys
# Hardware driver module to load
HWMOD=serial
# The device node that communicates with the IR device.
# with devfs enabled
#DEVICE=/dev/lirc/1
DEVICE=/dev/lirc/serial
# without devfs
#DEVICE=/dev/lirc
# Serial port for the receiver (for serial driver)
# COM1 (/dev/ttyS0)
#COM_PORT=/dev/ttyS0
#DRIVER_OPTS=irq=4 io=0x3f8
# COM2 (/dev/ttyS1)
COM_PORT=/dev/ttyS1
DRIVER_OPTS=irq=3 io=0x2f8
Using the serial driver, no /dev/lirc/serial directory was created by devfs -
because serial is
compiled into the kernel?
When I reboot, and re-run with driver=lirc_serial, devfs does the right thing and
creates a
device, but apparently this is the wrong driver for the pinnacle systems remote, which
needs
just standard access to the serial port?
Anyway, the only way I can get this to work is to manually create a symlink in
/dev/lirc/
pointing back to the actual COM port I'm connected to and by using the serial vs.
lirc_serial HWMOD.
Thanks.
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: UNCONFIRMED
creation_date:
description:
I have a pinnacle systems dumb IR receiver which connects to the COM1 / COM2 serial
port.
The example /etc/sysconfig/lircd file gives the user no indication that they need to
create a
symlink between the actual tty device and the /dev/lirc entry.
Here's a working example:
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=pinsys
# Hardware driver module to load
HWMOD=serial
# The device node that communicates with the IR device.
# with devfs enabled
DEVICE=/dev/lirc/1
snip
[EMAIL PROTECTED] dev]# ls -l /dev/lirc/1
lr-xr-xr-x1 root root 10 Mar 15 21:48 /dev/lirc/1 - /dev/ttyS1
It took me about 2 hours to figure this out. I recommend that the lircd file be a
little more
verbose with examples.
Here is an updated /etc/sysconfig/lircd file that I think explains things better.
(Note that the symlink is created correctly when manually installing lirc from a
tarball because
the lirc configure program does this as a part of the installation process)
[EMAIL PROTECTED] sysconfig]# cat lircd
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=UNCONFIGURED
# Hardware driver module to load
# Choices are:
# serial
# lirc_serial (for home-brew serial port IR receivers)
# lirc_parallel
# etc. See /lib/modules/{kern-version}/kernel/3rdparty/lirc for a
# list of modules.
HWMOD=UNCONFIGURED
# The device node that communicates with the IR device.
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc/ entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc/0
# or as root# ln -sf ttyS0 lirc/serial
# If you are using devfs, use one of the following and create the symlink
# as shown above
# DEVICE=/dev/lirc/0
# DEVICE=/dev/lirc/serial
# Without devfs:
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc
# DEVICE=/dev/lirc
# Serial port for the receiver (for serial driver)
# COM1 (/dev/ttyS0)
#COM_PORT=/dev/ttyS0
#DRIVER_OPTS=irq=4 io=0x3f8
# COM2 (/dev/ttyS1)
#COM_PORT=/dev/ttyS1
#DRIVER_OPTS=irq=3 io=0x2f8
# COM3 (/dev/ttyS2)
#COM_PORT=/dev/ttyS2
#DRIVER_OPTS=irq=4 io=0x3e8
# COM4 (/dev/ttyS3)
#COM_PORT=/dev/ttyS3
#DRIVER_OPTS=irq=3 io=0x2e8
[Cooker] [Bug 3356] [drakxtools-newt] Can not upgrade due to file collision with msec
http://qa.mandrakesoft.com/show_bug.cgi?id=3356 [EMAIL PROTECTED] changed: What|Removed |Added Version|9.1-25mdk |9.1-26mdk --- Additional Comments From [EMAIL PROTECTED] 2003-03-17 22:31 --- Still exists on -26 Installation failed: file /usr/lib/libDrakX/security/help.pm from install of drakxtools-newt-9.1-26mdk conflicts with file from package msec-0.38-1mdk --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Installation failed: file /usr/lib/libDrakX/security/help.pm from install of drakxtools-newt-9.1-25mdk conflicts with file from package msec-0.38-1mdk
[Cooker] [Bug 3358] [lirc] lirc not correctly creating symlinks for serial devices
http://qa.mandrakesoft.com/show_bug.cgi?id=3358
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Additional Comments From [EMAIL PROTECTED] 2003-03-17 23:42 ---
I'm sorry, how is the fact that I need to manually create the symlink not a bug?
1) The pinnacle PCTV remote does not use lirc_serial
2) If I use HWMOD=serial, then no device gets created in /dev/lirc/, and I must
manually
create the symlink from /dev/ttySx to /dev/lirc/serial, otherwise lircd immediately
errors out
when the readlink call fails.
However, I'm not the packager, and you really feel that this isn't a bug, then I
certainly can't
force the issue. If you feel that this isn't a bug, then what is your recommended
solution to my
problem? Remember, when compiled from source, the lirc install routine _does_ create
a
symlink pointing to the device that you said the pinnacle receiver was on, ie ttyS0,
ttyS1, etc.
Thomas: the serial ports default to the status recommened when you compile from
source.
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: UNCONFIRMED
creation_date:
description:
I have a pinnacle systems dumb IR receiver which connects to the COM1 / COM2 serial
port.
The example /etc/sysconfig/lircd file gives the user no indication that they need to
create a
symlink between the actual tty device and the /dev/lirc entry.
Here's a working example:
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=pinsys
# Hardware driver module to load
HWMOD=serial
# The device node that communicates with the IR device.
# with devfs enabled
DEVICE=/dev/lirc/1
snip
[EMAIL PROTECTED] dev]# ls -l /dev/lirc/1
lr-xr-xr-x1 root root 10 Mar 15 21:48 /dev/lirc/1 - /dev/ttyS1
It took me about 2 hours to figure this out. I recommend that the lircd file be a
little more
verbose with examples.
Here is an updated /etc/sysconfig/lircd file that I think explains things better.
(Note that the symlink is created correctly when manually installing lirc from a
tarball because
the lirc configure program does this as a part of the installation process)
[EMAIL PROTECTED] sysconfig]# cat lircd
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=UNCONFIGURED
# Hardware driver module to load
# Choices are:
# serial
# lirc_serial (for home-brew serial port IR receivers)
# lirc_parallel
# etc. See /lib/modules/{kern-version}/kernel/3rdparty/lirc for a
# list of modules.
HWMOD=UNCONFIGURED
# The device node that communicates with the IR device.
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc/ entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc/0
# or as root# ln -sf ttyS0 lirc/serial
# If you are using devfs, use one of the following and create the symlink
# as shown above
# DEVICE=/dev/lirc/0
# DEVICE=/dev/lirc/serial
# Without devfs:
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc
# DEVICE=/dev/lirc
# Serial port for the receiver (for serial driver)
# COM1 (/dev/ttyS0)
#COM_PORT=/dev/ttyS0
#DRIVER_OPTS=irq=4 io=0x3f8
# COM2 (/dev/ttyS1)
#COM_PORT=/dev/ttyS1
#DRIVER_OPTS=irq=3 io=0x2f8
# COM3 (/dev/ttyS2)
#COM_PORT=/dev/ttyS2
#DRIVER_OPTS=irq=4 io=0x3e8
# COM4 (/dev/ttyS3)
#COM_PORT=/dev/ttyS3
#DRIVER_OPTS=irq=3 io=0x2e8
[Cooker] [Bug 1628] [KDE] PATH for autologin not login shell PATH
http://qa.mandrakesoft.com/show_bug.cgi?id=1628 --- Additional Comments From [EMAIL PROTECTED] 2003-03-15 17:45 --- Concur; 9.1B2 upgraded with cooker versions of kdebase -83 version still exhibits this bug. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: I expect that the PATH for a non-root user should be the same whether she gets to the desktop via autologin or via a login window. This appears not to be the case. Path upon autologin to desktop: /usr/X11R6/bin:/usr/local/bin:/bin:/usr/bin Path after loging out of desktop and back in: /usr//bin:/bin:/usr/bin::/usr/local/bin:/usr/X11R6/bin:/usr/games:/home/craig/bin: Path after logging into a pseudoterminal: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/home/craig/bin: Note the peculiar /usr//bin: entry in the second situation above.
[Cooker] [Bug 3356] [drakxtools-newt] New: Can not upgrade due to file collision with msec
http://qa.mandrakesoft.com/show_bug.cgi?id=3356 Product: drakxtools-newt Component: packaging Summary: Can not upgrade due to file collision with msec Version: 9.1-25mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Installation failed: file /usr/lib/libDrakX/security/help.pm from install of drakxtools-newt-9.1-25mdk conflicts with file from package msec-0.38-1mdk --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3358] [lirc] New: lirc not correctly creating symlinks for serial devices
http://qa.mandrakesoft.com/show_bug.cgi?id=3358
Product: lirc
Component: documentation
Summary: lirc not correctly creating symlinks for serial devices
Version: 0.6.6-1mdk
Platform: PC
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I have a pinnacle systems dumb IR receiver which connects to the COM1 / COM2 serial
port.
The example /etc/sysconfig/lircd file gives the user no indication that they need to
create a
symlink between the actual tty device and the /dev/lirc entry.
Here's a working example:
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=pinsys
# Hardware driver module to load
HWMOD=serial
# The device node that communicates with the IR device.
# with devfs enabled
DEVICE=/dev/lirc/1
snip
[EMAIL PROTECTED] dev]# ls -l /dev/lirc/1
lr-xr-xr-x1 root root 10 Mar 15 21:48 /dev/lirc/1 - /dev/ttyS1
It took me about 2 hours to figure this out. I recommend that the lircd file be a
little more
verbose with examples.
Here is an updated /etc/sysconfig/lircd file that I think explains things better.
(Note that the symlink is created correctly when manually installing lirc from a
tarball because
the lirc configure program does this as a part of the installation process)
[EMAIL PROTECTED] sysconfig]# cat lircd
# Customized setings for lirc daemon
# The hardware driver to use, run lircd --driver=? for a list
DRIVER=UNCONFIGURED
# Hardware driver module to load
# Choices are:
# serial
# lirc_serial (for home-brew serial port IR receivers)
# lirc_parallel
# etc. See /lib/modules/{kern-version}/kernel/3rdparty/lirc for a
# list of modules.
HWMOD=UNCONFIGURED
# The device node that communicates with the IR device.
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc/ entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc/0
# or as root# ln -sf ttyS0 lirc/serial
# If you are using devfs, use one of the following and create the symlink
# as shown above
# DEVICE=/dev/lirc/0
# DEVICE=/dev/lirc/serial
# Without devfs:
# If you are using a serial device, create a symlink between the actual
# hardware device and the /dev/lirc entry
# Example for receiver connected to COM1
# as root# cd /dev
# as root# ln -sf ttyS0 lirc
# DEVICE=/dev/lirc
# Serial port for the receiver (for serial driver)
# COM1 (/dev/ttyS0)
#COM_PORT=/dev/ttyS0
#DRIVER_OPTS=irq=4 io=0x3f8
# COM2 (/dev/ttyS1)
#COM_PORT=/dev/ttyS1
#DRIVER_OPTS=irq=3 io=0x2f8
# COM3 (/dev/ttyS2)
#COM_PORT=/dev/ttyS2
#DRIVER_OPTS=irq=4 io=0x3e8
# COM4 (/dev/ttyS3)
#COM_PORT=/dev/ttyS3
#DRIVER_OPTS=irq=3 io=0x2e8
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3361] [lirc-remotes] New: lirc-remotes v0.6.5 not the most current set of remotes available
http://qa.mandrakesoft.com/show_bug.cgi?id=3361 Product: lirc-remotes Component: program Summary: lirc-remotes v0.6.5 not the most current set of remotes available Version: 0.6.5-1mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] the remotes.tar.bz2 file on http://www.lirc.org has remotes as recent as 2003-02-03. The packaged lirc-remotes file is very out of date. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 1628] [KDE] PATH for autologin not login shell PATH
https://qa.mandrakesoft.com/show_bug.cgi?id=1628 --- Additional Comments From [EMAIL PROTECTED] 2003-02-21 19:11 --- I also see this bug under Cooker, 9.1Beta3 SSH: Path is OK. Login at TTY: Path is OK. Konsole: (BASH): Path is not OK. This bug has also been noted on MandrakeExpert for ML9.0 http://www.mandrakeexpert.com/showarchive.php?arc=51472 Is a script in /etc/rc.d/init.d munging the path? --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: I expect that the PATH for a non-root user should be the same whether she gets to the desktop via autologin or via a login window. This appears not to be the case. Path upon autologin to desktop: /usr/X11R6/bin:/usr/local/bin:/bin:/usr/bin Path after loging out of desktop and back in: /usr//bin:/bin:/usr/bin::/usr/local/bin:/usr/X11R6/bin:/usr/games:/home/craig/bin: Path after logging into a pseudoterminal: /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/home/craig/bin: Note the peculiar /usr//bin: entry in the second situation above.
