BTW, in case my post came through as a complaint. It is not intended -- the emphasis is on my readiness to contribute the actual fix, if this makes sense.
The version 1.36 is already somewhat off the usual. Perhaps with the next release, the consistency will be back. On Wed, Nov 9, 2016 at 4:18 PM, Artur Shepilko <nomadb...@gmail.com> wrote: > I appreciate your quick response on this -- I understand your point. > > My point is rather about inconsistent __attribution__ for the > most-recent version posted on the download page. > And indeed as is the 64-bit Fossil binary does not run on Ubuntu 14.04 > LTS 32-bit: > ./fossil > bash: ./fossil: cannot execute binary file: Exec format error > > I'm not advocating posting binaries for a whole variety of platforms, > current subset is reasonable, as long as it's consistent. > Sure, Fossil may be built from sources. This however does not make the > posted v1.36 binary 32-bit as it was consistently with previously > posted versions. > > Also, it's may be worth mentioning somewhere, that even though the > posted 32-bit Fossil version may __appear__ to run correctly on 64-bit > Linux x86, > it however may fail at clone/pull/push as I mentioned earlier, this is > due to being linked STATIC -- that was experienced with the posted > v1.35 on Ubuntu 14.04 LTS 64-bit. > > ./fossil clone http://fossil-scm.org fossil.fossil > getaddrinfo() fails: Name or service not known > Clone done, sent: 0 received: 0 ip: > server returned an error - clone aborted > > This issue has been already described a year ago > (http://fossil-users.fossil-scm.narkive.com/sFeCbzeR/issue-with-cloning-a-repo) > > Effectively this prompts Fossil users to always build it from sources > in order to avoid such confusion. > > > Thanks. > > On Wed, Nov 9, 2016 at 3:44 PM, Richard Hipp <d...@sqlite.org> wrote: >> On 11/9/16, Artur Shepilko <nomadb...@gmail.com> wrote: >>> >>> Seriously, guys, >> >> The existing download works great on the vast majority of Linux >> desktops. For the small minority where it doesn't work, "./configure; >> make" is an easy alternative. >> >> Where does one draw the line? If we have separate builds for 64-bit >> and 32-bit Intel Fossil, what about ARM? Or Sparc? Or PowerPC. Hey, >> why no VAX build? >> >> And shouldn't we also then publish binaries with various compile-time >> options enabled/disabled? Why no --json and --with-tcl builds? >> >> Rather than spend a lot of time generating and publishing an >> ever-growing assortment of precompiled, I think the developers' time >> would be better spent just making "./configure; make" work >> better/easier on all systems. We've already made a lot of progress in >> that area. Fossil has few external dependencies. More often than not >> "./configure;make" just works. >> >> If "./configure;make" is not working for you, then by all means talk >> about the problem and we will try to fix it. That complaint is much >> more likely to fall upon sympathetic ears. >> >> But I'm not particularly motivated to add an ever-growing assortment >> of precompiled binaries to the download page. If anything, I'd like >> to cull a few. Linux and OpenBSD being obvious candidates since >> "./configure;make" works so well on those platforms. >> >> >> -- >> D. Richard Hipp >> d...@sqlite.org >> _______________________________________________ >> fossil-dev mailing list >> fossil-dev@mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
