Here is a simple question that Virtualmin needs to answer.
Why is Virtualmin making architecure specific packages when they do not include architecure specific binary code in the package?
Hence my assertion before:
The way packaging works in Virtualmin is not clear
There is no such package.
Any package with an arch label such as x86_64 is an architecture specific package, even when it does not contain architecure specific code.
Below, from October 2006, is odd on two counts:
So again, the same question.
Why is Virtualmin making architecure specific packages when they do not include architecure specific binary code in the package?
Please don’t interpret this as an attack. I have great admiration for Virtualmin. The broad approach of Virtualmin is fantastic and deserves far more recognition. I have looked in detail at internal coding and have had a few fixes accepted in GitHub. I am happy to state publicly Virtualmin code is sound and solid.
We are not. You’ve linked a post from nearly 20 years ago, and about packages that were architecture dependent.
There is one architecture dependent package (procmail-wrapper) in current repos (there used to be more). I don’t know how else to explain it. Your own testing showed that you are able to install the architecture independent packages on ARM without problems.
Packages that can be architecture independent are architecture independent and always have been.
Massive amount of packages labelled as amd64 that are installed in aarch64 (see images below).
It would be nice if you could just at least accept there IS a problem with this approach, instead of just dismissing my real (non-theoretical) experiences, which are relevant.
Why does Webmin get it right and Virtualmin, an extension to Webmin, not get it right? After all, Virtualmin code is Perl script, which is architecture independent, not compiled binary, which is architecture dependent.
https://software.virtualmin.com/vm/7/gpl/apt/dists/virtualmin/
https://software.virtualmin.com/vm/7/gpl/apt/dists/virtualmin/main/
My impression is that a relatively simple re-organisation would fix the upgrade problems I experienced after install on aarch64.
I don’t want to go into details when I cannot get it even accepted there may be a problem. Curt dismissals and unacceptance of legitimate experience give a message of ‘Go away; you are irritating me. There is no problem’.
You’re misinterpreting what you’re looking at. Look at every package in Index of /vm/7/gpl/apt/pool/main/w
This is becoming pointless. You have already proven that all of our packages except procmail-wrapper install fine on ARM (or any other arch that has all the necessary Perl dependencies). I don’t understand how you watched with your own eyes that all of our packages that can be architecture-independent are architecture-independent (and always have been), and continue to argue about it? You installed these packages on your test ARM system, did you not? In this comment above: I got Virtualmin working on ARM64 (Ampere) - #14 by johnhe
OP has also installed our packages, except for procmail-wrapper, on an ARM system. Our packages that can be architecture-independent are architecture-independent.
I cannot fix what is not broken. I can’t make it more architecture independent. They are already all packages, and they always have been.
Installing on ARM was harder in the past, where there were more architecture dependent packages, and when we handled dependencies differently. But, there was never a time when we packaged our architecture-independent code in an architecture-dependent package, and I don’t know where you got the idea that we do or did, because there’s no reason to think that.
Proves nothing. Labels and policy, right down through an incredibly complex install and update chain are everything in packaging, as you should know and for very good reason. Wasn’t Webmin packaging removed from Debian for violation of policy issues?
The install chain LOOKS odd. Not healthy in such a complex environment.
I only have to repeat one comment to prove my case. For updates,
Why does Webmin get it right and Virtualmin, an extension to Webmin, not get it right?
I am done with this. I will just wait until the problems re-emerge.
When the problem does re-emerge I think it will be easy to fix.
A dog with a bone 
Seems whatever Joe says your going to disagree.
So @stefan1959, have you lived through the disappointment of not being able to update an install?
With, a failure to accept there may be a problem, when there are numerous red flags blowing in the wind?
Such as a weird problem with non-architecture specific code on a different architecture, when there should not be any? With a weird policy of non-support for the architecture when the base OS has gone to tremendous trouble to support the architecture and make it trivial for non-architecure specific code to be supported.
Good, if no.
The bigger issue here is that Virtualmin does not support aarch64. This is weird. Webmin, that Virtualmin is a module of, does.
However, that is the choice of Virtualmin. Since they have a stated policy of non-support, they can be as cavalier as they want.
As I said in the beginning, I would need to see specific errors. There is no architecture dependency in any of our packages, except procmail-wrapper. There is no reason they should not install or update normally.
The installer does not support ARM, and we don’t have repos for architecture-dependent packages (which is just procmail-wrapper on Debian/Ubuntu, but also includes jailkit on RPM-based distros, and maybe another one or two packages), which we state clearly on our OS support page.
wow the dramatics, Ive seen none so far, works perfectly.
So you have been around the forum for ten years and you think Virtualmin works perfectly. OK.
Yep, perfect.
Every software gets bugs, but they all get fixed, if they not fixed just wait as they will be.
But my Rock9 system is purrring along.
Remember VM/webmin are config tools, they not the OS.
Hi guys,
Please don’t hijack my thread. I started off this post on a very happy and positive note about how incredible it was for me to get Virtualmin working on ARM64, how I overcame compiling to procmail-wrapper, and how I have some additional work to do before I can give full feedback.
Virtualmin is an incredible open-source product run by a small team and most people leach off it without every buying a Pro license. In the world of open-source, you go to the repository on Github and you can an explore and learn how it works and then if you wish you make positive contributions by pull requests.
Let’s keep this thread about ARM64 and Virtualmin. Thanks.
When Joe says the installer does not support ARM he means Virtualmin does not support ARM.
Relevant, not hijacking, not a happy thread.
I have presented evidence that there are issues but it has clearly been unwelcomed. Apart from my negative experience with Virtualmin on aarach64, which has yet to re-emege, there are issues with the Virtualmin install system, which Joe took enormous and unjustified offence to.
I gave up, despite being willing to engage more on.
So, this is the reality you are now in.
If there is a problem with our non-architecture dependent packages on ARM, I would need to see an exact error. I am unaware of any issues.
Yet here you are.
That is right, closing the door.
@vander.host Please try doing the following on your ARM64 VPS
apt update
Do you get the following as your last line?
N : Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://software.virtualmin.com/vm/7/gpl/apt virtualmin InRelease' doesn't support architecture 'arm64'
I think this is the message I got before that I found terribly disappointing, particularly the last four words:
doesn't support architecture 'arm64'