* worth adding a "git"-versioned of i2c-tools to oe-core? @ 2017-07-31 10:41 rpjday 2017-07-31 10:41 ` Alexander Kanavin 0 siblings, 1 reply; 9+ messages in thread From: rpjday @ 2017-07-31 10:41 UTC (permalink / raw) To: openembedded-core given that some significant changes have been made to i2c-tools since version 3.1.2, is it worth adding a git-versioned recipe of that to oe-core, and using DEFAULT_PREFERENCE to force people to select it if they want it? in particular, the code base has been restructured, and a new utility, "i2ctransfer", has been added. rday ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: worth adding a "git"-versioned of i2c-tools to oe-core? 2017-07-31 10:41 worth adding a "git"-versioned of i2c-tools to oe-core? rpjday @ 2017-07-31 10:41 ` Alexander Kanavin 2017-07-31 11:00 ` Richard Purdie 0 siblings, 1 reply; 9+ messages in thread From: Alexander Kanavin @ 2017-07-31 10:41 UTC (permalink / raw) To: rpjday, openembedded-core On 07/31/2017 01:41 PM, rpjday@crashcourse.ca wrote: > > given that some significant changes have been made to i2c-tools since > version 3.1.2, is it worth adding a git-versioned recipe of that to > oe-core, > and using DEFAULT_PREFERENCE to force people to select it if they want it? > in particular, the code base has been restructured, and a new utility, > "i2ctransfer", has been added. It's better to ask the upstream to make a new release. We've had dual git/release recipes in the past, and they were all an utter failure. In the sense, that only one version of the recipe was maintained, and the other was completely neglected. Alex ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: worth adding a "git"-versioned of i2c-tools to oe-core? 2017-07-31 10:41 ` Alexander Kanavin @ 2017-07-31 11:00 ` Richard Purdie 2017-07-31 11:15 ` rpjday 0 siblings, 1 reply; 9+ messages in thread From: Richard Purdie @ 2017-07-31 11:00 UTC (permalink / raw) To: Alexander Kanavin, rpjday, openembedded-core On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote: > On 07/31/2017 01:41 PM, rpjday@crashcourse.ca wrote: > > > > > > given that some significant changes have been made to i2c-tools > > since > > version 3.1.2, is it worth adding a git-versioned recipe of that > > to > > oe-core, > > and using DEFAULT_PREFERENCE to force people to select it if they > > want it? > > in particular, the code base has been restructured, and a new > > utility, > > "i2ctransfer", has been added. > It's better to ask the upstream to make a new release. > > We've had dual git/release recipes in the past, and they were all an > utter failure. In the sense, that only one version of the recipe was > maintained, and the other was completely neglected. Going forward we may accept patches using this instead: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass Cheers, Richard ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: worth adding a "git"-versioned of i2c-tools to oe-core? 2017-07-31 11:00 ` Richard Purdie @ 2017-07-31 11:15 ` rpjday 2017-07-31 12:50 ` Maxin B. John 2017-07-31 18:57 ` Khem Raj 0 siblings, 2 replies; 9+ messages in thread From: rpjday @ 2017-07-31 11:15 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core Quoting Richard Purdie <richard.purdie@linuxfoundation.org>: > On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote: >> On 07/31/2017 01:41 PM, rpjday@crashcourse.ca wrote: >> > >> > >> > given that some significant changes have been made to i2c-tools >> > since >> > version 3.1.2, is it worth adding a git-versioned recipe of that >> > to >> > oe-core, >> > and using DEFAULT_PREFERENCE to force people to select it if they >> > want it? >> > in particular, the code base has been restructured, and a new >> > utility, >> > "i2ctransfer", has been added. >> It's better to ask the upstream to make a new release. >> >> We've had dual git/release recipes in the past, and they were all an >> utter failure. In the sense, that only one version of the recipe was >> maintained, and the other was completely neglected. > > Going forward we may accept patches using this instead: > > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass > > Cheers, > > Richard well, here's a possible conundrum ... in that same package (i2c-tools), there appears to be an *obvious* flaw in that the "eeprog" utility uses a sleep that is far too short for proper operation, as described here: https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html there is a link to a patch on that page that simply cranks up a few sleep calls from 10usec to 5msec, which apparently solves the problem. i've been involved in a discussion on the i2c-tools mailing list about this very issue after i tripped over it, but there seems to be little enthusiasm on that list for "fixing" this -- i was told that people use the kernel driver instead and access via /sys rather than calling "eeprog". so, from my perspective, this should definitely be fixed so that "eeprog" functions properly, but it's not clear upstream is all that interested in it. what would the protocol be here? rday ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: worth adding a "git"-versioned of i2c-tools to oe-core? 2017-07-31 11:15 ` rpjday @ 2017-07-31 12:50 ` Maxin B. John 2017-07-31 14:10 ` Maxin B. John 2017-07-31 19:17 ` Andre McCurdy 2017-07-31 18:57 ` Khem Raj 1 sibling, 2 replies; 9+ messages in thread From: Maxin B. John @ 2017-07-31 12:50 UTC (permalink / raw) To: rpjday; +Cc: openembedded-core Hi, On Mon, Jul 31, 2017 at 07:15:23AM -0400, rpjday@crashcourse.ca wrote: > > Quoting Richard Purdie <richard.purdie@linuxfoundation.org>: > > >On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote: > >>On 07/31/2017 01:41 PM, rpjday@crashcourse.ca wrote: > >>> > >>> > >>> given that some significant changes have been made to i2c-tools > >>> since > >>> version 3.1.2, is it worth adding a git-versioned recipe of that > >>> to > >>> oe-core, > >>> and using DEFAULT_PREFERENCE to force people to select it if they > >>> want it? > >>> in particular, the code base has been restructured, and a new > >>> utility, > >>> "i2ctransfer", has been added. > >>It's better to ask the upstream to make a new release. > >> > >>We've had dual git/release recipes in the past, and they were all an > >>utter failure. In the sense, that only one version of the recipe was > >>maintained, and the other was completely neglected. > > > >Going forward we may accept patches using this instead: > > > >http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass > > > >Cheers, > > > >Richard > > well, here's a possible conundrum ... in that same package (i2c-tools), > there appears to be an *obvious* flaw in that the "eeprog" utility uses a > sleep that is far too short for proper operation, as described here: > > https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html > > there is a link to a patch on that page that simply cranks up a few sleep > calls from 10usec to 5msec, which apparently solves the problem. i've been > involved in a discussion on the i2c-tools mailing list about this very > issue after i tripped over it, but there seems to be little enthusiasm on > that list for "fixing" this -- i was told that people use the kernel driver > instead and access via /sys rather than calling "eeprog". dl.lm-sensors.org has been down for a while and doesn't show any positive signs that it will be back in near future. One possibility will be to use the unofficial mirrors listed below and upgrade to version 3.1.2 1. https://fossies.org/linux/misc/ 2. http://jdelvare.nerim.net/mirror/i2c-tools/ > so, from my perspective, this should definitely be fixed so that "eeprog" > functions properly, but it's not clear upstream is all that interested in it. > what would the protocol be here? Since this genuinely fixes an error, we should be able to include this patch with: "Inappropriate [bug workaround]" status. > rday Best Regards, Maxin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: worth adding a "git"-versioned of i2c-tools to oe-core? 2017-07-31 12:50 ` Maxin B. John @ 2017-07-31 14:10 ` Maxin B. John 2017-07-31 19:17 ` Andre McCurdy 1 sibling, 0 replies; 9+ messages in thread From: Maxin B. John @ 2017-07-31 14:10 UTC (permalink / raw) To: rpjday; +Cc: openembedded-core Hi, On Mon, Jul 31, 2017 at 03:50:17PM +0300, Maxin B. John wrote: > Hi, > > On Mon, Jul 31, 2017 at 07:15:23AM -0400, rpjday@crashcourse.ca wrote: > > <snip> > > > > well, here's a possible conundrum ... in that same package (i2c-tools), > > there appears to be an *obvious* flaw in that the "eeprog" utility uses a > > sleep that is far too short for proper operation, as described here: > > > > https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html > > > > there is a link to a patch on that page that simply cranks up a few sleep > > calls from 10usec to 5msec, which apparently solves the problem. i've been > > involved in a discussion on the i2c-tools mailing list about this very > > issue after i tripped over it, but there seems to be little enthusiasm on > > that list for "fixing" this -- i was told that people use the kernel driver > > instead and access via /sys rather than calling "eeprog". > > dl.lm-sensors.org has been down for a while and doesn't show any positive signs that > it will be back in near future. One possibility will be to use the unofficial mirrors > listed below and upgrade to version 3.1.2 Sorry, I meant to use the most recent version (we already have the latest released verion - 3.1.2) > 1. https://fossies.org/linux/misc/ > 2. http://jdelvare.nerim.net/mirror/i2c-tools/ > > > so, from my perspective, this should definitely be fixed so that "eeprog" > > functions properly, but it's not clear upstream is all that interested in it. > > what would the protocol be here? > > Since this genuinely fixes an error, we should be able to include this patch with: > "Inappropriate [bug workaround]" status. > > > rday > > Best Regards, > Maxin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: worth adding a "git"-versioned of i2c-tools to oe-core? 2017-07-31 12:50 ` Maxin B. John 2017-07-31 14:10 ` Maxin B. John @ 2017-07-31 19:17 ` Andre McCurdy 1 sibling, 0 replies; 9+ messages in thread From: Andre McCurdy @ 2017-07-31 19:17 UTC (permalink / raw) To: Maxin B. John; +Cc: OE Core mailing list On Mon, Jul 31, 2017 at 5:50 AM, Maxin B. John <maxin.john@intel.com> wrote: > Hi, > > On Mon, Jul 31, 2017 at 07:15:23AM -0400, rpjday@crashcourse.ca wrote: >> >> Quoting Richard Purdie <richard.purdie@linuxfoundation.org>: >> >> >On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote: >> >>On 07/31/2017 01:41 PM, rpjday@crashcourse.ca wrote: >> >>> >> >>> >> >>> given that some significant changes have been made to i2c-tools >> >>> since >> >>> version 3.1.2, is it worth adding a git-versioned recipe of that >> >>> to >> >>> oe-core, >> >>> and using DEFAULT_PREFERENCE to force people to select it if they >> >>> want it? >> >>> in particular, the code base has been restructured, and a new >> >>> utility, >> >>> "i2ctransfer", has been added. >> >>It's better to ask the upstream to make a new release. >> >> >> >>We've had dual git/release recipes in the past, and they were all an >> >>utter failure. In the sense, that only one version of the recipe was >> >>maintained, and the other was completely neglected. >> > >> >Going forward we may accept patches using this instead: >> > >> >http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass >> > >> >Cheers, >> > >> >Richard >> >> well, here's a possible conundrum ... in that same package (i2c-tools), >> there appears to be an *obvious* flaw in that the "eeprog" utility uses a >> sleep that is far too short for proper operation, as described here: >> >> https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html >> >> there is a link to a patch on that page that simply cranks up a few sleep >> calls from 10usec to 5msec, which apparently solves the problem. i've been >> involved in a discussion on the i2c-tools mailing list about this very >> issue after i tripped over it, but there seems to be little enthusiasm on >> that list for "fixing" this -- i was told that people use the kernel driver >> instead and access via /sys rather than calling "eeprog". > > dl.lm-sensors.org has been down for a while and doesn't show any positive signs that > it will be back in near future. One possibility will be to use the unofficial mirrors > listed below and upgrade to version 3.1.2 > > 1. https://fossies.org/linux/misc/ > 2. http://jdelvare.nerim.net/mirror/i2c-tools/ > >> so, from my perspective, this should definitely be fixed so that "eeprog" >> functions properly, but it's not clear upstream is all that interested in it. >> what would the protocol be here? > > Since this genuinely fixes an error, we should be able to include this patch with: > "Inappropriate [bug workaround]" status. If upstream isn't interesting in a fix then "Inappropriate [upstream not interested in fix]" or "Inappropriate [upstream is dead]" would be better tags. >> rday > > Best Regards, > Maxin > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: worth adding a "git"-versioned of i2c-tools to oe-core? 2017-07-31 11:15 ` rpjday 2017-07-31 12:50 ` Maxin B. John @ 2017-07-31 18:57 ` Khem Raj 2017-08-01 13:35 ` Alexander Kanavin 1 sibling, 1 reply; 9+ messages in thread From: Khem Raj @ 2017-07-31 18:57 UTC (permalink / raw) To: rpjday, Richard Purdie; +Cc: openembedded-core [-- Attachment #1.1: Type: text/plain, Size: 2377 bytes --] On 7/31/17 4:15 AM, rpjday@crashcourse.ca wrote: > > Quoting Richard Purdie <richard.purdie@linuxfoundation.org>: > >> On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote: >>> On 07/31/2017 01:41 PM, rpjday@crashcourse.ca wrote: >>> > >>> > >>> > given that some significant changes have been made to i2c-tools >>> > since >>> > version 3.1.2, is it worth adding a git-versioned recipe of that >>> > to >>> > oe-core, >>> > and using DEFAULT_PREFERENCE to force people to select it if they >>> > want it? >>> > in particular, the code base has been restructured, and a new >>> > utility, >>> > "i2ctransfer", has been added. >>> It's better to ask the upstream to make a new release. >>> >>> We've had dual git/release recipes in the past, and they were all an >>> utter failure. In the sense, that only one version of the recipe was >>> maintained, and the other was completely neglected. >> >> Going forward we may accept patches using this instead: >> >> http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass >> >> >> Cheers, >> >> Richard > > well, here's a possible conundrum ... in that same package (i2c-tools), > there appears to be an *obvious* flaw in that the "eeprog" utility uses a > sleep that is far too short for proper operation, as described here: > > https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html > > > there is a link to a patch on that page that simply cranks up a few sleep > calls from 10usec to 5msec, which apparently solves the problem. i've been > involved in a discussion on the i2c-tools mailing list about this very > issue after i tripped over it, but there seems to be little enthusiasm on > that list for "fixing" this -- i was told that people use the kernel driver > instead and access via /sys rather than calling "eeprog" > > so, from my perspective, this should definitely be fixed so that "eeprog" > functions properly, but it's not clear upstream is all that interested > in it. > what would the protocol be here? usually, sending it upstream at same time when its proposed here for OE is best. Then you can discuss it with upstream on sides, if upstream does not want a patch, that creates some maintenance debt for future upgrades but such is life. > > rday > > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 169 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: worth adding a "git"-versioned of i2c-tools to oe-core? 2017-07-31 18:57 ` Khem Raj @ 2017-08-01 13:35 ` Alexander Kanavin 0 siblings, 0 replies; 9+ messages in thread From: Alexander Kanavin @ 2017-08-01 13:35 UTC (permalink / raw) To: Khem Raj, rpjday, Richard Purdie; +Cc: openembedded-core On 07/31/2017 09:57 PM, Khem Raj wrote: > usually, sending it upstream at same time when its proposed here for OE > is best. Then you can discuss it with upstream on sides, if upstream > does not want a patch, that creates some maintenance debt for future > upgrades but such is life. Also, if the patch is non-trivial, there is a risk it will be dropped from Yocto in the future, if rebasing it to a newer upstream release is difficult and requires specialist knowledge. It's best if upstream maintainers take it. Alex ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-08-01 13:38 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-07-31 10:41 worth adding a "git"-versioned of i2c-tools to oe-core? rpjday 2017-07-31 10:41 ` Alexander Kanavin 2017-07-31 11:00 ` Richard Purdie 2017-07-31 11:15 ` rpjday 2017-07-31 12:50 ` Maxin B. John 2017-07-31 14:10 ` Maxin B. John 2017-07-31 19:17 ` Andre McCurdy 2017-07-31 18:57 ` Khem Raj 2017-08-01 13:35 ` Alexander Kanavin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.