Menu
▾
▴
tilp-devel — This list is intended to TiLP's developers, contributors and advanced users.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2003 |
Jan
(25) |
Feb
(5) |
Mar
(12) |
Apr
(46) |
May
(47) |
Jun
|
Jul
(2) |
Aug
|
Sep
(15) |
Oct
(8) |
Nov
(11) |
Dec
|
| 2004 |
Jan
(25) |
Feb
(24) |
Mar
(13) |
Apr
(59) |
May
(52) |
Jun
(6) |
Jul
(3) |
Aug
(7) |
Sep
(33) |
Oct
(17) |
Nov
(16) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(5) |
May
(50) |
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(7) |
Oct
(1) |
Nov
(2) |
Dec
(9) |
| 2006 |
Jan
(10) |
Feb
(6) |
Mar
(2) |
Apr
(24) |
May
(32) |
Jun
(53) |
Jul
(26) |
Aug
(28) |
Sep
(59) |
Oct
(72) |
Nov
(85) |
Dec
(57) |
| 2007 |
Jan
(43) |
Feb
(26) |
Mar
(25) |
Apr
(36) |
May
(13) |
Jun
(14) |
Jul
(53) |
Aug
(68) |
Sep
(46) |
Oct
(62) |
Nov
(15) |
Dec
(4) |
| 2008 |
Jan
(4) |
Feb
(5) |
Mar
(7) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(5) |
Nov
|
Dec
(3) |
| 2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2007-10-15 11:17:59
|
Bugs item #1808645, was opened at 2007-10-06 16:17 Message generated for change (Comment added) made by roms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: Accepted Priority: 5 Private: No Submitted By: rpdrum (rpdrum) Assigned to: Romain Liévin (roms) Summary: Backup - Connection Resets Initial Comment: I have a Voyage 200 connected via the "silver" usb cable. I am running TILP2 V1.07 under Linux (Fedora Core 7). From info screen: Framework version (cables=1.0.9, files=1.0.7, calcs=1.0.7, conv=1.0.4) When using the backup function it gets to a large flash application, and when the transfer of this file appears to be complete, sometimes I get a popup window saying the connection is being reset, then (regardless of whether I get the "reset" message) I get a popup window with the following message: Msg: timeout occured while reading to the device. Cause: check that link cable is plugged and/or the calculator is ready. System: Resource temporarily unavailable (errno = 11) At that point, the backup is failed. Where this problem occurs does not appear to have any consistency. It *usually* occurs on the first larger file transfer, but sometimes I actually get to the second larger flash app before getting these results. I have also had it occur on a rom dump. I have checked the log messages and don't find anything unusual there when this occurs. I have attached a gzipped file with the tilp output in it. If I can provide anything else, let me know. I really like this program and would like to get it working reliably for my setup. Thanks. ---------------------------------------------------------------------- >Comment By: Romain Liévin (roms) Date: 2007-10-15 13:18 Message: Logged In: YES user_id=136160 Originator: NO I received it! Thanks. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-14 21:15 Message: Logged In: YES user_id=136160 Originator: NO >Would sending a copy of the ti group backup using ti-connect help? Yep, a lot! Please send it directly to <roms AT tilp DOT info>. ---------------------------------------------------------------------- Comment By: rpdrum (rpdrum) Date: 2007-10-14 19:25 Message: Logged In: YES user_id=1907033 Originator: YES I am using the calcforge repos. and got the new updates installed. Tried to backup, sorry, I still get the timeout on backup:( Would sending a copy of the ti group backup using ti-connect help? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 09:06 Message: Logged In: YES user_id=573515 Originator: NO libticalcs2-1.0.8-2 is now up at http://repo.calcforge.org/fedora/ . Please try the update and report whether it fixes your issue. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 05:30 Message: Logged In: YES user_id=573515 Originator: NO Oh, and it's called Fedora 7, not Fedora Core 7. ;-) The last "Core" was FC6. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 05:27 Message: Logged In: YES user_id=573515 Originator: NO An updated RPM which should fix this (libticalcs2-1.0.8-2, which has Romain's fix backported) is going to hit the CalcForge RPM repository in a few hours. I'll tell you when it's up. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-14 04:46 Message: Logged In: YES user_id=136160 Originator: NO Another way to help me: backup your hand-held with Ti-Connect and send the TiGroup file backup to <roms AT tilp DOT info>. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-13 22:21 Message: Logged In: YES user_id=136160 Originator: NO Did you install TiLP from source or package? Would you be able to run a test for me? If yes, open ticalcs2/src/backup.c, look for ticalcs_calc_recv_tigroup and next, look for TRYF(handle->calc->is_ready(handle)). Simply add 'PAUSE(250);' just before and just after this line. Install the library again, re-run TiLP and take me up to date... Thanks, Romain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 |
|
From: Darrald S. <Dar...@er...> - 2007-10-15 01:42:07
|
WATCH KGLJ TRADE ON MONDAY OCTOBER 15, 2007 WE ARE 100% CONFIDENT THAT THIS ONE WILL BE THE RUNNER OF THE YEAR! Name: Kingslake Energy, Inc. Symbol: KGLJ Price: $1.51 5-D Target: $4 Rating: Agressive Buy ADD KGLJ TO YOUR RADAR ON MONDAY OCTOBER 15! RIDE THE WAVE LIKE A SURFER! END UP ON TOP! DON'T LET KGLJ PASS YOU BY! DISCLAIMER: This is not an offer to buy or sell any security. ASA Press = discloses that they were paid ten thousand dollars for distribution of = this report. This report contains forward-lqqking statements. Please do due diligence = before investing in any company. Best of luck to you in the markets this = morning! |
|
From: SourceForge.net <no...@so...> - 2007-10-14 19:15:12
|
Bugs item #1808645, was opened at 2007-10-06 16:17 Message generated for change (Comment added) made by roms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: rpdrum (rpdrum) Assigned to: Romain Liévin (roms) Summary: Backup - Connection Resets Initial Comment: I have a Voyage 200 connected via the "silver" usb cable. I am running TILP2 V1.07 under Linux (Fedora Core 7). From info screen: Framework version (cables=1.0.9, files=1.0.7, calcs=1.0.7, conv=1.0.4) When using the backup function it gets to a large flash application, and when the transfer of this file appears to be complete, sometimes I get a popup window saying the connection is being reset, then (regardless of whether I get the "reset" message) I get a popup window with the following message: Msg: timeout occured while reading to the device. Cause: check that link cable is plugged and/or the calculator is ready. System: Resource temporarily unavailable (errno = 11) At that point, the backup is failed. Where this problem occurs does not appear to have any consistency. It *usually* occurs on the first larger file transfer, but sometimes I actually get to the second larger flash app before getting these results. I have also had it occur on a rom dump. I have checked the log messages and don't find anything unusual there when this occurs. I have attached a gzipped file with the tilp output in it. If I can provide anything else, let me know. I really like this program and would like to get it working reliably for my setup. Thanks. ---------------------------------------------------------------------- >Comment By: Romain Liévin (roms) Date: 2007-10-14 21:15 Message: Logged In: YES user_id=136160 Originator: NO >Would sending a copy of the ti group backup using ti-connect help? Yep, a lot! Please send it directly to <roms AT tilp DOT info>. ---------------------------------------------------------------------- Comment By: rpdrum (rpdrum) Date: 2007-10-14 19:25 Message: Logged In: YES user_id=1907033 Originator: YES I am using the calcforge repos. and got the new updates installed. Tried to backup, sorry, I still get the timeout on backup:( Would sending a copy of the ti group backup using ti-connect help? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 09:06 Message: Logged In: YES user_id=573515 Originator: NO libticalcs2-1.0.8-2 is now up at http://repo.calcforge.org/fedora/ . Please try the update and report whether it fixes your issue. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 05:30 Message: Logged In: YES user_id=573515 Originator: NO Oh, and it's called Fedora 7, not Fedora Core 7. ;-) The last "Core" was FC6. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 05:27 Message: Logged In: YES user_id=573515 Originator: NO An updated RPM which should fix this (libticalcs2-1.0.8-2, which has Romain's fix backported) is going to hit the CalcForge RPM repository in a few hours. I'll tell you when it's up. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-14 04:46 Message: Logged In: YES user_id=136160 Originator: NO Another way to help me: backup your hand-held with Ti-Connect and send the TiGroup file backup to <roms AT tilp DOT info>. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-13 22:21 Message: Logged In: YES user_id=136160 Originator: NO Did you install TiLP from source or package? Would you be able to run a test for me? If yes, open ticalcs2/src/backup.c, look for ticalcs_calc_recv_tigroup and next, look for TRYF(handle->calc->is_ready(handle)). Simply add 'PAUSE(250);' just before and just after this line. Install the library again, re-run TiLP and take me up to date... Thanks, Romain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-14 17:26:00
|
Bugs item #1808645, was opened at 2007-10-06 09:17 Message generated for change (Comment added) made by rpdrum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: rpdrum (rpdrum) Assigned to: Romain Liévin (roms) Summary: Backup - Connection Resets Initial Comment: I have a Voyage 200 connected via the "silver" usb cable. I am running TILP2 V1.07 under Linux (Fedora Core 7). From info screen: Framework version (cables=1.0.9, files=1.0.7, calcs=1.0.7, conv=1.0.4) When using the backup function it gets to a large flash application, and when the transfer of this file appears to be complete, sometimes I get a popup window saying the connection is being reset, then (regardless of whether I get the "reset" message) I get a popup window with the following message: Msg: timeout occured while reading to the device. Cause: check that link cable is plugged and/or the calculator is ready. System: Resource temporarily unavailable (errno = 11) At that point, the backup is failed. Where this problem occurs does not appear to have any consistency. It *usually* occurs on the first larger file transfer, but sometimes I actually get to the second larger flash app before getting these results. I have also had it occur on a rom dump. I have checked the log messages and don't find anything unusual there when this occurs. I have attached a gzipped file with the tilp output in it. If I can provide anything else, let me know. I really like this program and would like to get it working reliably for my setup. Thanks. ---------------------------------------------------------------------- >Comment By: rpdrum (rpdrum) Date: 2007-10-14 12:25 Message: Logged In: YES user_id=1907033 Originator: YES I am using the calcforge repos. and got the new updates installed. Tried to backup, sorry, I still get the timeout on backup:( Would sending a copy of the ti group backup using ti-connect help? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 02:06 Message: Logged In: YES user_id=573515 Originator: NO libticalcs2-1.0.8-2 is now up at http://repo.calcforge.org/fedora/ . Please try the update and report whether it fixes your issue. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 22:30 Message: Logged In: YES user_id=573515 Originator: NO Oh, and it's called Fedora 7, not Fedora Core 7. ;-) The last "Core" was FC6. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 22:27 Message: Logged In: YES user_id=573515 Originator: NO An updated RPM which should fix this (libticalcs2-1.0.8-2, which has Romain's fix backported) is going to hit the CalcForge RPM repository in a few hours. I'll tell you when it's up. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-13 21:46 Message: Logged In: YES user_id=136160 Originator: NO Another way to help me: backup your hand-held with Ti-Connect and send the TiGroup file backup to <roms AT tilp DOT info>. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-13 15:21 Message: Logged In: YES user_id=136160 Originator: NO Did you install TiLP from source or package? Would you be able to run a test for me? If yes, open ticalcs2/src/backup.c, look for ticalcs_calc_recv_tigroup and next, look for TRYF(handle->calc->is_ready(handle)). Simply add 'PAUSE(250);' just before and just after this line. Install the library again, re-run TiLP and take me up to date... Thanks, Romain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-14 16:47:14
|
Bugs item #1717903, was opened at 2007-05-12 22:45 Message generated for change (Comment added) made by roms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1717903&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: Accepted Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Romain Liévin (roms) Summary: Weird Variable Names Initial Comment: Whenever you try to receive Pics stored with xLIB or ZSTO that are beyond Pic0, instead of Pic14 or Pic52, it gives it something weird like PicÈ or something, and it sometimes it says there are more than one of the same variable on the calc even though they're two completely different ones. The same thing also happens with strings and matrices over 10. ---------------------------------------------------------------------- >Comment By: Romain Liévin (roms) Date: 2007-10-14 18:47 Message: Logged In: YES user_id=136160 Originator: NO I really want to fix this bug but I have to get an answer. Otherwise, bug will be closed automatically in 15 days. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 15:07 Message: Logged In: YES user_id=136160 Originator: NO Could you send to me your variables so that I can take a look? Screenshots should be welcome, too. Mail at: <roms AT tilp DOT info>. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1717903&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-14 07:06:18
|
Bugs item #1808645, was opened at 2007-10-06 16:17 Message generated for change (Comment added) made by kevinkofler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Pending Resolution: Accepted Priority: 5 Private: No Submitted By: rpdrum (rpdrum) Assigned to: Romain Liévin (roms) Summary: Backup - Connection Resets Initial Comment: I have a Voyage 200 connected via the "silver" usb cable. I am running TILP2 V1.07 under Linux (Fedora Core 7). From info screen: Framework version (cables=1.0.9, files=1.0.7, calcs=1.0.7, conv=1.0.4) When using the backup function it gets to a large flash application, and when the transfer of this file appears to be complete, sometimes I get a popup window saying the connection is being reset, then (regardless of whether I get the "reset" message) I get a popup window with the following message: Msg: timeout occured while reading to the device. Cause: check that link cable is plugged and/or the calculator is ready. System: Resource temporarily unavailable (errno = 11) At that point, the backup is failed. Where this problem occurs does not appear to have any consistency. It *usually* occurs on the first larger file transfer, but sometimes I actually get to the second larger flash app before getting these results. I have also had it occur on a rom dump. I have checked the log messages and don't find anything unusual there when this occurs. I have attached a gzipped file with the tilp output in it. If I can provide anything else, let me know. I really like this program and would like to get it working reliably for my setup. Thanks. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 09:06 Message: Logged In: YES user_id=573515 Originator: NO libticalcs2-1.0.8-2 is now up at http://repo.calcforge.org/fedora/ . Please try the update and report whether it fixes your issue. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 05:30 Message: Logged In: YES user_id=573515 Originator: NO Oh, and it's called Fedora 7, not Fedora Core 7. ;-) The last "Core" was FC6. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 05:27 Message: Logged In: YES user_id=573515 Originator: NO An updated RPM which should fix this (libticalcs2-1.0.8-2, which has Romain's fix backported) is going to hit the CalcForge RPM repository in a few hours. I'll tell you when it's up. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-14 04:46 Message: Logged In: YES user_id=136160 Originator: NO Another way to help me: backup your hand-held with Ti-Connect and send the TiGroup file backup to <roms AT tilp DOT info>. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-13 22:21 Message: Logged In: YES user_id=136160 Originator: NO Did you install TiLP from source or package? Would you be able to run a test for me? If yes, open ticalcs2/src/backup.c, look for ticalcs_calc_recv_tigroup and next, look for TRYF(handle->calc->is_ready(handle)). Simply add 'PAUSE(250);' just before and just after this line. Install the library again, re-run TiLP and take me up to date... Thanks, Romain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-14 03:30:25
|
Bugs item #1808645, was opened at 2007-10-06 16:17 Message generated for change (Comment added) made by kevinkofler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Pending Resolution: Accepted Priority: 5 Private: No Submitted By: rpdrum (rpdrum) Assigned to: Romain Liévin (roms) Summary: Backup - Connection Resets Initial Comment: I have a Voyage 200 connected via the "silver" usb cable. I am running TILP2 V1.07 under Linux (Fedora Core 7). From info screen: Framework version (cables=1.0.9, files=1.0.7, calcs=1.0.7, conv=1.0.4) When using the backup function it gets to a large flash application, and when the transfer of this file appears to be complete, sometimes I get a popup window saying the connection is being reset, then (regardless of whether I get the "reset" message) I get a popup window with the following message: Msg: timeout occured while reading to the device. Cause: check that link cable is plugged and/or the calculator is ready. System: Resource temporarily unavailable (errno = 11) At that point, the backup is failed. Where this problem occurs does not appear to have any consistency. It *usually* occurs on the first larger file transfer, but sometimes I actually get to the second larger flash app before getting these results. I have also had it occur on a rom dump. I have checked the log messages and don't find anything unusual there when this occurs. I have attached a gzipped file with the tilp output in it. If I can provide anything else, let me know. I really like this program and would like to get it working reliably for my setup. Thanks. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 05:30 Message: Logged In: YES user_id=573515 Originator: NO Oh, and it's called Fedora 7, not Fedora Core 7. ;-) The last "Core" was FC6. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 05:27 Message: Logged In: YES user_id=573515 Originator: NO An updated RPM which should fix this (libticalcs2-1.0.8-2, which has Romain's fix backported) is going to hit the CalcForge RPM repository in a few hours. I'll tell you when it's up. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-14 04:46 Message: Logged In: YES user_id=136160 Originator: NO Another way to help me: backup your hand-held with Ti-Connect and send the TiGroup file backup to <roms AT tilp DOT info>. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-13 22:21 Message: Logged In: YES user_id=136160 Originator: NO Did you install TiLP from source or package? Would you be able to run a test for me? If yes, open ticalcs2/src/backup.c, look for ticalcs_calc_recv_tigroup and next, look for TRYF(handle->calc->is_ready(handle)). Simply add 'PAUSE(250);' just before and just after this line. Install the library again, re-run TiLP and take me up to date... Thanks, Romain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-14 03:27:22
|
Bugs item #1808645, was opened at 2007-10-06 16:17 Message generated for change (Comment added) made by kevinkofler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Pending Resolution: Accepted Priority: 5 Private: No Submitted By: rpdrum (rpdrum) Assigned to: Romain Liévin (roms) Summary: Backup - Connection Resets Initial Comment: I have a Voyage 200 connected via the "silver" usb cable. I am running TILP2 V1.07 under Linux (Fedora Core 7). From info screen: Framework version (cables=1.0.9, files=1.0.7, calcs=1.0.7, conv=1.0.4) When using the backup function it gets to a large flash application, and when the transfer of this file appears to be complete, sometimes I get a popup window saying the connection is being reset, then (regardless of whether I get the "reset" message) I get a popup window with the following message: Msg: timeout occured while reading to the device. Cause: check that link cable is plugged and/or the calculator is ready. System: Resource temporarily unavailable (errno = 11) At that point, the backup is failed. Where this problem occurs does not appear to have any consistency. It *usually* occurs on the first larger file transfer, but sometimes I actually get to the second larger flash app before getting these results. I have also had it occur on a rom dump. I have checked the log messages and don't find anything unusual there when this occurs. I have attached a gzipped file with the tilp output in it. If I can provide anything else, let me know. I really like this program and would like to get it working reliably for my setup. Thanks. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 05:27 Message: Logged In: YES user_id=573515 Originator: NO An updated RPM which should fix this (libticalcs2-1.0.8-2, which has Romain's fix backported) is going to hit the CalcForge RPM repository in a few hours. I'll tell you when it's up. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-14 04:46 Message: Logged In: YES user_id=136160 Originator: NO Another way to help me: backup your hand-held with Ti-Connect and send the TiGroup file backup to <roms AT tilp DOT info>. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-13 22:21 Message: Logged In: YES user_id=136160 Originator: NO Did you install TiLP from source or package? Would you be able to run a test for me? If yes, open ticalcs2/src/backup.c, look for ticalcs_calc_recv_tigroup and next, look for TRYF(handle->calc->is_ready(handle)). Simply add 'PAUSE(250);' just before and just after this line. Install the library again, re-run TiLP and take me up to date... Thanks, Romain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-14 03:04:36
|
Bugs item #1731776, was opened at 2007-06-06 03:50 Message generated for change (Comment added) made by kevinkofler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Ross Kendall Axe (rossaxe) Assigned to: Romain Liévin (roms) Summary: Bad permissions check on /dev/ttySx Initial Comment: TiLP produces the following output in the terminal window when attempting to open a serial link: ticables-INFO: Check for tty usability: ticables-INFO: node /dev/ttyS0: exists ticables-INFO: permissions/user/group: -rw-rw---- root users ticables-INFO: is user can r/w on device: no ticables-INFO: are others can r/w on device: no ticables-INFO: is the user 'ross' in the group 'users': no ticables-INFO: => you should add your username at the group 'users' in '/etc/group' ticables-INFO: => you will have to restart you session, too However, 'id ross' clearly indicates that I'm in the users group, in case I didn't already know that ;-) $ id ross uid=1004(ross) gid=100(users) groups=100(users),11(floppy),17(audio),18(video),19(cdrom),93(scanner) Any attempt to use the link therefore fails since it never got initialised. As to why it failed to notice that I have access, well, I'm not sure. It could be that it's because it's my primary group, or because my passwd entry is accessed via nss_ldap. I imagine it would also fail if I was using ACLs. It seems to be that TiLP ought to simply use open("/dev/ttySx", O_RDWR) to check access rather than trying to be too clever and attempting to second guess the kernel's access rules. Meanwhile, 'chmod 0666 /dev/ttyS?' is a suitable workaround for this problem :-) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 05:04 Message: Logged In: YES user_id=573515 Originator: NO Revision 3906 tested successfully (both in a situation with permissions and in one without). ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 04:57 Message: Logged In: YES user_id=573515 Originator: NO Oops, that if(access(pathname, R_OK | W_OK)) should have been if(!access(pathname, R_OK | W_OK)), I fixed that: http://svn.tilp.info/cgi-bin/viewcvs.cgi?rev=3905&view=rev ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-14 04:40 Message: Logged In: YES user_id=136160 Originator: NO Patch merged. Thanks, Kevin. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:28 Message: Logged In: YES user_id=573515 Originator: NO Fixed patch (no need to check for group membership if the user has access, we can go directly to the "unknown reason" conclusion): Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,24 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +276,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +287,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:23 Message: Logged In: YES user_id=573515 Originator: NO > It does seem to me that if the program is not SUID, then no extra checks > are needed beyond what the kernel does anyway when calling open(), and if > it is then it should just drop privileges before it calls open(). Running TiLP SUID is no longer supported (there's better ways to get access rights to devices these days), but even when it was, the entire purpose of doing that was to be able to access more devices than otherwise. > But then again, I don't know what the reason for this extra check is so > perhaps this is too simple minded. It's to help debugging. I think the right solution is to: * use access() to check if the device can be accessed, * only if this fails, do the other checks to help debugging. I'd suggest this patch: Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,22 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +274,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +285,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) Romain, can I commit this one? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-10-13 20:30 Message: Logged In: YES user_id=1206088 Originator: YES Well, I'm glad I'm not the only one who thinks so :-) It does seem to me that if the program is not SUID, then no extra checks are needed beyond what the kernel does anyway when calling open(), and if it is then it should just drop privileges before it calls open(). But then again, I don't know what the reason for this extra check is so perhaps this is too simple minded. nss_ldap, ACLs, maybe SELinux? Either these things (and god only knows what else) have to supported explicitly, or libticables should just trust that the kernel knows best? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 08:47 Message: Logged In: YES user_id=573515 Originator: NO How's that "fixed"? He just worked around it. We really really need to fix libticables2 not to do those weird access checks, also because newer Fedora (and probably many other distros soon, because granting access to console users is now going to be done with ConsoleKit and HAL rather than the RH-specific pam_console) is going to always use ACLs to grant access to devices, so your ACL-unaware hacks aren't going to work anymore. ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-09 15:10 Message: Logged In: YES user_id=1206088 Originator: YES Yes, it's OK now with the the modification to /etc/group. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-05 08:50 Message: Logged In: YES user_id=136160 Originator: NO So, is TiLP working now? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-05 00:46 Message: Logged In: YES user_id=1206088 Originator: YES Yeah, putting my username into /etc/group does also work around the problem. My username wasn't in 'group' on the LDAP server either though, only in 'passwd' (where my GID is set to the GID of the users group, of course). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 14:58 Message: Logged In: YES user_id=136160 Originator: NO ticables2 library is parsing /etc/group for entries. Is your username in the same line as the 'users' line in this file? nss_ldap access may explain your problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-14 02:57:36
|
Bugs item #1731776, was opened at 2007-06-06 03:50 Message generated for change (Comment added) made by kevinkofler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Ross Kendall Axe (rossaxe) Assigned to: Romain Liévin (roms) Summary: Bad permissions check on /dev/ttySx Initial Comment: TiLP produces the following output in the terminal window when attempting to open a serial link: ticables-INFO: Check for tty usability: ticables-INFO: node /dev/ttyS0: exists ticables-INFO: permissions/user/group: -rw-rw---- root users ticables-INFO: is user can r/w on device: no ticables-INFO: are others can r/w on device: no ticables-INFO: is the user 'ross' in the group 'users': no ticables-INFO: => you should add your username at the group 'users' in '/etc/group' ticables-INFO: => you will have to restart you session, too However, 'id ross' clearly indicates that I'm in the users group, in case I didn't already know that ;-) $ id ross uid=1004(ross) gid=100(users) groups=100(users),11(floppy),17(audio),18(video),19(cdrom),93(scanner) Any attempt to use the link therefore fails since it never got initialised. As to why it failed to notice that I have access, well, I'm not sure. It could be that it's because it's my primary group, or because my passwd entry is accessed via nss_ldap. I imagine it would also fail if I was using ACLs. It seems to be that TiLP ought to simply use open("/dev/ttySx", O_RDWR) to check access rather than trying to be too clever and attempting to second guess the kernel's access rules. Meanwhile, 'chmod 0666 /dev/ttyS?' is a suitable workaround for this problem :-) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-14 04:57 Message: Logged In: YES user_id=573515 Originator: NO Oops, that if(access(pathname, R_OK | W_OK)) should have been if(!access(pathname, R_OK | W_OK)), I fixed that: http://svn.tilp.info/cgi-bin/viewcvs.cgi?rev=3905&view=rev ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-14 04:40 Message: Logged In: YES user_id=136160 Originator: NO Patch merged. Thanks, Kevin. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:28 Message: Logged In: YES user_id=573515 Originator: NO Fixed patch (no need to check for group membership if the user has access, we can go directly to the "unknown reason" conclusion): Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,24 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +276,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +287,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:23 Message: Logged In: YES user_id=573515 Originator: NO > It does seem to me that if the program is not SUID, then no extra checks > are needed beyond what the kernel does anyway when calling open(), and if > it is then it should just drop privileges before it calls open(). Running TiLP SUID is no longer supported (there's better ways to get access rights to devices these days), but even when it was, the entire purpose of doing that was to be able to access more devices than otherwise. > But then again, I don't know what the reason for this extra check is so > perhaps this is too simple minded. It's to help debugging. I think the right solution is to: * use access() to check if the device can be accessed, * only if this fails, do the other checks to help debugging. I'd suggest this patch: Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,22 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +274,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +285,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) Romain, can I commit this one? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-10-13 20:30 Message: Logged In: YES user_id=1206088 Originator: YES Well, I'm glad I'm not the only one who thinks so :-) It does seem to me that if the program is not SUID, then no extra checks are needed beyond what the kernel does anyway when calling open(), and if it is then it should just drop privileges before it calls open(). But then again, I don't know what the reason for this extra check is so perhaps this is too simple minded. nss_ldap, ACLs, maybe SELinux? Either these things (and god only knows what else) have to supported explicitly, or libticables should just trust that the kernel knows best? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 08:47 Message: Logged In: YES user_id=573515 Originator: NO How's that "fixed"? He just worked around it. We really really need to fix libticables2 not to do those weird access checks, also because newer Fedora (and probably many other distros soon, because granting access to console users is now going to be done with ConsoleKit and HAL rather than the RH-specific pam_console) is going to always use ACLs to grant access to devices, so your ACL-unaware hacks aren't going to work anymore. ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-09 15:10 Message: Logged In: YES user_id=1206088 Originator: YES Yes, it's OK now with the the modification to /etc/group. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-05 08:50 Message: Logged In: YES user_id=136160 Originator: NO So, is TiLP working now? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-05 00:46 Message: Logged In: YES user_id=1206088 Originator: YES Yeah, putting my username into /etc/group does also work around the problem. My username wasn't in 'group' on the LDAP server either though, only in 'passwd' (where my GID is set to the GID of the users group, of course). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 14:58 Message: Logged In: YES user_id=136160 Originator: NO ticables2 library is parsing /etc/group for entries. Is your username in the same line as the 'users' line in this file? nss_ldap access may explain your problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-14 02:46:20
|
Bugs item #1808645, was opened at 2007-10-06 16:17 Message generated for change (Comment added) made by roms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: Accepted Priority: 5 Private: No Submitted By: rpdrum (rpdrum) Assigned to: Romain Liévin (roms) Summary: Backup - Connection Resets Initial Comment: I have a Voyage 200 connected via the "silver" usb cable. I am running TILP2 V1.07 under Linux (Fedora Core 7). From info screen: Framework version (cables=1.0.9, files=1.0.7, calcs=1.0.7, conv=1.0.4) When using the backup function it gets to a large flash application, and when the transfer of this file appears to be complete, sometimes I get a popup window saying the connection is being reset, then (regardless of whether I get the "reset" message) I get a popup window with the following message: Msg: timeout occured while reading to the device. Cause: check that link cable is plugged and/or the calculator is ready. System: Resource temporarily unavailable (errno = 11) At that point, the backup is failed. Where this problem occurs does not appear to have any consistency. It *usually* occurs on the first larger file transfer, but sometimes I actually get to the second larger flash app before getting these results. I have also had it occur on a rom dump. I have checked the log messages and don't find anything unusual there when this occurs. I have attached a gzipped file with the tilp output in it. If I can provide anything else, let me know. I really like this program and would like to get it working reliably for my setup. Thanks. ---------------------------------------------------------------------- >Comment By: Romain Liévin (roms) Date: 2007-10-14 04:46 Message: Logged In: YES user_id=136160 Originator: NO Another way to help me: backup your hand-held with Ti-Connect and send the TiGroup file backup to <roms AT tilp DOT info>. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-10-13 22:21 Message: Logged In: YES user_id=136160 Originator: NO Did you install TiLP from source or package? Would you be able to run a test for me? If yes, open ticalcs2/src/backup.c, look for ticalcs_calc_recv_tigroup and next, look for TRYF(handle->calc->is_ready(handle)). Simply add 'PAUSE(250);' just before and just after this line. Install the library again, re-run TiLP and take me up to date... Thanks, Romain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-14 02:40:44
|
Bugs item #1731776, was opened at 2007-06-06 03:50 Message generated for change (Comment added) made by roms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ross Kendall Axe (rossaxe) Assigned to: Romain Liévin (roms) Summary: Bad permissions check on /dev/ttySx Initial Comment: TiLP produces the following output in the terminal window when attempting to open a serial link: ticables-INFO: Check for tty usability: ticables-INFO: node /dev/ttyS0: exists ticables-INFO: permissions/user/group: -rw-rw---- root users ticables-INFO: is user can r/w on device: no ticables-INFO: are others can r/w on device: no ticables-INFO: is the user 'ross' in the group 'users': no ticables-INFO: => you should add your username at the group 'users' in '/etc/group' ticables-INFO: => you will have to restart you session, too However, 'id ross' clearly indicates that I'm in the users group, in case I didn't already know that ;-) $ id ross uid=1004(ross) gid=100(users) groups=100(users),11(floppy),17(audio),18(video),19(cdrom),93(scanner) Any attempt to use the link therefore fails since it never got initialised. As to why it failed to notice that I have access, well, I'm not sure. It could be that it's because it's my primary group, or because my passwd entry is accessed via nss_ldap. I imagine it would also fail if I was using ACLs. It seems to be that TiLP ought to simply use open("/dev/ttySx", O_RDWR) to check access rather than trying to be too clever and attempting to second guess the kernel's access rules. Meanwhile, 'chmod 0666 /dev/ttyS?' is a suitable workaround for this problem :-) ---------------------------------------------------------------------- >Comment By: Romain Liévin (roms) Date: 2007-10-14 04:40 Message: Logged In: YES user_id=136160 Originator: NO Patch merged. Thanks, Kevin. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:28 Message: Logged In: YES user_id=573515 Originator: NO Fixed patch (no need to check for group membership if the user has access, we can go directly to the "unknown reason" conclusion): Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,24 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +276,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +287,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:23 Message: Logged In: YES user_id=573515 Originator: NO > It does seem to me that if the program is not SUID, then no extra checks > are needed beyond what the kernel does anyway when calling open(), and if > it is then it should just drop privileges before it calls open(). Running TiLP SUID is no longer supported (there's better ways to get access rights to devices these days), but even when it was, the entire purpose of doing that was to be able to access more devices than otherwise. > But then again, I don't know what the reason for this extra check is so > perhaps this is too simple minded. It's to help debugging. I think the right solution is to: * use access() to check if the device can be accessed, * only if this fails, do the other checks to help debugging. I'd suggest this patch: Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,22 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +274,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +285,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) Romain, can I commit this one? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-10-13 20:30 Message: Logged In: YES user_id=1206088 Originator: YES Well, I'm glad I'm not the only one who thinks so :-) It does seem to me that if the program is not SUID, then no extra checks are needed beyond what the kernel does anyway when calling open(), and if it is then it should just drop privileges before it calls open(). But then again, I don't know what the reason for this extra check is so perhaps this is too simple minded. nss_ldap, ACLs, maybe SELinux? Either these things (and god only knows what else) have to supported explicitly, or libticables should just trust that the kernel knows best? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 08:47 Message: Logged In: YES user_id=573515 Originator: NO How's that "fixed"? He just worked around it. We really really need to fix libticables2 not to do those weird access checks, also because newer Fedora (and probably many other distros soon, because granting access to console users is now going to be done with ConsoleKit and HAL rather than the RH-specific pam_console) is going to always use ACLs to grant access to devices, so your ACL-unaware hacks aren't going to work anymore. ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-09 15:10 Message: Logged In: YES user_id=1206088 Originator: YES Yes, it's OK now with the the modification to /etc/group. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-05 08:50 Message: Logged In: YES user_id=136160 Originator: NO So, is TiLP working now? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-05 00:46 Message: Logged In: YES user_id=1206088 Originator: YES Yeah, putting my username into /etc/group does also work around the problem. My username wasn't in 'group' on the LDAP server either though, only in 'passwd' (where my GID is set to the GID of the users group, of course). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 14:58 Message: Logged In: YES user_id=136160 Originator: NO ticables2 library is parsing /etc/group for entries. Is your username in the same line as the 'users' line in this file? nss_ldap access may explain your problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-14 02:31:39
|
Bugs item #1731776, was opened at 2007-06-06 03:50 Message generated for change (Settings changed) made by roms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: Ross Kendall Axe (rossaxe) Assigned to: Romain Liévin (roms) Summary: Bad permissions check on /dev/ttySx Initial Comment: TiLP produces the following output in the terminal window when attempting to open a serial link: ticables-INFO: Check for tty usability: ticables-INFO: node /dev/ttyS0: exists ticables-INFO: permissions/user/group: -rw-rw---- root users ticables-INFO: is user can r/w on device: no ticables-INFO: are others can r/w on device: no ticables-INFO: is the user 'ross' in the group 'users': no ticables-INFO: => you should add your username at the group 'users' in '/etc/group' ticables-INFO: => you will have to restart you session, too However, 'id ross' clearly indicates that I'm in the users group, in case I didn't already know that ;-) $ id ross uid=1004(ross) gid=100(users) groups=100(users),11(floppy),17(audio),18(video),19(cdrom),93(scanner) Any attempt to use the link therefore fails since it never got initialised. As to why it failed to notice that I have access, well, I'm not sure. It could be that it's because it's my primary group, or because my passwd entry is accessed via nss_ldap. I imagine it would also fail if I was using ACLs. It seems to be that TiLP ought to simply use open("/dev/ttySx", O_RDWR) to check access rather than trying to be too clever and attempting to second guess the kernel's access rules. Meanwhile, 'chmod 0666 /dev/ttyS?' is a suitable workaround for this problem :-) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:28 Message: Logged In: YES user_id=573515 Originator: NO Fixed patch (no need to check for group membership if the user has access, we can go directly to the "unknown reason" conclusion): Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,24 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +276,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +287,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:23 Message: Logged In: YES user_id=573515 Originator: NO > It does seem to me that if the program is not SUID, then no extra checks > are needed beyond what the kernel does anyway when calling open(), and if > it is then it should just drop privileges before it calls open(). Running TiLP SUID is no longer supported (there's better ways to get access rights to devices these days), but even when it was, the entire purpose of doing that was to be able to access more devices than otherwise. > But then again, I don't know what the reason for this extra check is so > perhaps this is too simple minded. It's to help debugging. I think the right solution is to: * use access() to check if the device can be accessed, * only if this fails, do the other checks to help debugging. I'd suggest this patch: Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,22 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +274,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +285,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) Romain, can I commit this one? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-10-13 20:30 Message: Logged In: YES user_id=1206088 Originator: YES Well, I'm glad I'm not the only one who thinks so :-) It does seem to me that if the program is not SUID, then no extra checks are needed beyond what the kernel does anyway when calling open(), and if it is then it should just drop privileges before it calls open(). But then again, I don't know what the reason for this extra check is so perhaps this is too simple minded. nss_ldap, ACLs, maybe SELinux? Either these things (and god only knows what else) have to supported explicitly, or libticables should just trust that the kernel knows best? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 08:47 Message: Logged In: YES user_id=573515 Originator: NO How's that "fixed"? He just worked around it. We really really need to fix libticables2 not to do those weird access checks, also because newer Fedora (and probably many other distros soon, because granting access to console users is now going to be done with ConsoleKit and HAL rather than the RH-specific pam_console) is going to always use ACLs to grant access to devices, so your ACL-unaware hacks aren't going to work anymore. ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-09 15:10 Message: Logged In: YES user_id=1206088 Originator: YES Yes, it's OK now with the the modification to /etc/group. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-05 08:50 Message: Logged In: YES user_id=136160 Originator: NO So, is TiLP working now? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-05 00:46 Message: Logged In: YES user_id=1206088 Originator: YES Yeah, putting my username into /etc/group does also work around the problem. My username wasn't in 'group' on the LDAP server either though, only in 'passwd' (where my GID is set to the GID of the users group, of course). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 14:58 Message: Logged In: YES user_id=136160 Originator: NO ticables2 library is parsing /etc/group for entries. Is your username in the same line as the 'users' line in this file? nss_ldap access may explain your problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-13 21:28:13
|
Bugs item #1731776, was opened at 2007-06-06 03:50 Message generated for change (Comment added) made by kevinkofler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Ross Kendall Axe (rossaxe) Assigned to: Romain Liévin (roms) Summary: Bad permissions check on /dev/ttySx Initial Comment: TiLP produces the following output in the terminal window when attempting to open a serial link: ticables-INFO: Check for tty usability: ticables-INFO: node /dev/ttyS0: exists ticables-INFO: permissions/user/group: -rw-rw---- root users ticables-INFO: is user can r/w on device: no ticables-INFO: are others can r/w on device: no ticables-INFO: is the user 'ross' in the group 'users': no ticables-INFO: => you should add your username at the group 'users' in '/etc/group' ticables-INFO: => you will have to restart you session, too However, 'id ross' clearly indicates that I'm in the users group, in case I didn't already know that ;-) $ id ross uid=1004(ross) gid=100(users) groups=100(users),11(floppy),17(audio),18(video),19(cdrom),93(scanner) Any attempt to use the link therefore fails since it never got initialised. As to why it failed to notice that I have access, well, I'm not sure. It could be that it's because it's my primary group, or because my passwd entry is accessed via nss_ldap. I imagine it would also fail if I was using ACLs. It seems to be that TiLP ought to simply use open("/dev/ttySx", O_RDWR) to check access rather than trying to be too clever and attempting to second guess the kernel's access rules. Meanwhile, 'chmod 0666 /dev/ttyS?' is a suitable workaround for this problem :-) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:28 Message: Logged In: YES user_id=573515 Originator: NO Fixed patch (no need to check for group membership if the user has access, we can go directly to the "unknown reason" conclusion): Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,24 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +276,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +287,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:23 Message: Logged In: YES user_id=573515 Originator: NO > It does seem to me that if the program is not SUID, then no extra checks > are needed beyond what the kernel does anyway when calling open(), and if > it is then it should just drop privileges before it calls open(). Running TiLP SUID is no longer supported (there's better ways to get access rights to devices these days), but even when it was, the entire purpose of doing that was to be able to access more devices than otherwise. > But then again, I don't know what the reason for this extra check is so > perhaps this is too simple minded. It's to help debugging. I think the right solution is to: * use access() to check if the device can be accessed, * only if this fails, do the other checks to help debugging. I'd suggest this patch: Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,22 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +274,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +285,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) Romain, can I commit this one? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-10-13 20:30 Message: Logged In: YES user_id=1206088 Originator: YES Well, I'm glad I'm not the only one who thinks so :-) It does seem to me that if the program is not SUID, then no extra checks are needed beyond what the kernel does anyway when calling open(), and if it is then it should just drop privileges before it calls open(). But then again, I don't know what the reason for this extra check is so perhaps this is too simple minded. nss_ldap, ACLs, maybe SELinux? Either these things (and god only knows what else) have to supported explicitly, or libticables should just trust that the kernel knows best? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 08:47 Message: Logged In: YES user_id=573515 Originator: NO How's that "fixed"? He just worked around it. We really really need to fix libticables2 not to do those weird access checks, also because newer Fedora (and probably many other distros soon, because granting access to console users is now going to be done with ConsoleKit and HAL rather than the RH-specific pam_console) is going to always use ACLs to grant access to devices, so your ACL-unaware hacks aren't going to work anymore. ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-09 15:10 Message: Logged In: YES user_id=1206088 Originator: YES Yes, it's OK now with the the modification to /etc/group. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-05 08:50 Message: Logged In: YES user_id=136160 Originator: NO So, is TiLP working now? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-05 00:46 Message: Logged In: YES user_id=1206088 Originator: YES Yeah, putting my username into /etc/group does also work around the problem. My username wasn't in 'group' on the LDAP server either though, only in 'passwd' (where my GID is set to the GID of the users group, of course). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 14:58 Message: Logged In: YES user_id=136160 Originator: NO ticables2 library is parsing /etc/group for entries. Is your username in the same line as the 'users' line in this file? nss_ldap access may explain your problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-13 21:22:58
|
Bugs item #1731776, was opened at 2007-06-06 03:50 Message generated for change (Comment added) made by kevinkofler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Ross Kendall Axe (rossaxe) Assigned to: Romain Liévin (roms) Summary: Bad permissions check on /dev/ttySx Initial Comment: TiLP produces the following output in the terminal window when attempting to open a serial link: ticables-INFO: Check for tty usability: ticables-INFO: node /dev/ttyS0: exists ticables-INFO: permissions/user/group: -rw-rw---- root users ticables-INFO: is user can r/w on device: no ticables-INFO: are others can r/w on device: no ticables-INFO: is the user 'ross' in the group 'users': no ticables-INFO: => you should add your username at the group 'users' in '/etc/group' ticables-INFO: => you will have to restart you session, too However, 'id ross' clearly indicates that I'm in the users group, in case I didn't already know that ;-) $ id ross uid=1004(ross) gid=100(users) groups=100(users),11(floppy),17(audio),18(video),19(cdrom),93(scanner) Any attempt to use the link therefore fails since it never got initialised. As to why it failed to notice that I have access, well, I'm not sure. It could be that it's because it's my primary group, or because my passwd entry is accessed via nss_ldap. I imagine it would also fail if I was using ACLs. It seems to be that TiLP ought to simply use open("/dev/ttySx", O_RDWR) to check access rather than trying to be too clever and attempting to second guess the kernel's access rules. Meanwhile, 'chmod 0666 /dev/ttyS?' is a suitable workaround for this problem :-) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 23:23 Message: Logged In: YES user_id=573515 Originator: NO > It does seem to me that if the program is not SUID, then no extra checks > are needed beyond what the kernel does anyway when calling open(), and if > it is then it should just drop privileges before it calls open(). Running TiLP SUID is no longer supported (there's better ways to get access rights to devices these days), but even when it was, the entire purpose of doing that was to be able to access more devices than otherwise. > But then again, I don't know what the reason for this extra check is so > perhaps this is too simple minded. It's to help debugging. I think the right solution is to: * use access() to check if the device can be accessed, * only if this fails, do the other checks to help debugging. I'd suggest this patch: Index: src/linux/detect.c =================================================================== --- src/linux/detect.c (revision 3891) +++ src/linux/detect.c (working copy) @@ -3,6 +3,7 @@ /* libticables2 - link cable library, a part of the TiLP project * Copyright (C) 1999-2005 Romain Lievin + * Copyright (C) 2007 Kevin Kofler * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -217,12 +218,18 @@ } else { - ticables_info(_(" node %s: does not exists"), pathname); + ticables_info(_(" node %s: does not exist"), pathname); ticables_info(_(" => you will have to create the node.")); return -1; } + if(access(pathname, R_OK | W_OK)) + { + ticables_info(_(" node %s: accessible"), pathname); + return 0; + } + if(!stat(pathname, &st)) { ticables_info(_(" permissions/user/group:%s%s %s"), @@ -238,23 +245,22 @@ if(getuid() == st.st_uid) { - ticables_info(_(" is user can r/w on device: yes")); - return 0; + ticables_info(_(" user can r/w on device: yes")); } else { - ticables_info(_(" is user can r/w on device: no")); + ticables_info(_(" user can r/w on device: no")); } if((st.st_mode & S_IROTH) && (st.st_mode & S_IWOTH)) { - ticables_info(_(" are others can r/w on device: yes")); + ticables_info(_(" others can r/w on device: yes")); } else { char *user, *group; - ticables_info(_(" are others can r/w on device: no")); + ticables_info(_(" others can r/w on device: no")); user = strdup(get_user_name(getuid())); group = strdup(get_group_name(st.st_gid)); @@ -268,7 +274,7 @@ { ticables_info(_(" is the user '%s' in the group '%s': no"), user, group); ticables_info(_(" => you should add your username at the group '%s' in '/etc/group'"), group); - ticables_info(_(" => you will have to restart you session, too"), group); + ticables_info(_(" => you will have to restart you session, too")); free(user); free(group); @@ -279,7 +285,8 @@ free(group); } - return 0; + ticables_info(_(" => device is inaccessible for unknown reasons (SELinux?)")); + return -1; } int linux_check_root(void) Romain, can I commit this one? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-10-13 20:30 Message: Logged In: YES user_id=1206088 Originator: YES Well, I'm glad I'm not the only one who thinks so :-) It does seem to me that if the program is not SUID, then no extra checks are needed beyond what the kernel does anyway when calling open(), and if it is then it should just drop privileges before it calls open(). But then again, I don't know what the reason for this extra check is so perhaps this is too simple minded. nss_ldap, ACLs, maybe SELinux? Either these things (and god only knows what else) have to supported explicitly, or libticables should just trust that the kernel knows best? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 08:47 Message: Logged In: YES user_id=573515 Originator: NO How's that "fixed"? He just worked around it. We really really need to fix libticables2 not to do those weird access checks, also because newer Fedora (and probably many other distros soon, because granting access to console users is now going to be done with ConsoleKit and HAL rather than the RH-specific pam_console) is going to always use ACLs to grant access to devices, so your ACL-unaware hacks aren't going to work anymore. ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-09 15:10 Message: Logged In: YES user_id=1206088 Originator: YES Yes, it's OK now with the the modification to /etc/group. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-05 08:50 Message: Logged In: YES user_id=136160 Originator: NO So, is TiLP working now? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-05 00:46 Message: Logged In: YES user_id=1206088 Originator: YES Yeah, putting my username into /etc/group does also work around the problem. My username wasn't in 'group' on the LDAP server either though, only in 'passwd' (where my GID is set to the GID of the users group, of course). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 14:58 Message: Logged In: YES user_id=136160 Originator: NO ticables2 library is parsing /etc/group for entries. Is your username in the same line as the 'users' line in this file? nss_ldap access may explain your problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-13 20:33:00
|
Bugs item #1709137, was opened at 2007-04-28 10:34 Message generated for change (Comment added) made by roms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1709137&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Vity01 (vity01) Assigned to: Romain Liévin (roms) Summary: TiLP 2 WinXp - Popmenu - Grouping/Ungrouping does not work Initial Comment: Hello, I am playing with TiLP2 1.03 to help user of WordRider and i encountered some problems with managing files. 1. When I select some 89t files and then I use popmenu (right click) so this menu disappears immediately - it flashes/blinks only (i can see it when no files of such file types are selected). 2. When I select 89g file and then I use same popmenu. Popmenu appears correctly, but file becomes deselected so I always get error 'A file must have been selected in the right window.' Yet another note to TI-89 Link Protocol Guide/TiLP. The latest version of AMS OS seems to stop to support 'A simplification of the TI-89 file format for a single variable' (user on MacOS cannot move such file see http://wordrider.net/forum/read.php?2,286 for more details). Could you add a support to move these file types to such version OS? Vity WordRider developer ---------------------------------------------------------------------- >Comment By: Romain Liévin (roms) Date: 2007-10-13 22:33 Message: Logged In: YES user_id=136160 Originator: NO No answer from 3 months. Bug closed! ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 15:10 Message: Logged In: YES user_id=136160 Originator: NO Could you send to me your file(s)? roms AT tilp DOT info. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1709137&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-13 20:21:02
|
Bugs item #1808645, was opened at 2007-10-06 16:17 Message generated for change (Comment added) made by roms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: rpdrum (rpdrum) Assigned to: Romain Liévin (roms) Summary: Backup - Connection Resets Initial Comment: I have a Voyage 200 connected via the "silver" usb cable. I am running TILP2 V1.07 under Linux (Fedora Core 7). From info screen: Framework version (cables=1.0.9, files=1.0.7, calcs=1.0.7, conv=1.0.4) When using the backup function it gets to a large flash application, and when the transfer of this file appears to be complete, sometimes I get a popup window saying the connection is being reset, then (regardless of whether I get the "reset" message) I get a popup window with the following message: Msg: timeout occured while reading to the device. Cause: check that link cable is plugged and/or the calculator is ready. System: Resource temporarily unavailable (errno = 11) At that point, the backup is failed. Where this problem occurs does not appear to have any consistency. It *usually* occurs on the first larger file transfer, but sometimes I actually get to the second larger flash app before getting these results. I have also had it occur on a rom dump. I have checked the log messages and don't find anything unusual there when this occurs. I have attached a gzipped file with the tilp output in it. If I can provide anything else, let me know. I really like this program and would like to get it working reliably for my setup. Thanks. ---------------------------------------------------------------------- >Comment By: Romain Liévin (roms) Date: 2007-10-13 22:21 Message: Logged In: YES user_id=136160 Originator: NO Did you install TiLP from source or package? Would you be able to run a test for me? If yes, open ticalcs2/src/backup.c, look for ticalcs_calc_recv_tigroup and next, look for TRYF(handle->calc->is_ready(handle)). Simply add 'PAUSE(250);' just before and just after this line. Install the library again, re-run TiLP and take me up to date... Thanks, Romain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-13 18:34:24
|
Bugs item #1808645, was opened at 2007-10-06 16:17 Message generated for change (Settings changed) made by roms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: rpdrum (rpdrum) >Assigned to: Romain Liévin (roms) Summary: Backup - Connection Resets Initial Comment: I have a Voyage 200 connected via the "silver" usb cable. I am running TILP2 V1.07 under Linux (Fedora Core 7). From info screen: Framework version (cables=1.0.9, files=1.0.7, calcs=1.0.7, conv=1.0.4) When using the backup function it gets to a large flash application, and when the transfer of this file appears to be complete, sometimes I get a popup window saying the connection is being reset, then (regardless of whether I get the "reset" message) I get a popup window with the following message: Msg: timeout occured while reading to the device. Cause: check that link cable is plugged and/or the calculator is ready. System: Resource temporarily unavailable (errno = 11) At that point, the backup is failed. Where this problem occurs does not appear to have any consistency. It *usually* occurs on the first larger file transfer, but sometimes I actually get to the second larger flash app before getting these results. I have also had it occur on a rom dump. I have checked the log messages and don't find anything unusual there when this occurs. I have attached a gzipped file with the tilp output in it. If I can provide anything else, let me know. I really like this program and would like to get it working reliably for my setup. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1808645&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-13 18:30:31
|
Bugs item #1731776, was opened at 2007-06-06 02:50 Message generated for change (Comment added) made by rossaxe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Ross Kendall Axe (rossaxe) Assigned to: Romain Liévin (roms) Summary: Bad permissions check on /dev/ttySx Initial Comment: TiLP produces the following output in the terminal window when attempting to open a serial link: ticables-INFO: Check for tty usability: ticables-INFO: node /dev/ttyS0: exists ticables-INFO: permissions/user/group: -rw-rw---- root users ticables-INFO: is user can r/w on device: no ticables-INFO: are others can r/w on device: no ticables-INFO: is the user 'ross' in the group 'users': no ticables-INFO: => you should add your username at the group 'users' in '/etc/group' ticables-INFO: => you will have to restart you session, too However, 'id ross' clearly indicates that I'm in the users group, in case I didn't already know that ;-) $ id ross uid=1004(ross) gid=100(users) groups=100(users),11(floppy),17(audio),18(video),19(cdrom),93(scanner) Any attempt to use the link therefore fails since it never got initialised. As to why it failed to notice that I have access, well, I'm not sure. It could be that it's because it's my primary group, or because my passwd entry is accessed via nss_ldap. I imagine it would also fail if I was using ACLs. It seems to be that TiLP ought to simply use open("/dev/ttySx", O_RDWR) to check access rather than trying to be too clever and attempting to second guess the kernel's access rules. Meanwhile, 'chmod 0666 /dev/ttyS?' is a suitable workaround for this problem :-) ---------------------------------------------------------------------- >Comment By: Ross Kendall Axe (rossaxe) Date: 2007-10-13 19:30 Message: Logged In: YES user_id=1206088 Originator: YES Well, I'm glad I'm not the only one who thinks so :-) It does seem to me that if the program is not SUID, then no extra checks are needed beyond what the kernel does anyway when calling open(), and if it is then it should just drop privileges before it calls open(). But then again, I don't know what the reason for this extra check is so perhaps this is too simple minded. nss_ldap, ACLs, maybe SELinux? Either these things (and god only knows what else) have to supported explicitly, or libticables should just trust that the kernel knows best? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 07:47 Message: Logged In: YES user_id=573515 Originator: NO How's that "fixed"? He just worked around it. We really really need to fix libticables2 not to do those weird access checks, also because newer Fedora (and probably many other distros soon, because granting access to console users is now going to be done with ConsoleKit and HAL rather than the RH-specific pam_console) is going to always use ACLs to grant access to devices, so your ACL-unaware hacks aren't going to work anymore. ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-09 14:10 Message: Logged In: YES user_id=1206088 Originator: YES Yes, it's OK now with the the modification to /etc/group. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-05 07:50 Message: Logged In: YES user_id=136160 Originator: NO So, is TiLP working now? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-04 23:46 Message: Logged In: YES user_id=1206088 Originator: YES Yeah, putting my username into /etc/group does also work around the problem. My username wasn't in 'group' on the LDAP server either though, only in 'passwd' (where my GID is set to the GID of the users group, of course). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 13:58 Message: Logged In: YES user_id=136160 Originator: NO ticables2 library is parsing /etc/group for entries. Is your username in the same line as the 'users' line in this file? nss_ldap access may explain your problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-13 18:13:16
|
Bugs item #1811299, was opened at 2007-10-11 07:12 Message generated for change (Comment added) made by roms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1811299&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Darksurf (darksurf) >Assigned to: Romain Liévin (roms) Summary: Doesn't even compile Initial Comment: IR=\"/etc\" -DGTK_DISABLE_DEPRECATED -DQT_THREAD_SUPPORT -D_REENTRANT -Wall -g -O2 -D__LINUX__ -fvisibility=hidden -DGTK_DISABLE_DEPRECATED -MT tilp-device.o -MD -MP -MF .deps/tilp-device.Tpo -c -o tilp-device.o `test -f 'device.c' || echo './'`device.c device.c: In function ‘comm_treeview1_button_press_event’: device.c:194: error: ‘CALC_NSPIRE’ undeclared (first use in this function) device.c:194: error: (Each undeclared identifier is reported only once device.c:194: error: for each function it appears in.) device.c: In function ‘display_device_dbox’: device.c:358: error: ‘CALC_NSPIRE’ undeclared (first use in this function) device.c: In function ‘comm_calc_changed’: device.c:499: error: ‘CALC_NSPIRE’ undeclared (first use in this function) make[2]: *** [tilp-device.o] Error 1 make[2]: Leaving directory `/home/darksurf/tilp2/tilp2-1.07/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/darksurf/tilp2/tilp2-1.07' make: *** [all] Error 2 darksurf@Darkwaters ~/tilp2/tilp2-1.07 $ ---------------------------------------------------------------------- >Comment By: Romain Liévin (roms) Date: 2007-10-13 20:13 Message: Logged In: YES user_id=136160 Originator: NO It compiles since yesterday. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 08:39 Message: Logged In: YES user_id=573515 Originator: NO Current SVN is known not to compile, please use a release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1811299&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-13 06:47:28
|
Bugs item #1731776, was opened at 2007-06-06 03:50 Message generated for change (Comment added) made by kevinkofler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Ross Kendall Axe (rossaxe) Assigned to: Romain Liévin (roms) Summary: Bad permissions check on /dev/ttySx Initial Comment: TiLP produces the following output in the terminal window when attempting to open a serial link: ticables-INFO: Check for tty usability: ticables-INFO: node /dev/ttyS0: exists ticables-INFO: permissions/user/group: -rw-rw---- root users ticables-INFO: is user can r/w on device: no ticables-INFO: are others can r/w on device: no ticables-INFO: is the user 'ross' in the group 'users': no ticables-INFO: => you should add your username at the group 'users' in '/etc/group' ticables-INFO: => you will have to restart you session, too However, 'id ross' clearly indicates that I'm in the users group, in case I didn't already know that ;-) $ id ross uid=1004(ross) gid=100(users) groups=100(users),11(floppy),17(audio),18(video),19(cdrom),93(scanner) Any attempt to use the link therefore fails since it never got initialised. As to why it failed to notice that I have access, well, I'm not sure. It could be that it's because it's my primary group, or because my passwd entry is accessed via nss_ldap. I imagine it would also fail if I was using ACLs. It seems to be that TiLP ought to simply use open("/dev/ttySx", O_RDWR) to check access rather than trying to be too clever and attempting to second guess the kernel's access rules. Meanwhile, 'chmod 0666 /dev/ttyS?' is a suitable workaround for this problem :-) ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 08:47 Message: Logged In: YES user_id=573515 Originator: NO How's that "fixed"? He just worked around it. We really really need to fix libticables2 not to do those weird access checks, also because newer Fedora (and probably many other distros soon, because granting access to console users is now going to be done with ConsoleKit and HAL rather than the RH-specific pam_console) is going to always use ACLs to grant access to devices, so your ACL-unaware hacks aren't going to work anymore. ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-09 15:10 Message: Logged In: YES user_id=1206088 Originator: YES Yes, it's OK now with the the modification to /etc/group. ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-05 08:50 Message: Logged In: YES user_id=136160 Originator: NO So, is TiLP working now? ---------------------------------------------------------------------- Comment By: Ross Kendall Axe (rossaxe) Date: 2007-07-05 00:46 Message: Logged In: YES user_id=1206088 Originator: YES Yeah, putting my username into /etc/group does also work around the problem. My username wasn't in 'group' on the LDAP server either though, only in 'passwd' (where my GID is set to the GID of the users group, of course). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 14:58 Message: Logged In: YES user_id=136160 Originator: NO ticables2 library is parsing /etc/group for entries. Is your username in the same line as the 'users' line in this file? nss_ldap access may explain your problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1731776&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-13 06:39:49
|
Bugs item #1811299, was opened at 2007-10-11 07:12 Message generated for change (Comment added) made by kevinkofler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1811299&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Darksurf (darksurf) Assigned to: Nobody/Anonymous (nobody) Summary: Doesn't even compile Initial Comment: IR=\"/etc\" -DGTK_DISABLE_DEPRECATED -DQT_THREAD_SUPPORT -D_REENTRANT -Wall -g -O2 -D__LINUX__ -fvisibility=hidden -DGTK_DISABLE_DEPRECATED -MT tilp-device.o -MD -MP -MF .deps/tilp-device.Tpo -c -o tilp-device.o `test -f 'device.c' || echo './'`device.c device.c: In function ‘comm_treeview1_button_press_event’: device.c:194: error: ‘CALC_NSPIRE’ undeclared (first use in this function) device.c:194: error: (Each undeclared identifier is reported only once device.c:194: error: for each function it appears in.) device.c: In function ‘display_device_dbox’: device.c:358: error: ‘CALC_NSPIRE’ undeclared (first use in this function) device.c: In function ‘comm_calc_changed’: device.c:499: error: ‘CALC_NSPIRE’ undeclared (first use in this function) make[2]: *** [tilp-device.o] Error 1 make[2]: Leaving directory `/home/darksurf/tilp2/tilp2-1.07/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/darksurf/tilp2/tilp2-1.07' make: *** [all] Error 2 darksurf@Darkwaters ~/tilp2/tilp2-1.07 $ ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2007-10-13 08:39 Message: Logged In: YES user_id=573515 Originator: NO Current SVN is known not to compile, please use a release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1811299&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-12 02:20:05
|
Bugs item #1719926, was opened at 2007-05-16 03:44 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1719926&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Romain Liévin (roms) Summary: Error 35 with TI-85 and TiLP2 Initial Comment: I use: * USB SilverLink cable * TiLP2 v1.03 and TiLP v6.81 * TI-82 and TI-85 With the TI-82, TiLP2 works perfectly (I tried restore, transfer and screenshot). With the TI-85, TiLP2 complains about a communication error and the TI-85 returns a "Transmission error 35" whenever I try to restore, send a file or take a screenshot. Yet, with TiLP v6.81, all of these operations work perfectly. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-10-11 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-09-27 04:47 Message: Logged In: YES user_id=136160 Originator: NO Can you give a try to TiLP v1.07? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1719926&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-12 02:20:05
|
Bugs item #1719757, was opened at 2007-05-15 20:06 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1719757&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Private: Yes Submitted By: Nobody/Anonymous (nobody) Assigned to: Romain Liévin (roms) Summary: Win98se and USB cable Initial Comment: Dear Sirs, Even after downloading the latest driver for the USB direct cable(under Win98se) I could not get the USB to work with either Tilp2 or with the latest TiEmu3. I've looked at the Tiglusb.dll and found that the same driver is supplied in the different *.zip versions. They all list under "Special Build Desription" Windows XP. I could well be wrong but have a look maybe that's the reason why the USB cable's just don't work. Best regards, Joe jo...@al... ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-10-11 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-09-27 04:46 Message: Logged In: YES user_id=136160 Originator: NO Can you give a try to TiLP v1.07b. It has new USB drivers... ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-07-04 06:06 Message: Logged In: YES user_id=136160 Originator: NO Could you go into your control panel and check whether the cable is properly detected and installed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1719757&group_id=18378 |
|
From: SourceForge.net <no...@so...> - 2007-10-12 02:20:03
|
Bugs item #1742548, was opened at 2007-06-24 14:09 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1742548&group_id=18378 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Private: Yes Submitted By: Nobody/Anonymous (nobody) Assigned to: Romain Liévin (roms) Summary: Crash Initial Comment: TILp2 (version 1.04)keeps on crashing whenever I try to move a variable from TI89 to PC or when I try to do a backup. AppName: tilp.exe AppVer: 1.0.4.0 ModName: ntdll.dll ModVer: 5.1.2600.2180 Offset: 00011e58 Tilp2 version 013 has no problems! I run Windows xp pro and TI89Titanium with direct USB cable (driver is installed) bo_...@ya... ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-10-11 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Romain Liévin (roms) Date: 2007-09-26 23:00 Message: Logged In: YES user_id=136160 Originator: NO Can you try and use TiLP2 v1.07b from SourceForge archives? Driver has been changed, it may solve your problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=118378&aid=1742548&group_id=18378 |
379 messages has been excluded from this view by a project administrator.
