On Wed, Aug 26, 2020 at 08:13:10PM -0300, Antonio Terceiro wrote: > On Wed, Aug 26, 2020 at 02:03:41AM +0530, Pirate Praveen wrote: > > Hi, > > > > As discussed in today's ruby team BoF, I'm sending the list of current > > blockers for rails 6 transition. > > > > 1. node-yarnpkg blocked by node-babel removal (need to port to node-babel7) > > - via ruby-webpackager which is currently in Depends for rails meta package > > (rails new foo needs it). One suggestion from Duck was to lower this > > requirement to Recommends. But we will then also need to disable newapp > > autopkgtest/mark it as skip if dependencies are not available restriction > > (don't remember the exact name, just saw it in today's debconf presentation > > about autopkgtest status). > > Restrictions: skippable + exit 77 Alternatively, you could just not use the webpack in that autopkgtest. For the following patch: ----------------8<----------------8<----------------8<----------------- diff --git a/debian/tests/newapp b/debian/tests/newapp index bdbb6970..ca592a6b 100755 --- a/debian/tests/newapp +++ b/debian/tests/newapp @@ -12,7 +12,7 @@ if [ -z "$ADTTMP" ]; then fi cd $ADTTMP -rails new foo +rails new --skip-javascript --skip-webpack-install foo cd foo # Does the empty app boots? This should catch dependency problems with gemspecs ----------------8<----------------8<----------------8<----------------- > > 2. rails autopkgtest has a regression in arm64 > > https://ci.debian.net/data/autopkgtest/testing/arm64/r/rails/6730827/log.gz > > I don't know what is the root cause, it appears something related to python2 > > removal. > > I started looking at this, and tried to run the rails autopkgtest > locally. It seems to be downloading random (JS) packages from the internet? > If that's the case, I would say we probably don't want that. The above patch also fixes this issue, which could be the cause of the failure on arm64. Maybe some part of the JS stack doesn't on work on arm64?
Attachment:
signature.asc
Description: PGP signature