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

Building namecoinq-release on OS X results in binaries different from released binaries #228

Open
Midar opened this issue May 24, 2015 · 13 comments

Comments

@Midar
Copy link

Midar commented May 24, 2015

Hi!

When building namecoinq-release from OS X, it results in a different, non-working binary than the released OS X binary. Could you please either a.) specify from which source it is actually build or b.) if it is actually build from that source, document all patches and modifications that have been applied?

@JeremyRand
Copy link
Member

I think Cassini built that binary, I'll check with him about it.

@JeremyRand
Copy link
Member

@cassiniNMC

@cassiniNMC
Copy link

Initially I had planned writing a wiki article on how to build Namecoin-Qt but then abandoned this idea when domob started developing Namecoin Core. Meanwhile there are Namecoin Core OSX build instructions. Is Namecoin Core sufficient for you, or do you actually need Namecoin-Qt?

@Midar
Copy link
Author

Midar commented May 26, 2015

@cassiniNMC I'm not interested in namecoind, since I got that working since forever (I'm the guy who did the OS X fixes). What I'm interested in is Namecoin-Qt, because yours actually works while it doesn't when building it from source. It does work when I build it from source and apply my patches, however, without them it doesn't. Thus I'm wondering what patches you applied or if you built it differently. The linked instructions are unfortunately way out of date.

@indolering
Copy link

FWIW, we are planning on deprecating this repo in favor of Namecore Namecoin Core for server/daemon usage and porting Armory for the GUI. However, I don't think PR's for adding QT support to Namecore Namecoin Core would be refused.

At any rate, time spent on this repo is time wasted.

@JeremyRand
Copy link
Member

Generally agreed with @indolering . (However, the correct name for the rebase is Namecoin Core, not Namecore. Namecore is the correct name for a port of Bitcore.)

@JeremyRand
Copy link
Member

As an aside, the Qt GUI works in Namecoin Core, except that the word Bitcoin isn't changed to Namecoin (there's already a fix pending merge), and that the name tab on the GUI isn't present.

@indolering
Copy link

As an aside, the Qt GUI works in Namecoin Core, except that the word Bitcoin isn't changed to Namecoin (there's already a fix pending merge), and that the name tab on the GUI isn't present.

Oh, that's cool! However, I now don't see why we shouldn't just update namecoin/namecoin to Namecoin Core....

But that's a different discussion, I vote to close this ticket.

@Midar
Copy link
Author

Midar commented May 31, 2015

Are we seriously having the discussion about not doing anything on this repo again? This is not about doing any code change, this is about transparency, namely documenting how the OS X Qt App is built. I really don't see any explanation on how it was actually built (whatever can be found on the web, it does not match how the binary is actually built), so why vote for closing this ticket? If even such a small thing cannot be done anymore, I really don't see how Namecoin can have a future. This is just about documenting how the binaries were built! How can this seriously end in a bike shedding discussion about the different Namecoin implementations?

@indolering
Copy link

Are we seriously having the discussion about not doing anything on this repo again?

It's 4 years out of date.

This is not about doing any code change, this is about transparency, namely documenting how the OS X Qt App is built.

Okay, I guess it comes down to getting @cassiniNMC to write that article. FWIW, I believe that Domob and Phelix have met Cassini in person. While knowing who someone is doesn't mean s/he isn't capable of doing something nefarious, I would suggest that we put our efforts into setting up reproducible builds and signing binaries.

I really don't see any explanation on how it was actually built (whatever can be found on the web, it does not match how the binary is actually built), so why vote for closing this ticket?

Because every core developer is stretched beyond capacity and spending effort on a deprecated repo feels like a waste of time.

If even such a small thing cannot be done anymore, I really don't see how Namecoin can have a future. This is just about documenting how the binaries were built! This is just about documenting how the binaries were built! How can this seriously end in a bike shedding discussion about the different Namecoin implementations?

I understand your frustration, especially given that we spent so much time on the failed LibCoin rebase. But Namecoin Core is being used by all of the miners ... this comes down to a real cost-benefit analysis. I would prefer Cassini and you spend time hacking on Namecoin Core, Armory port, or our build infrastructure.

Are you on IRC much? Drop into #namecoin and chat with Jeremy or jBisch sometime. We really need your help.

@cassiniNMC
Copy link

Ok, what I can do is posting my notes I made during the build process as a github gist, without any guarantees that it still works like this. (Would need a homebrew roll-back, I guess.)

a.) specify from which source it is actually build

Branch namecoin-releaseq in https://github.com/namecoin/namecoin , commit height a00c33d

b.) ... all patches and modifications that have been applied?

See https://gist.github.com/cassiniNMC/335764eef533e33080a5

@JeremyRand
Copy link
Member

For the record I agree with @Midar that documenting how our official releases are built is an important thing to do. I don't see any reason that switching to Namecoin Core would be mutually exclusive with this.

@Midar
Copy link
Author

Midar commented Jun 1, 2015

@cassiniNMC

That pretty much looks like what I did, except the different Boost version. However, I end up with a version that deadlocks on the splashscreen. I'll give it a try with the older Boost version…

Is there a reason you built in manually instead of just using an old homebrew recipe?

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

No branches or pull requests

4 participants