| Message ID | 5d4e572b6a29cdf484a8df1562993d68206022dd.1514719506.git.baruch@tkos.co.il |
|---|---|
| State | Accepted |
| Headers | show |
| Series | eeprog: fix homepage link | expand |
Hello, On Sun, 31 Dec 2017 13:25:06 +0200, Baruch Siach wrote: > The current link leads to a 400 Bad Request error page. > > Cc: Matt Weber <matthew.weber@rockwellcollins.com> > Signed-off-by: Baruch Siach <baruch@tkos.co.il> > --- > package/eeprog/Config.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to master, thanks. However, do we still need this package, now that i2c-tools also builds/installs eeprog ? Best regards, Thomas
Hi Thomas, On Sun, Dec 31, 2017 at 12:48:12PM +0100, Thomas Petazzoni wrote: > On Sun, 31 Dec 2017 13:25:06 +0200, Baruch Siach wrote: > > The current link leads to a 400 Bad Request error page. > > > > Cc: Matt Weber <matthew.weber@rockwellcollins.com> > > Signed-off-by: Baruch Siach <baruch@tkos.co.il> > > --- > > package/eeprog/Config.in | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Applied to master, thanks. However, do we still need this package, now > that i2c-tools also builds/installs eeprog ? Probably not. Event worse. When both i2c-tools and eeprog are enabled, the target /usr/bin/eeprog depends on the build order. Has the autobuilder caught this file overwrite? Are you OK with dropping eeprog? Matt? baruch
Hello, On Sun, 31 Dec 2017 14:26:18 +0200, Baruch Siach wrote: > > Applied to master, thanks. However, do we still need this package, now > > that i2c-tools also builds/installs eeprog ? > > Probably not. Do they provide the same features ? > Event worse. When both i2c-tools and eeprog are enabled, the > target /usr/bin/eeprog depends on the build order. Has the autobuilder caught > this file overwrite? It will, be currently such errors are not errors, but warnings: they don't make the build fail. Yann recently posted a patch that would allow to turn such warnings into errors, but there are so many of such overwrites today that enabling such an option in the autobuilders would turn almost all results to NOK. > Are you OK with dropping eeprog? Matt? I don't use eeprog, so I don't really care. But if the standalone eeprog and the one on i2c-tools are equivalent, I think it makes sense to keep the one from i2c-tools. Best regards, Thomas
Hi Thomas, On Sun, Dec 31, 2017 at 01:54:33PM +0100, Thomas Petazzoni wrote: > On Sun, 31 Dec 2017 14:26:18 +0200, Baruch Siach wrote: > > > Applied to master, thanks. However, do we still need this package, now > > > that i2c-tools also builds/installs eeprog ? > > > > Probably not. > > Do they provide the same features ? They are both based on the same code. It looks like i2c-tools adopted eeprog after the last eeprog release in February 2004. > > Event worse. When both i2c-tools and eeprog are enabled, the target > > /usr/bin/eeprog depends on the build order. Has the autobuilder caught > > this file overwrite? > > It will, be currently such errors are not errors, but warnings: they > don't make the build fail. Yann recently posted a patch that would > allow to turn such warnings into errors, but there are so many of such > overwrites today that enabling such an option in the autobuilders would > turn almost all results to NOK. > > > Are you OK with dropping eeprog? Matt? > > I don't use eeprog, so I don't really care. But if the standalone > eeprog and the one on i2c-tools are equivalent, I think it makes sense > to keep the one from i2c-tools. OK. Let's give Matt some time to recover from the holidays and respond before I send a patch to remove the eeprog package. baruch
Hello, On Sun, 31 Dec 2017 15:11:08 +0200, Baruch Siach wrote: > They are both based on the same code. It looks like i2c-tools adopted eeprog > after the last eeprog release in February 2004. OK. > OK. Let's give Matt some time to recover from the holidays and respond before > I send a patch to remove the eeprog package. Sounds good. Thanks! Thomas
Baruch, Thomas, On Sun, Dec 31, 2017 at 10:08 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > >> OK. Let's give Matt some time to recover from the holidays and respond before >> I send a patch to remove the eeprog package. > Removal sounds good to me. Angelo, thanks for bumping i2c-tools! Lots of good stuff with this cleanup and the new tools we now install. Matt
>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes: > The current link leads to a 400 Bad Request error page. > Cc: Matt Weber <matthew.weber@rockwellcollins.com> > Signed-off-by: Baruch Siach <baruch@tkos.co.il> Committed to 2017.11.x, thanks.
>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes: > The current link leads to a 400 Bad Request error page. > Cc: Matt Weber <matthew.weber@rockwellcollins.com> > Signed-off-by: Baruch Siach <baruch@tkos.co.il> Committed to 2017.02.x, thanks.
diff --git a/package/eeprog/Config.in b/package/eeprog/Config.in index ff313bdbae96..73582c70f9d4 100644 --- a/package/eeprog/Config.in +++ b/package/eeprog/Config.in @@ -3,4 +3,4 @@ config BR2_PACKAGE_EEPROG help Simple tool to read/write i2c eeprom chips. - http://codesink.org/eeprog.html + http://www.codesink.org/eeprog.html
The current link leads to a 400 Bad Request error page. Cc: Matt Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> --- package/eeprog/Config.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)