ser2net: Fix compilation failures due to missing TIOCSRS485 macro
PATCH 1/1 ser2net: Fix compilation failures due to missing TIOCSRS485 macro
Apply a patch sent upstream to fix a compilation failure present on some architectures which do not define the TIOCSRS485 macro and do not include the <asm-generic/ioctls.h> header. This is how the error looks like:
devcfg.c:781:34: error: 'TIOCSRS485' undeclared (first use in this function)
Patch sent upstream:
https://sourceforge.net/p/ser2net/mailman/message/32905302/
Fixes:
http://autobuild.buildroot.net/results/5376a3f64c95f14449b956df006741ffeca1350b/ http://autobuild.buildroot.net/results/d182d94562a549c79c0c9fb01777a7cb83d7ab4c/ http://autobuild.buildroot.net/results/478c5ad2f5541adef4218ad485aab4d78cf29210/
--- ...2net-0001-Fix-TIOCSRS485-undeclared-error.patch | 65 ++++++++++++++++++++ 1 files changed, 65 insertions(+), 0 deletions(-) create mode 100644 package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch
package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch new file +65 -0
@@ -0,0 +1,65 @@ +ser2net: Fix compilation failures due to missing TIOCSRS485 macro + +Patch sent upstream: + https://sourceforge.net/p/ser2net/mailman/message/32905302/ + +Signed-off-by: Vicente Olivert Riera <[email protected]> + +From: Yegor Yefremov <[email protected]> + +include <asm-generic/ioctls.h> fixes compilations for systems, +where <asm-generic/ioctls.h> won't be included automatically. + +Move special Linux includes to dataxfer.h. + +Signed-off-by: Yegor Yefremov <[email protected]> +--- + dataxfer.h | 5 +++-- + devcfg.c | 2 -- + 2 files changed, 3 insertions(+), 4 deletions(-) + +diff --git a/dataxfer.h b/dataxfer.h +index bd2665e..c3d7431 100644 +--- a/dataxfer.h ++++ b/dataxfer.h +@@ -20,8 +20,6 @@ + #ifndef DATAXFER + #define DATAXFER + +-#include <linux/serial.h> +- + #include "controller.h" + + #ifdef USE_UUCP_LOCKING +@@ -30,6 +28,9 @@ extern int uucp_locking_enabled; + + #ifdef linux + ++#include <linux/serial.h> ++#include <asm-generic/ioctls.h> ++ + #define USE_RS485_FEATURE + + /* Check, if the toolchain provides serial_rs485 structure and macros */ +diff --git a/devcfg.c b/devcfg.c +index ab819a6..1f84714 100644 +--- a/devcfg.c ++++ b/devcfg.c +@@ -18,7 +18,6 @@ + */ + + /* This code handles generating the configuration for the serial port. */ +- + #include <unistd.h> + #include <termios.h> + #include <sys/ioctl.h> +@@ -31,7 +30,6 @@ + #include <signal.h> + #include <errno.h> + #include <syslog.h> +-#include <linux/serial.h> + + #include "ser2net.h" + #include "selector.h" +-- +1.9.1
Signature · 1 line
1.7.1
PATCH 1/1 ser2net: Add a hash file
--- package/ser2net/ser2net.hash | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) create mode 100644 package/ser2net/ser2net.hash
package/ser2net/ser2net.hash new file +6 -0
@@ -0,0 +1,6 @@ +md5 cd937041144de83d41d811521e72158c ser2net-2.10.0.tar.gz +sha1 80e826ef1630cbf282d8a656754967d0f842ecba ser2net-2.10.0.tar.gz +sha224 1d851e90fde37db55109a7399f3c7166628ca23d53e87f2c65b5b01a ser2net-2.10.0.tar.gz +sha256 98f6193225338e25f35302fef5e1f16688693ed43e7b3c3e9e09187eb54547ac ser2net-2.10.0.tar.gz +sha384 b4ea0014e5ffd303f7a2a6b0cd31ec2b24640fea535cd87631aa685b7b33464261dee0e4baba8c418209767c83961dca ser2net-2.10.0.tar.gz +sha512 dd3e37619b10d8bf20d738e90c253bc2d109e0a57ee9f3a8b2a85a69399afa5a8459a4602b2856f0b655427023a36c78330851bf7f8d8da0f28d1fe22c1d5e10 ser2net-2.10.0.tar.gz
Signature · 1 line
1.7.1
PATCH 1/1 ser2net: Add a hash file
Dear Vicente Olivert Riera,
Quoted 12 lines · Vicente Olivert Riera
Signed-off-by Vicente Olivert Riera <[email protected]>--- package/ser2net/ser2net.hash | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) create mode 100644 package/ser2net/ser2net.hashpackage/ser2net/ser2net.hash new file +0
-0
package/ser2net/ser2net.hash line 6
Quoted 6 lines
package/ser2net/ser2net.hash new file +6
-0@@ -0,0 +1,6 @@ +md5 cd937041144de83d41d811521e72158c ser2net-2.10.0.tar.gz +sha1 80e826ef1630cbf282d8a656754967d0f842ecba ser2net-2.10.0.tar.gz +sha224 1d851e90fde37db55109a7399f3c7166628ca23d53e87f2c65b5b01a ser2net-2.10.0.tar.gz +sha256 98f6193225338e25f35302fef5e1f16688693ed43e7b3c3e9e09187eb54547ac ser2net-2.10.0.tar.gz +sha384 b4ea0014e5ffd303f7a2a6b0cd31ec2b24640fea535cd87631aa685b7b33464261dee0e4baba8c418209767c83961dca ser2net-2.10.0.tar.gz +sha512 dd3e37619b10d8bf20d738e90c253bc2d109e0a57ee9f3a8b2a85a69399afa5a8459a4602b2856f0b655427023a36c78330851bf7f8d8da0f28d1fe22c1d5e10 ser2net-2.10.0.tar.gz
Why having all those hashes? And the comment indicating how they have been found is missing (locally computed? found on the upstream web site).
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 ser2net: Add a hash file
Dear Thomas Petazzoni,
Quoted 9 lines · Thomas Petazzoni
Dear Vicente Olivert Riera,
Quoted 6 lines · Vicente Olivert Riera
Signed-off-by Vicente Olivert Riera <[email protected]>--- package/ser2net/ser2net.hash | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)create mode 100644 package/ser2net/ser2net.hash
Quoted 14 lines
package/ser2net/ser2net.hash line 6
Quoted 12 lines
package/ser2net/ser2net.hash new file +6
-0@@ -0,0 +1,6 @@ +md5 cd937041144de83d41d811521e72158c ser2net-2.10.0.tar.gz +sha1 80e826ef1630cbf282d8a656754967d0f842ecba ser2net-2.10.0.tar.gz +sha224 1d851e90fde37db55109a7399f3c7166628ca23d53e87f2c65b5b01a ser2net-2.10.0.tar.gz +sha256 98f6193225338e25f35302fef5e1f16688693ed43e7b3c3e9e09187eb54547ac ser2net-2.10.0.tar.gz +sha384 b4ea0014e5ffd303f7a2a6b0cd31ec2b24640fea535cd87631aa685b7b33464261dee0e4baba8c418209767c83961dca ser2net-2.10.0.tar.gz +sha512 dd3e37619b10d8bf20d738e90c253bc2d109e0a57ee9f3a8b2a85a69399afa5a8459a4602b2856f0b655427023a36c78330851bf7f8d8da0f28d1fe22c1d5e10 ser2net-2.10.0.tar.gzWhy having all those hashes?
Why not? Those are all the hashes supported in Buildroot. The more we have the better.
Quoted 3 lines
And the comment indicating how they have
been found is missing (locally computed? found on the upstream web site).
I haven't added any comment because those hashes were locally computed. Do I need to add a comment explain that?
Signature · 1 line
Vincent
PATCH 1/1 ser2net: Add a hash file
Dear Vicente Olivert Riera,
Quoted 4 lines · Vicente Olivert Riera
Quoted 1 line
Why having all those hashes?
Why not? Those are all the hashes supported in Buildroot. The more we have the better.
I disagree: more hashes means more work to do when bumping the package. Either one strong hash, or two weaker hashes should be sufficient IMO.
Something to be discussed at the meeting maybe?
Quoted 6 lines
Quoted 3 lines
And the comment indicating how they have
been found is missing (locally computed? found on the upstream web site).I haven't added any comment because those hashes were locally computed. Do I need to add a comment explain that?
Yes, I believe so.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 ser2net: Add a hash file
Dear Thomas Petazzoni,
Quoted 11 lines · Thomas Petazzoni
Dear Vicente Olivert Riera,
Quoted 4 lines · Vicente Olivert Riera
Quoted 1 line
Why having all those hashes?
Why not? Those are all the hashes supported in Buildroot. The more we have the better.
I disagree: more hashes means more work to do when bumping the package. Either one strong hash, or two weaker hashes should be sufficient IMO.
More work? I disagree. I created the hash file with a one-liner command:
for i in md5 sha1 sha224 sha256 sha384 sha512; do echo $i ${i}sum ser2net-2.10.0.tar.gz >> ../package/ser2net/ser2net.hash; done
Quoted 10 lines
Something to be discussed at the meeting maybe?
Quoted 6 lines
Quoted 3 lines
And the comment indicating how they have
been found is missing (locally computed? found on the upstream web site).I haven't added any comment because those hashes were locally computed. Do I need to add a comment explain that?
Yes, I believe so.
No problem, I can resend the patch adding that comment. Or maybe it's easier if you or Peter do it, since is a trivial change and you are the ones who will commit the patch at the end.
Quoted 4 lines
Best regards,
Thomas
Signature · 1 line
Vincent
PATCH 1/1 ser2net: Add a hash file
In reply to Thomas PetazzoniQuoted 6 lines · Thomas Petazzoni
Dear Vicente Olivert Riera,
Quoted 2 lines · Vicente Olivert Riera
Quoted 1 line
Why having all those hashes?
Quoted 7 lines
Quoted 2 lines
Why not? Those are all the hashes supported in Buildroot. The more we have the better.
I disagree: more hashes means more work to do when bumping the package. Either one strong hash, or two weaker hashes should be sufficient IMO.
Something to be discussed at the meeting maybe?
I am curious, what's the point of supporting more than one hash types? Why not support only the strongest one?
Signature · 1 line
markos
PATCH 1/1 ser2net: Add a hash file
Quoted 10 lines · Markos Chandras
Quoted 9 lines · Thomas Petazzoni
Dear Vicente Olivert Riera,
Quoted 4 lines · Vicente Olivert Riera
Quoted 1 line
Why having all those hashes?
Why not? Those are all the hashes supported in Buildroot. The more we have the better.
Quoted 7 lines
Quoted 4 lines
I disagree: more hashes means more work to do when bumping the package. Either one strong hash, or two weaker hashes should be sufficient IMO.
Something to be discussed at the meeting maybe?
I am curious, what's the point of supporting more than one hash types? Why not support only the strongest one?
The hashes have a limited range of values, so it's possible to have two inputs which produce the same hash. It's very unlikely, but it can happen. So, supporting more than one hash type is to increase the security. It's very unlikely that two inputs generate the same hash for one algorithm, and it's even more unlikely if those two input generate the same hashes for two different algorithms, and more for three algorithms, etc.
Signature · 1 line
Vincent
PATCH 1/1 ser2net: Add a hash file
In reply to Markos ChandrasQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Markos" == Markos Chandras <[email protected]> writes:
Hi,
Quoted 7 lines
Quoted 4 lines
I disagree: more hashes means more work to do when bumping the package. Either one strong hash, or two weaker hashes should be sufficient IMO.
Something to be discussed at the meeting maybe?
I am curious, what's the point of supporting more than one hash types? Why not support only the strongest one?
The point is that we want to use the hashes published by upstream if available, and different projects use different hashes.
We could decide on one specific hash type (the "best one") to use whenever we calculate a hash ourselves through.
Looking at what we have, that should probably be sha256:
find package -name \*.hash|xargs grep -l Locally|xargs tail -n 1 ==> package/gnupg/gnupg.hash <==
sha256 b7b5fdda78849955e0cdbc5a085f3a08f8b7fba126c622085debb62def5d6388 gnupg-1.4.18.tar.bz2
==> package/libksba/libksba.hash <==
sha256 bc96b95516bd2b67f413bc8b5cc5a75a2583c6e666d24dfd0d5bcc6b1aab46f9 libksba-1.3.1.tar.bz2
==> package/libassuan/libassuan.hash <==
sha256 39f8a7c9349aaaf7ccd937b90660153ec4d2d4df2465018754e5bcae5b1db77b libassuan-2.1.2.tar.bz2
==> package/openssh/openssh.hash <==
sha256 b2f8394eae858dabbdef7dac10b99aec00c95462753e80342e530bbb6f725507 openssh-6.7p1.tar.gz
==> package/dnsmasq/dnsmasq.hash <==
sha256 7d0bd23f5d74b3a6b26a75d5ffcf9db81d461b47cbe578cb65a83a98008600b1 dnsmasq-2.72.tar.xz
==> package/atftp/atftp.hash <==
sha1 fc9e9f821dfd2f257b4a5c32b948ed60b4e31fd1 atftp-0.7.1.tar.gz
==> package/gnupg2/gnupg2.hash <==
sha256 7758e30dc382ae7a7167ed41b7f936aa50af5ea2d6fccdef663b5b750b65b8e0 gnupg-2.0.26.tar.bz2
==> package/dejavu/dejavu.hash <==
sha1 33fa825aa1dd44ce23a11af92b3078e978ff513d dejavu-fonts-ttf-2.34.tar.bz2
==> package/fan-ctrl/fan-ctrl.hash <==
sha1 d8ba5bac15e90c36a4e908ca1c98fac83bf702ea fan-ctrl.c?revision=1.3
==> package/gnutls/gnutls.hash <==
sha256 4762afab5e1b9e829c5f53d2b00cd5e41d43fa6d035efcf239e3fe0459134d45 gnutls-3.2.18.tar.xz
==> package/bash/bash.hash <==
sha256 afc687a28e0e24dc21b988fa159ff9dbcf6b7caa92ade8645cc6d5605cd024d4 bash-4.3.tar.gz
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 ser2net: Add a hash file
In reply to Markos ChandrasQuoted 5 lines · Markos Chandras
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
Why having all those hashes?
Why not? Those are all the hashes supported in Buildroot. The more we have the better.
Quoted 7 lines
Quoted 4 lines
I disagree: more hashes means more work to do when bumping the package. Either one strong hash, or two weaker hashes should be sufficient IMO.
Something to be discussed at the meeting maybe?
I am curious, what's the point of supporting more than one hash types? Why not support only the strongest one?
Normally you want to use upstream-provided hashes and they're not of the same class for security.
You've got basically 3 kinds of security:
1) Upstream releases new version/software with hashes.
2) Upstream releases tarball signed (pgp).
3) Upstream just releases.
1 and 2 can intersect which is great.
Announcements ideally go into a mailing list hence the chance of compromising that is far lower than a hash file or note in the web page (which can be the same hosting site/server as the tarball). If you use a signed pgp that reduces the chance of website compromise since ideally the key is stored elsewhere as well.
If the hash/signature is on a mailing list archive the same happens (another site, harder to get all the pieces together).
If the release is using a weak hash (md5, sha1) for which there are possible collissions using two hashes makes it extremely difficult to collide in a useful way.
(re)computing the hash for a bump/package requires that people check the signature and we trust that they did it right (did anyone recheck besides Baruch with openssh?) instead of just sha256sum(ing) the file and sticking that result.
I think i've covered most of the cases here :)
Regards.
PATCH 1/1 ser2net: Add a hash file
Quoted 31 lines · Gustavo Zacarias
Quoted 5 lines · Markos Chandras
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
Why having all those hashes?
Why not? Those are all the hashes supported in Buildroot. The more we have the better.
Quoted 7 lines
Quoted 4 lines
I disagree: more hashes means more work to do when bumping the package. Either one strong hash, or two weaker hashes should be sufficient IMO.
Something to be discussed at the meeting maybe?
I am curious, what's the point of supporting more than one hash types? Why not support only the strongest one?
Normally you want to use upstream-provided hashes and they're not of the same class for security.
You've got basically 3 kinds of security:
1) Upstream releases new version/software with hashes.
2) Upstream releases tarball signed (pgp).
3) Upstream just releases.1 and 2 can intersect which is great.
Announcements ideally go into a mailing list hence the chance of compromising that is far lower than a hash file or note in the web page (which can be the same hosting site/server as the tarball). If you use a signed pgp that reduces the chance of website compromise since ideally the key is stored elsewhere as well.
If the hash/signature is on a mailing list archive the same happens (another site, harder to get all the pieces together).
If the release is using a weak hash (md5, sha1) for which there are
Quoted 9 lines
possible collissions using two hashes makes it extremely difficult to collide in a useful way.
(re)computing the hash for a bump/package requires that people check the signature and we trust that they did it right (did anyone recheck besides Baruch with openssh?) instead of just sha256sum(ing) the file and sticking that result.
I think i've covered most of the cases here :)
Regards.
I understand that, but realistically speaking, supporting so many different hashes is not very efficient. If an upstream uses weak hashes for released tarballs, just verify the weak hash on your local pc and then generate a strong hash yourself. Is there really a point having a week md5 and a strong sha256 hash at the same time?
Signature · 1 line
markos
PATCH 1/1 ser2net: Add a hash file
Quoted 5 lines · Markos Chandras
I understand that, but realistically speaking, supporting so many different hashes is not very efficient. If an upstream uses weak hashes for released tarballs, just verify the weak hash on your local pc and then generate a strong hash yourself. Is there really a point having a week md5 and a strong sha256 hash at the same time?
"strong" hashes are so for now, weak hashes were strong at the time too remember, they're, grossly said, glorified checksums/CRCs (which were also considered well enough until the data set and computation power grew). If you truly want to ensure a certain degree of tamper resistance you need to go to the 2-way collision.
After all a single value of 256 or 512 bits representing a file of 1 MB of compressed data is bound to hit some issue eventually.
With two different hashing methods it's statistically very complex to win the lottery.
Regards.
PATCH 1/1 ser2net: Add a hash file
Quoted 7 lines · Gustavo Zacarias
Quoted 5 lines · Markos Chandras
I understand that, but realistically speaking, supporting so many different hashes is not very efficient. If an upstream uses weak hashes for released tarballs, just verify the weak hash on your local pc and then generate a strong hash yourself. Is there really a point having a week md5 and a strong sha256 hash at the same time?
Quoted 11 lines
"strong" hashes are so for now, weak hashes were strong at the time too remember, they're, grossly said, glorified checksums/CRCs (which were also considered well enough until the data set and computation power grew). If you truly want to ensure a certain degree of tamper resistance you need to go to the 2-way collision.
After all a single value of 256 or 512 bits representing a file of 1 MB of compressed data is bound to hit some issue eventually.
With two different hashing methods it's statistically very complex to win the lottery.
Regards.
Sure. But this probably is not a strong argument because for all I know they may find sha256 broken tomorrow morning and you have to update all the buildroot packages using that hash to verify the tarball. If you think something is "not strong enough" then don't use it :) Perhaps it's best if buildroot supported the two strongest algorithms and request that information for every package? I really see no point supporting eg md5 since we know it's weak. Anyway, that's my personal opinion, I just feel there is no clear "rule" here so developers are free to use whatever they want which may not always be acceptable by the maintainers :)
Signature · 1 line
markos
PATCH 1/1 ser2net: Add a hash file
Quoted 10 lines · Markos Chandras
Sure. But this probably is not a strong argument because for all I know they may find sha256 broken tomorrow morning and you have to update all the buildroot packages using that hash to verify the tarball. If you think something is "not strong enough" then don't use it :) Perhaps it's best if buildroot supported the two strongest algorithms and request that information for every package? I really see no point supporting eg md5 since we know it's weak. Anyway, that's my personal opinion, I just feel there is no clear "rule" here so developers are free to use whatever they want which may not always be acceptable by the maintainers :)
Those last lines ^^^ :)
If upstream maintainers ship with md5 there's not much we can do about it. In the end we do hashes for integrity above everything else and we don't want to get in the way of new/bumped packages hence hashes aren't mandatory for now (it would be good to have them all though). Regards.
PS: and to detect sucky upstream that switches tarballs without bumping versions to cover their lower heads.
PATCH 1/1 ser2net: Add a hash file
In reply to Vicente Olivert RieraDear Vicente Olivert Riera,
Quoted 12 lines · Vicente Olivert Riera
Signed-off-by Vicente Olivert Riera <[email protected]>--- package/ser2net/ser2net.hash | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) create mode 100644 package/ser2net/ser2net.hashpackage/ser2net/ser2net.hash new file +0
-0
package/ser2net/ser2net.hash line 6
Quoted 6 lines
package/ser2net/ser2net.hash new file +6
-0@@ -0,0 +1,6 @@ +md5 cd937041144de83d41d811521e72158c ser2net-2.10.0.tar.gz +sha1 80e826ef1630cbf282d8a656754967d0f842ecba ser2net-2.10.0.tar.gz +sha224 1d851e90fde37db55109a7399f3c7166628ca23d53e87f2c65b5b01a ser2net-2.10.0.tar.gz +sha256 98f6193225338e25f35302fef5e1f16688693ed43e7b3c3e9e09187eb54547ac ser2net-2.10.0.tar.gz +sha384 b4ea0014e5ffd303f7a2a6b0cd31ec2b24640fea535cd87631aa685b7b33464261dee0e4baba8c418209767c83961dca ser2net-2.10.0.tar.gz +sha512 dd3e37619b10d8bf20d738e90c253bc2d109e0a57ee9f3a8b2a85a69399afa5a8459a4602b2856f0b655427023a36c78330851bf7f8d8da0f28d1fe22c1d5e10 ser2net-2.10.0.tar.gz
Following the discussion, can you resend a patch that 1/ has a more reasonable number of hashes, and 2/ declares how the hash was found (locally computed, indicated on the upstream web site), etc.
In the mean time, I'll mark your patch as 'Changes Requested' in patchwork.
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 ser2net: Fix compilation failures due to missing TIOCSRS485 macro
In reply to Vicente Olivert RieraQuoted 94 lines · Vicente Olivert Riera
Apply a patch sent upstream to fix a compilation failure present on some architectures which do not define the TIOCSRS485 macro and do not include the <
asm-generic/ioctls.h> header. This is how the error looks like:devcfg.c:781:34: error: 'TIOCSRS485' undeclared (first use in this function)
Patch sent upstream:
https://sourceforge.net/p/ser2net/mailman/message/32905302/Fixes:
http://autobuild.buildroot.net/results/5376a3f64c95f14449b956df006741ffeca1350b/ http://autobuild.buildroot.net/results/d182d94562a549c79c0c9fb01777a7cb83d7ab4c/ http://autobuild.buildroot.net/results/478c5ad2f5541adef4218ad485aab4d78cf29210/Signed-off-by Vicente Olivert Riera <[email protected]>--- ...2net-0001-Fix-TIOCSRS485-undeclared-error.patch | 65 ++++++++++++++++++++ 1 files changed, 65 insertions(+), 0 deletions(-) create mode 100644 package/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patchpackage/ser2net/ser2net-0001-Fix-TIOCSRS485-undeclared-error.patch new file +65
-1@@ -0,0 +1,65 @@ +ser2net: Fix compilation failures due to missing TIOCSRS485 macro + +Patch sent upstream: + https://sourceforge.net/p/ser2net/mailman/message/32905302/ + +Signed-off-by: Vicente Olivert Riera <[email protected]> + +From: Yegor Yefremov <[email protected]> + +include <asm-generic/ioctls.h> fixes compilations for systems, +where <asm-generic/ioctls.h> won't be included automatically. + +Move special Linux includes to dataxfer.h. + +Signed-off-by: Yegor Yefremov <[email protected]> +--- + dataxfer.h | 5 +++-- + devcfg.c | 2 -- + 2 files changed, 3 insertions(+), 4 deletions(-) + +diff --git a/dataxfer.h b/dataxfer.h +index bd2665e..c3d7431 100644 +--- a/dataxfer.h ++++ b/dataxfer.h +@@ -20,8 +20,6 @@ + #ifndef DATAXFER + #define DATAXFER + +-#include <linux/serial.h> +- + #include "controller.h" + + #ifdef USE_UUCP_LOCKING +@@ -30,6 +28,9 @@ extern int uucp_locking_enabled; + + #ifdef linux + ++#include <linux/serial.h> ++#include <asm-generic/ioctls.h> ++ + #define USE_RS485_FEATURE + + /* Check, if the toolchain provides serial_rs485 structure and macros */ +diff --git a/devcfg.c b/devcfg.c +index ab819a6..1f84714 100644 +--- a/devcfg.c ++++ b/devcfg.c +@@ -18,7 +18,6 @@ + */ + + /* This code handles generating the configuration for the serial port. */ +- + #include <unistd.h> + #include <termios.h> + #include <sys/ioctl.h> +@@ -31,7 +30,6 @@ + #include <signal.h> + #include <errno.h> + #include <syslog.h> +-#include <linux/serial.h> + + #include "ser2net.h" + #include "selector.h" +-- +1.9.1 --
Quoted 1 line
1.7.1
PATCH 1/1 ser2net: Fix compilation failures due to missing TIOCSRS485 macro
Dear Yegor Yefremov,
Quoted 1 line · Yegor Yefremov
Signed-off-by Yegor Yefremov <[email protected]>
If you actually agree with the patch, or tested it, or have reviewed it, you should give a Tested-by, Acked-by or Reviewed-by, not a Signed-off-by. Please see
http://buildroot.org/downloads/manual/manual.html#_reviewing_and_testing_patches.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 ser2net: Fix compilation failures due to missing TIOCSRS485 macro
Quoted 10 lines · Thomas Petazzoni
Dear Yegor Yefremov,
Quoted 1 line · Yegor Yefremov
Signed-off-by Yegor Yefremov <[email protected]>If you actually agree with the patch, or tested it, or have reviewed it, you should give a Tested-by, Acked-by or Reviewed-by, not a Signed-off-by. Please see
http://buildroot.org/downloads/manual/manual.html#_reviewing_and_testing_patches.
Then I'll choose
I was actually the author of the upstream ser2net patch, that's why I thought SoB would be OK :-)
Yegor
PATCH 1/1 ser2net: Fix compilation failures due to missing TIOCSRS485 macro
In reply to Vicente Olivert RieraQuoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
Apply a patch sent upstream to fix a compilation failure present on some architectures which do not define the TIOCSRS485 macro and do not include the <
asm-generic/ioctls.h> header. This is how the error looks like:devcfg.c:781:34: error: 'TIOCSRS485' undeclared (first use in this function)
Patch sent upstream:
Quoted 8 lines
https://sourceforge.net/p/ser2net/mailman/message/32905302/Fixes:
http://autobuild.buildroot.net/results/5376a3f64c95f14449b956df006741ffeca1350b/ http://autobuild.buildroot.net/results/d182d94562a549c79c0c9fb01777a7cb83d7ab4c/ http://autobuild.buildroot.net/results/478c5ad2f5541adef4218ad485aab4d78cf29210/Signed-off-by Vicente Olivert Riera <[email protected]>
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard