Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

publish-for-arch broken in 1.0.4 (for packages whose names contain colons) #3951

Closed
mizzao opened this issue Mar 17, 2015 · 13 comments
Closed

publish-for-arch broken in 1.0.4 (for packages whose names contain colons) #3951

mizzao opened this issue Mar 17, 2015 · 13 comments

Comments

@mizzao
Copy link
Contributor

@mizzao mizzao commented Mar 17, 2015

On all archs:

build:~ meteor$ meteor publish-for-arch mizzao:sharejs@0.7.2
Malformed source tarball

Originally posted here: https://forums.meteor.com/t/trying-to-publish-for-arch-in-meteor-1-0-4-malformed-source-tarball/1369

@mizzao
Copy link
Contributor Author

@mizzao mizzao commented Mar 18, 2015

I found a workaround to requiring binary code and took out the npm package that has binary references. But I still get this message:

Published mizzao:sharejs@0.7.3.               

This package contains binary code and must be built on multiple architectures.

You can access Meteor provided build machines, pre-configured to support older versions of MacOS and Linux, by running:
  meteor admin get-machine os.osx.x86_64      
  meteor admin get-machine os.linux.x86_64    
  meteor admin get-machine os.linux.x86_32    

On each machine, run:                         

  meteor publish-for-arch mizzao:sharejs@0.7.3

For more information on binary ABIs and consistent builds, see:
  https://github.com/meteor/meteor/wiki/Build-Machines

Is it possible that Meteor "remembers" a package as being binary from older versions, even if newer ones aren't?

@glasser
Copy link
Member

@glasser glasser commented Mar 18, 2015

Hmm, this might just be a bug in some of the Windows compatibility code:


  // XXX Factor out with packageClient.bundleSource so that we don't
  // have knowledge of the tarball structure in two places.
  var packageDir = files.pathJoin(sourcePath, colonConverter.convert(name));
  if (! files.exists(packageDir)) {
    Console.error('Malformed source tarball');
    return 1;
  }
@glasser
Copy link
Member

@glasser glasser commented Mar 18, 2015

Aha, this was already fixed on devel: 89f86b1

@avital FYI, this fix that you did on devel a few days ago was to something that was broken in 1.0.4. Were there any other similar fixes you made since release-1.0.4 forked that should have gotten released?

@glasser glasser changed the title publish-for-arch appears to be broken in 1.0.4 (Malformed source tarball) publish-for-arch broken in 1.0.4 (for packages whose names contain colons) Mar 18, 2015
@glasser
Copy link
Member

@glasser glasser commented Mar 18, 2015

Fixed in 1.0.4.1. Thanks for the report @mizzao !

@glasser glasser closed this Mar 18, 2015
@mizzao
Copy link
Contributor Author

@mizzao mizzao commented Mar 18, 2015

@glasser: So what do I need to use this fix? I'm still getting the same error.

Do I need to re-publish a new version of the package using 1.0.4.1?

build:~ meteor$ meteor --version              
Meteor 1.0.4.1
build:~ meteor$ meteor publish-for-arch mizzao:sharejs@0.7.3
Malformed source tarball 
@glasser
Copy link
Member

@glasser glasser commented Mar 18, 2015

Yes, publish-for-arch makes sure that it uses the same release that the package was published with.

In weird cases like this you can also carefully check out the same commit that you published the package with and run meteor publish --existing-version. But it is then your responsibility to make sure it's the same source!

@mizzao
Copy link
Contributor Author

@mizzao mizzao commented Mar 18, 2015

So what happens if you publish --existing-version with different source? Just curious.

@mizzao
Copy link
Contributor Author

@mizzao mizzao commented Mar 18, 2015

Even using that same commit does not seem to work. On my machine:

$ meteor publish --existing-version
Published mizzao:sharejs@0.7.3.               

WARNING: Your package contains binary code.   

On the build machine:

$ meteor publish-for-arch mizzao:sharejs@0.7.3
Malformed source tarball                      

I can tell it's not using 1.0.4.1 because it said Downloading meteor-tool@1.0.42 or whatever, which is the meteor-tool corresponding to 1.0.4 - 1.0.43 is 1.0.4.1.

@glasser
Copy link
Member

@glasser glasser commented Mar 18, 2015

Sorry, I mean run that command instead of publish-for-arch.

@mizzao
Copy link
Contributor Author

@mizzao mizzao commented Mar 18, 2015

Not sure what command you mean. I've run that command on my local machine and it works. But trying publish-for-arch on the build machines afterward produces the same error.

@glasser
Copy link
Member

@glasser glasser commented Mar 18, 2015

meteor publish --existing-version on the build machines.

In a (not quite literal) sense, publish-for-arch is syntactic sugar for "download the source tarball, make sure you're running the same release, and run publish --existing-version".

@mizzao
Copy link
Contributor Author

@mizzao mizzao commented Mar 18, 2015

Thanks, that worked.

If that's the case, why does meteor publish on my local machine still require a publish-for-arch of the same architecture on the build machines? It didn't used to, but now we have to do all three?

@glasser
Copy link
Member

@glasser glasser commented Mar 18, 2015

To encourage people to use build machines which have a carefully chosen architecture (glibc, etc) which we've chosen to maximize the span of machines that the binaries will work on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants