cisTEM does not work on wxWidgets 3.0.3 and 3.1

timothygrant80 commented 6 years ago

Sockets things cause the gui to hang, removal of wxSOCKET_BLOCK appears to fix this (at least on small scale). Then there are lots of issues with panels not getting events until you change to another page. Strangely 2D classification, and ab-inito appear to work without issue, so hopefully there is a relatively quick fix.

Should be looked into soon after intial release.

arohou commented 6 years ago

For initial release milestone, I suggest we make the configure script clever enough to not allow building against those versions.

arohou commented 3 years ago

Closing - we now have our build system check for specific versions. I also believe we are now compatible with recent wxWidgets releases.

alexmyczko commented 1 year ago

just run into it again with 1.0.0. maybe tagging a new release would be helpful?

configure: error: "Only wxWidgets version 3.0.2 is currently supported."
        tail -v -n \+0 config.log

bHimes commented 1 year ago

[ ] The line you are printing is an intentional exception being thrown during the config step to ensure the correct wxWidgets version is available.

Although, this should be 3.04 or 3.05 for most recent and stable(ish) branches of the code.

What commit/tag/branch are you trying to compile?

Please add this information as well as some details like

your config cli options
Os
WX build/ method (did you compile or use a package repo)

alexmyczko commented 1 year ago

I just gave master a try: http://sid.ethz.ch/debian/cistem/

CLI config option should be visible in: http://sid.ethz.ch/debian/cistem/cistem_1.0.0%2Bgit20230418%2Bds-1_amd64.build OS: Debian GNU/Linux sid+experimental (x86_64) ws build, installed from package (as the goal is proper official debian package): libwxgtk3.2-dev:amd64 3.2.2+dfsg-2

bHimes commented 1 year ago

Hi Alex,

I'm a bit confused at what I'm looking at here. Are you trying to create a cisTEM package for debian? For starters, the contents of the copyright file are problematic (see below)

cisTEM is primarily licensed under a mix of BSD-3 clause and Mozilla VS 2. You do not have the permission or right to re-distribute the source code under any other license.

About your other question, you are trying to link against WX vs 3.2.2. This will not work. Versions after 3.0.5 are a major change. We are working on supporting something around 3.1 but that is not anywhere near complete.

If you have any other specific questions or comments related to what your goal is here (beyond "I want to compile against unsupported libraries) perhaps I can help.

For notes on compiling against wx 3.0.5

please see the Dockerfile for our GCC CI build

For notes on using a more current wx via package repository

please see the Docker file for our developmental container

The included (problematic) copyright file you linked to.

# If you want to use GPL v2 or later for the /debian/ files use # the following clauses, or change it to suit. Delete these two lines Files: debian/ Copyright: 2023 Gürkan Myczko tar@debian.org License: GPL-2+ This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. . This package is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

alexmyczko commented 1 year ago

Hi @bHimes

Ahh that place sid.ethz.ch is just kind of a fork of github.com sources, without git. a place to build software sources, and transforming into binary debian packages (once that's done), the users are satisfied with binary packages of software (need be installed on many machines - doesn't make sense to build every software on every host).

So I didn't even get as far as building, so didn't even bother yet checking the license (usually using decopy). But thanks for the pointer, and maybe this link should be fixed then accordingly? https://github.com/timothygrant80/cisTEM/blob/master/COPYING

the current debian/copyright, actually all of debian/ is just auto-created with dh_make and not yet reviewed/edited. and the debian/copyright is right about the Files: debian/ that's what i created i can usually license that part as whatever i wish, if it's compatible with upstream licensing (and fits DFSG). anyways, your softwere not ready for wx3.2 makes it not fit for future debian/ubuntu versions, but could just build/work on older versions with the wx version you support... (Debian 11, or Ubuntu 22.04)

Short summary of my goal: i have users (they want your software), i have computers (linux workstations). i build binaries of software and distribute them (either if license wise possible directly to debian.org - if not with reprepro)

ps: docker, I don't use and avoid docker. (podman can sometimes serve as a replacement, but if it's possible without, the better)

Thank you!

bHimes commented 1 year ago

Hi @bHimes

Ahh that place sid.ethz.ch is just kind of a fork of github.com sources, without git. a place to build software sources, and transforming into binary debian packages (once that's done), the users are satisfied with binary packages of software (need be installed on many machines - doesn't make sense to build every software on every host).

