| Message ID | 1488322477-25447-1-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Accepted |
| Headers | show |
Thomas, All, On 2017-02-28 23:54 +0100, Thomas Petazzoni spake thusly: > The ncftp build process tries to build and run a small program called > ccdv to beautify the build process output. If it manages to build and > run it, then it uses it. > > Unfortunately, this doesn't work well when the target architecture is > close to the host architecture, but not exactly the same. Because both > architectures are close to each other, the test run of ccdv succeeds, > but real use of ccdv during ncftp build process causes an Illegal > instruction issue. > > This for example happens with the CodeSourcery AMD64 toolchain, on a > build machine running an i7-4600U, and has been detected in the > autobuilders since the CodeSourcery AMD64 toolchain was upgraded at > the end of January: > > http://autobuild.buildroot.net/?reason=ncftp-3.2.6 > > The issue was also reported by Christopher Arguin back in July 2016: > > http://lists.busybox.net/pipermail/buildroot/2016-July/168026.html > > and at the time, we identified that simply disabling the ccdv tool, by > passing --disable-ccdv, was enough to solve the issue. But Christopher > never submitted the patch, so the problem remained unfixed. > > Therefore, we pass --disable-ccdv to the configure script, which > fixes: > > http://autobuild.buildroot.net/results/6eadad0e879ca70bb07b13b4196d42c64b11699f/ > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Regards, Yann E. MORIN. > --- > package/ncftp/ncftp.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/package/ncftp/ncftp.mk b/package/ncftp/ncftp.mk > index 5c88556..11bfcca 100644 > --- a/package/ncftp/ncftp.mk > +++ b/package/ncftp/ncftp.mk > @@ -12,6 +12,7 @@ NCFTP_LICENSE = Clarified Artistic License > NCFTP_LICENSE_FILES = doc/LICENSE.txt > > NCFTP_DEPENDENCIES = host-autoconf > +NCFTP_CONF_OPTS = --disable-ccdv > > # The bundled configure script is generated by autoconf 2.13 and doesn't > # detect cross-compilation correctly. Therefore, we have to regenerate it. > -- > 2.7.4 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hello, On Tue, 28 Feb 2017 23:54:37 +0100, Thomas Petazzoni wrote: > The ncftp build process tries to build and run a small program called > ccdv to beautify the build process output. If it manages to build and > run it, then it uses it. > > Unfortunately, this doesn't work well when the target architecture is > close to the host architecture, but not exactly the same. Because both > architectures are close to each other, the test run of ccdv succeeds, > but real use of ccdv during ncftp build process causes an Illegal > instruction issue. > > This for example happens with the CodeSourcery AMD64 toolchain, on a > build machine running an i7-4600U, and has been detected in the > autobuilders since the CodeSourcery AMD64 toolchain was upgraded at > the end of January: > > http://autobuild.buildroot.net/?reason=ncftp-3.2.6 > > The issue was also reported by Christopher Arguin back in July 2016: > > http://lists.busybox.net/pipermail/buildroot/2016-July/168026.html > > and at the time, we identified that simply disabling the ccdv tool, by > passing --disable-ccdv, was enough to solve the issue. But Christopher > never submitted the patch, so the problem remained unfixed. > > Therefore, we pass --disable-ccdv to the configure script, which > fixes: > > http://autobuild.buildroot.net/results/6eadad0e879ca70bb07b13b4196d42c64b11699f/ > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > --- > package/ncftp/ncftp.mk | 1 + > 1 file changed, 1 insertion(+) Applied to master, thanks. Peter, I believe this one qualifies for the LTS branch. Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, > Applied to master, thanks. Peter, I believe this one qualifies for the > LTS branch. Committed to 2017.02.x, thanks.
Peter, On Thu, Mar 2, 2017 at 8:28 AM, Peter Korsgaard <peter@korsgaard.com> wrote: >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > Hi, > > > Applied to master, thanks. Peter, I believe this one qualifies for the > > LTS branch. > > Committed to 2017.02.x, thanks. Are you able to download this tarball with the hash indicated in ncftp.hash? I keep getting an error: ERROR: ncftp-3.2.6-src.tar.xz has wrong sha256 hash: ERROR: expected: 7abd3e8f848f0efb4bb6a4bc5da58a59524d4378fc8d70a52adb0fe1fd00b89d ERROR: got : 5f200687c05d0807690d9fb770327b226f02dd86155b49e750853fce4e31098d ERROR: Incomplete download, or man-in-the-middle (MITM) attack Danomi - > -- > Bye, Peter Korsgaard > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hello, On Thu, 2 Mar 2017 11:07:55 -0800, Danomi Manchego wrote: > Are you able to download this tarball with the hash indicated in > ncftp.hash? I keep getting an error: > > ERROR: ncftp-3.2.6-src.tar.xz has wrong sha256 hash: > ERROR: expected: > 7abd3e8f848f0efb4bb6a4bc5da58a59524d4378fc8d70a52adb0fe1fd00b89d > ERROR: got : > 5f200687c05d0807690d9fb770327b226f02dd86155b49e750853fce4e31098d > ERROR: Incomplete download, or man-in-the-middle (MITM) attack It seems like the tarball has been re-generated and republished by upstream. Indeed, a diff between the two shows: -3.2.6, 2016-12-04 +3.2.6, 2016-09-23 (where the - lines are the tarball from the upstream site, which is newer, and the + lines are the tarball from sources.buildroot.net). And interestingly, the web page at http://www.ncftp.com/ncftp/doc/changelog.html pretends that the 3.2.6 version has been released on 2016-11-27... And the diffstat is actually not that small: Strn/DStrInternal.h | 4 Strn/Strn.h | 2 autoconf_local/acconfig.h | 8 autoconf_local/aclocal.m4 | 116 --- config.h.in | 8 configure | 1701 ++++++++++++++++++++-------------------------- configure.in | 9 doc/CHANGELOG.txt | 2 libncftp/c_opennologin.c | 4 libncftp/ftp.c | 31 libncftp/ftw.c | 2 libncftp/io_getmem.c | 2 libncftp/io_list.c | 6 libncftp/io_sendfile.c | 4 libncftp/io_util.c | 4 libncftp/ncftp.h | 2 libncftp/open.c | 4 libncftp/rftw.c | 2 libncftp/rglobr.c | 2 libncftp/u_decodehost.c | 2 libncftp/u_decodeurl.c | 2 libncftp/u_getpass.c | 2 libncftp/u_misc.c | 2 libncftp/u_pathcat.c | 4 libncftp/u_scram.c | 2 libncftp/wincfg.h | 1 ncftp/cmds.c | 38 - ncftp/gl_getline.c | 26 ncftp/ls.c | 9 ncftp/ls.h | 9 ncftp/progress.c | 9 ncftp/readln.c | 4 ncftp/shell.h | 10 ncftp/spoolutil.c | 8 ncftp/version.c | 2 sh/mksrctar.sh | 1 sh_util/gpshare.c | 12 sh_util/ncftpbatch.c | 110 -- sh_util/ncftpget.c | 6 sh_util/ncftpls.c | 5 sh_util/ncftpput.c | 14 sio/DNSUtil.c | 4 sio/Makefile.in | 16 sio/SBind.c | 35 sio/SConnect.c | 9 sio/SNew.c | 115 --- sio/SRead.c | 6 sio/StrAddr.c | 6 sio/config.h.in | 24 sio/configure.in | 8 sio/sio.h | 18 sio/wincfg.h | 1 vis/bmed.c | 13 vis/wgets.c | 12 vis/wgets.h | 7 vis/wutil.c | 6 vis/wutil.h | 6 win/bmed/bmed.vcproj | 4 I'm not sure what to do in this case? Blindly take the new upstream version? Complain to upstream? Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, > I'm not sure what to do in this case? Blindly take the new upstream > version? Complain to upstream? We should probably update. I have mailed support@ncftp.com asking them what happened. I will let you know when/if I hear back from them.
On 03-03-17 21:50, Peter Korsgaard wrote: >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > Hi, > > > I'm not sure what to do in this case? Blindly take the new upstream > > version? Complain to upstream? > > We should probably update. I have mailed support@ncftp.com asking them > what happened. > > I will let you know when/if I hear back from them. This is terribly annoying, however, since we just released 2017.02 with the 7abd3e8f hash. So now people are downloading it from sources.buildroot.net. But if we apply the new hash and update sources.buildroot.net, people using the 2017.02 release have no way to download ncftp anymore... Regards, Arnout
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > On 03-03-17 21:50, Peter Korsgaard wrote: >>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: >> >> Hi, >> >> > I'm not sure what to do in this case? Blindly take the new upstream >> > version? Complain to upstream? >> >> We should probably update. I have mailed support@ncftp.com asking them >> what happened. >> >> I will let you know when/if I hear back from them. > This is terribly annoying, however, since we just released 2017.02 with the > 7abd3e8f hash. So now people are downloading it from sources.buildroot.net. But > if we apply the new hash and update sources.buildroot.net, people using the > 2017.02 release have no way to download ncftp anymore... Indeed :/ We can naturally fix it in 2017.02.1, but still. Lets see what the ncftp guys say.
>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes: >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Hi, >> I'm not sure what to do in this case? Blindly take the new upstream >> version? Complain to upstream? > We should probably update. I have mailed support@ncftp.com asking them > what happened. > I will let you know when/if I hear back from them. After sending them a detailed mail explaining the issue with them updating the tarballs and a diff of the changes, I got the following answer: > Is this update intentional? Why was the tarball regenerated? Yes. Which wasn't exactly helpful :/ I'll send a patch to update our hash, but I will NOT update the tarball on sources.buildroot.net yet.
Hello, On Tue, 07 Mar 2017 17:48:08 +0100, Peter Korsgaard wrote: > >>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes: > > >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > Hi, > > >> I'm not sure what to do in this case? Blindly take the new upstream > >> version? Complain to upstream? > > > We should probably update. I have mailed support@ncftp.com asking them > > what happened. > > > I will let you know when/if I hear back from them. > > After sending them a detailed mail explaining the issue with them > updating the tarballs and a diff of the changes, I got the following > answer: > > > Is this update intentional? Why was the tarball regenerated? > > Yes. > > Which wasn't exactly helpful :/ I'll send a patch to update our hash, > but I will NOT update the tarball on sources.buildroot.net yet. Isn't sources.buildroot.net going to automatically pick up the new tarball once you change the hash? Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: >> > Is this update intentional? Why was the tarball regenerated? >> >> Yes. >> >> Which wasn't exactly helpful :/ I'll send a patch to update our hash, >> but I will NOT update the tarball on sources.buildroot.net yet. > Isn't sources.buildroot.net going to automatically pick up the new > tarball once you change the hash? Hmm, I guess so. It just runs 'make -k source'. I guess we should wait until we are ready to release 2017.02.1 then.
On 07-03-17 22:10, Peter Korsgaard wrote: >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > > >> > Is this update intentional? Why was the tarball regenerated? > >> > >> Yes. > >> > >> Which wasn't exactly helpful :/ I'll send a patch to update our hash, > >> but I will NOT update the tarball on sources.buildroot.net yet. > > > Isn't sources.buildroot.net going to automatically pick up the new > > tarball once you change the hash? > > Hmm, I guess so. It just runs 'make -k source'. I guess we should wait > until we are ready to release 2017.02.1 then. So this issue missed 2017.02.1 :-) However, we can do a workaround: in master, we can use the tar.gz file instead of the tar.xz. That way, there can be two separate tarballs on sources.buildroot.net for the two versions. Regards, Arnout
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > On 07-03-17 22:10, Peter Korsgaard wrote: >>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: >> >> >> >> > Is this update intentional? Why was the tarball regenerated? >> >> >> >> Yes. >> >> >> >> Which wasn't exactly helpful :/ I'll send a patch to update our hash, >> >> but I will NOT update the tarball on sources.buildroot.net yet. >> >> > Isn't sources.buildroot.net going to automatically pick up the new >> > tarball once you change the hash? >> >> Hmm, I guess so. It just runs 'make -k source'. I guess we should wait >> until we are ready to release 2017.02.1 then. > So this issue missed 2017.02.1 :-) Argh, yes :/ > However, we can do a workaround: in master, we can use the tar.gz file instead > of the tar.xz. That way, there can be two separate tarballs on > sources.buildroot.net for the two versions. Ahh yes, good idea - I'll send a patch doing that.
diff --git a/package/ncftp/ncftp.mk b/package/ncftp/ncftp.mk index 5c88556..11bfcca 100644 --- a/package/ncftp/ncftp.mk +++ b/package/ncftp/ncftp.mk @@ -12,6 +12,7 @@ NCFTP_LICENSE = Clarified Artistic License NCFTP_LICENSE_FILES = doc/LICENSE.txt NCFTP_DEPENDENCIES = host-autoconf +NCFTP_CONF_OPTS = --disable-ccdv # The bundled configure script is generated by autoconf 2.13 and doesn't # detect cross-compilation correctly. Therefore, we have to regenerate it.
The ncftp build process tries to build and run a small program called ccdv to beautify the build process output. If it manages to build and run it, then it uses it. Unfortunately, this doesn't work well when the target architecture is close to the host architecture, but not exactly the same. Because both architectures are close to each other, the test run of ccdv succeeds, but real use of ccdv during ncftp build process causes an Illegal instruction issue. This for example happens with the CodeSourcery AMD64 toolchain, on a build machine running an i7-4600U, and has been detected in the autobuilders since the CodeSourcery AMD64 toolchain was upgraded at the end of January: http://autobuild.buildroot.net/?reason=ncftp-3.2.6 The issue was also reported by Christopher Arguin back in July 2016: http://lists.busybox.net/pipermail/buildroot/2016-July/168026.html and at the time, we identified that simply disabling the ccdv tool, by passing --disable-ccdv, was enough to solve the issue. But Christopher never submitted the patch, so the problem remained unfixed. Therefore, we pass --disable-ccdv to the configure script, which fixes: http://autobuild.buildroot.net/results/6eadad0e879ca70bb07b13b4196d42c64b11699f/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- package/ncftp/ncftp.mk | 1 + 1 file changed, 1 insertion(+)