Builds failing for 32-bit platforms about common-lisp HOT 13 CLOSED

The error message is:

W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/Release  Unable to find expected entry 'main/binary-i386/Packages' in Release file (Wrong sources.list entry or malformed file)

Which occurs in install.sh:33 in install_i386_arch where sudo apt-get update -qq Sure enough, if you look in http://dl.google.com/linux/chrome/deb/dists/stable/Release directly, there are only main/binary-amd64/Packages entries. Looking into what dpkg options we may need now.

Here's the contents Release file
Release.txt

I note it's from Google, and not Ubuntu directly. I don't know if that's a Travis, Google, or Ubuntu thing. It's been a while since I worked in Debian, but there's a sources file which may specify this location for the packages. I'll look into if there's a Travis option for specifying this.

from common-lisp.

Not clear to me why the allowed failures are still failing:

• https://travis-ci.org/wobh/xlisp/jobs/114691646
• https://github.com/wobh/xlisp/tree/xlisp-106-builds-failing-for-32-bit-platforms
• https://raw.githubusercontent.com/wobh/xlisp/xlisp-106-builds-failing-for-32-bit-platforms/.travis.yml

Something about the YAML syntax?

from common-lisp.

So... what's the verdict?

from common-lisp.

No verdict, yet. I'll circle back on this ASAP. I've been crazy busy.

from common-lisp.

...crazy busy

Oh I know that feeling - fair enough. Come back to it when you can.

from common-lisp.

I took a look through some of the .travis.yml files in other tracks; xhaskell and xgo were the most informative. xgo is allowing a build to fail, however, Go has native travis support which I think lets it do yaml key values instead of a list item with environment variable literally in there. xhaskell's setup is more like ours with literal environment variable setting, but they don't allow any failing builds.

I don't think the lisp support for travis is in place yet, but I'll look into that soon. I don't see documentation that lets me know if I can setup allowed failures this way. We could just comment them out, but this is the kind of situation where it seems like we need this, there's something wrong about the installation method, it's not a problem in the implementations, or our testing script (EDIT: although there still could be something wrong about the travis config).

References:

• https://docs.travis-ci.com/user/customizing-the-build/#Rows-that-are-Allowed-to-Fail
• https://docs.travis-ci.com/user/customizing-the-build/#Fast-Finishing

from common-lisp.

Ah-ha!

Allowed failures here: https://travis-ci.org/wobh/xlisp/builds/121612074

Checking out the travis sources I found and an example and the code that makes it work. You have to have the key - env: for our allowed failures.

• code :: https://github.com/travis-ci/travis.rb/blob/89cb71786453cd07d9248ee31c0e135e23541ed4/lib/travis/client/job.rb#L33
• example (commented out) :: https://github.com/travis-ci/travis-scheduler/blob/7dd1d51871b45a17b1ddde79e3e97296deeb9e6e/.travis.yml#L32

This makes retroactive sense (doh!) but I haven't seen any other examples and it seems like that could possibly be documented better.

from common-lisp.

Glad you figured it out. Oddly - the builds had started working again at some point...

from common-lisp.

Looks like it was fixed upstream, not even two weeks ago. luismbo/cl-travis#17. But the system still seems delicate. Seems like there's got to be a way to specify sources.

from common-lisp.

given that it has been fixed - do we still want to make the 32 bit builds optional? I'm on the fence but leaning toward keeping them in - but could be swayed to have them be optional.

from common-lisp.

I think they should remain optional until we or luismbo figure out a better solution for the sources problem. The main thing keeping us from using the faster TravisCI environments is that install.sh uses sudo to custom install system implementations. I think, if we could tell the Travis where to download system implementations needed we could set that up in configuration and simplify install.sh a great deal, possibly enough to be able to say sudo: false. That should give us stable (or easily updated) sources for x86 architectures and everything else.

from common-lisp.

Fair enough. I'm swayed. I'll merge that PR.

from common-lisp.

(It's not entirely clear to me why travis-cl uses these system installations instead of using CIM.)

from common-lisp.