So I didn't even get as far as building, so didn't even bother yet checking the license (usually using decopy). But thanks for the pointer, and maybe this link should be fixed then accordingly? https://github.com/timothygrant80/cisTEM/blob/master/COPYING

Thanks for pointing this out. The Janelia license is just BSD-3 under the hood. The MozV2 licensed software isn't yet used in the main repo, but I will update this file so I don't forget once this get's merged in!

the current debian/copyright, actually all of debian/ is just auto-created with dh_make and not yet reviewed/edited. and the debian/copyright is right about the Files: debian/ that's what i created i can usually license that part as whatever i wish, if it's compatible with upstream licensing (and fits DFSG). anyways, your softwere not ready for wx3.2 makes it not fit for future debian/ubuntu versions, but could just build/work on older versions with the wx version you support... (Debian 11, or Ubuntu 22.04)

** Being mainly academic devs still bound to shared clusters in many cases, we are usually a few steps behind current versions. I've opted for Apptainer based distribution, but the official path is still to compile with static libs against the oldes OS/kernel possible inside a VM (CentOS 7 r/n)

Short summary of my goal: i have users (they want your software), i have computers (linux workstations). i build binaries of software and distribute them (either if license wise possible directly to debian.org - if not with reprepro)

Would you be interested in building an Apptainer container to distribute to your users?

ps: docker, I don't use and avoid docker. (podman can sometimes serve as a replacement, but if it's possible without, the better)

I was just pointing to the Dockerfiles as they are a nice build recipe you could follow/glean information from. We use docker for creating a unified development env, and Apptainer for distribution (with the caveat mentioned above.

Thank you!

alexmyczko commented 1 year ago

Is Apptainer the new name of the following?

https://packages.debian.org/search?keywords=singularity-container

Then absolutely no, it was hard to build, it had so much security issues, it's not widely spread, and on debian devel mailinglist it was discussed whether there's a chance to security maintain it for a stable phase of Debian (not remember the outcome), it was as far as I can remember, not pretty well supported from upstream (makeing huge changes, making it nearly impossible to only cherry pick the relevant parts for the security update)

Thus, generally speaking (don't get me wrong), if software is free software, it's preferred by me to work on, if not, I'll take any binary (tar.gz or tar.xz is preferred over appimage > flatpak > snap and from here on on a black list as in not supported, your software - up to you (for the user) podman/docker/singularity/anaconda)

Because mantra clearly is: if you can't build it, you're not supposed to run it. (YMMV)

academic software, i fully agree is very special, depending on the field. a lot get it right... i've only recently figured about the sbgrid licensed way of software distribution...

bHimes commented 1 year ago

Singularity was taken a bit off the rails by a commercial interest. Apptainer is an attempt to bring that back in, and is part of the Linux Foundation.

As for security, this is not my area of expertise, but my understanding from interactions with many HPC sysadmins is that it is a good option (but maybe only the lesser of evils?) Anyway, I like to support free software, but my main focus is on supporting science, which means supporting scientists, many of which are not ever going to be able to live by your mantra of build or don't use : )

alexmyczko commented 1 year ago

I hope you got the tongue in cheek about build or dont-use. But their headline is "Apptainer/Singularity is the most widely used container system" and it's maybe true, but compared to how much runs without container system?

Anyways, I'm like you, supporting science (people that do so), I've been doing so almost 20 years, and I don't see a need for change here (not for the next 20 years): let me point you to the Lindy effect: https://en.wikipedia.org/wiki/Lindy_effect

Looks like it'll take some time to get into Debian: https://repology.org/project/apptainer/versions

timothygrant80 commented 1 year ago

Hi Alex - is there a reason you can't use the pre-compiled binaries? These tend to work well on most systems.

The original old binaries are available here :-

https://grigoriefflab.umassmed.edu/sites/default/files/cistem-1.0.0-beta-intel-linux.tar.gz

More recent binaries for the development version are available here :-

https://grigoriefflab.umassmed.edu/sites/default/files/cisTEM-2.0.0-alpha-70-d11eb1e.tar.gz

Thanks!

Tim

alexmyczko commented 1 year ago

@timothygrant80 no binaries work just fine, these days where it's all only x86_64. unless arm64/aarch64 gets popular among scientists with linux i don't see a problem...

timothygrant80 / cisTEM