|
Mark A. Stevens wrote: [...] I know enough about RPMs to get myself in lots of trouble,
so I will point you to some online help. From my experience,
a part of the team developing a package, builds and tests
the RPMs. <snip> From the sounds of it then, it is not necessarily the developers of the product itself that is necessarily responsible for creating distribution packages, but another team altogether. I cannot speak for the rest of the team of course, but as for me I'm happy with the way things are. If someone (or several someones) wants to take on the added responsibility of creating official distribution packages for SDL Hyperion Hercules, they are free to do so. But as for me, I've already got enough on my plate. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Joe Monk wrote: The last OFFICIAL release I am aware of is V3.13...
What constitutes "an OFFICIAL release"? How is that defined? Or perhaps a better question might be, WHO gets to decide? "I can now develop "my" Hercules (Hyperion) the way
I want to, without ... <snip> Old news. The current SDL Hercules hasn't been "mine" for many years now. It was only "my" Hercules for the first year or two of its existence, since during that time it existed as a private fork, and I was the only one making any changes to it (I was the only one with commit access). Since the creation of the SDL-Hercules-390 GitHub Organization () however (exact date unknown; oddly, github doesn't seem to provide that information! But probably for several years now, since *before* 4.1 was released, which was on Nov 11, 2018), SDL Hercules hasn't been "mine". It's now "the groups" (i.e. the GitHub Organization's), of which I am only one member. It started out as a private fork, but it is no longer a private fork. It is an official GitHub Organization. The GitHub Organization -- not me -- "owns" the repository and assumes full responsibility for it. Not me. And for the record, the only reason it's called SDL-Hercules-390 instead of just Hercules-390 is because GitHub already had a Hercules-390, so I had to come up with a different name. And since I had my own "SDL" web site, I decided to name it SDL-Hercules-390 to distinguish it from Hercules-390. Since its creation, it has been the only active Hercules in existence that I am aware of. Hercules v3.x is no longer updated (or sure as hell isn't updated very damn often). And IMHO, SDL Hercules is vastly superior (which I hope the community agrees) to Hercules v3.x too, containing many important bug fixes and enhancements that simply don't exist in v3.x. So if the official release is determined by popularity, I rather suspect SDL Hercules's v4.x is clearly the official Hercules, not v3.x. So again, HOW is the "official" release of a product determined? Really? WHO determines what the "official" release is? But the bottom line is, IMHO, it's largely unimportant. At least to me anyway. I don't really care "which Hercules" is deemed "the official version" and which isn't. All I care about is that *OUR* version of Hercules (SDL-Hercules-390's and the community's) remains the *best* damn Hercules out there. And if that's not good enough for some people, so be it. It's no skin off my nose. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Hello! I thought those folk from the piscean communities do not have noses? Now a word from one of the managers, now that we have an official last word on these things, let's move the thread back to the original premise that of why the correspondent is having these issues? ----- Gregg C Levine gregg.drwho8@... "This signature fought the Time Wars, time and again." On Sat, Jan 1, 2022 at 1:46 AM Fish Fish <david.b.trout@...> wrote:
Joe Monk wrote:
The last OFFICIAL release I am aware of is V3.13...
What constitutes "an OFFICIAL release"? How is that defined? Or perhaps a better question might be, WHO gets to decide?
"I can now develop "my" Hercules (Hyperion) the way
I want to, without ... <snip>
Old news.
The current SDL Hercules hasn't been "mine" for many years now. It was only "my" Hercules for the first year or two of its existence, since during that time it existed as a private fork, and I was the only one making any changes to it (I was the only one with commit access).
Since the creation of the SDL-Hercules-390 GitHub Organization () however (exact date unknown; oddly, github doesn't seem to provide that information! But probably for several years now, since *before* 4.1 was released, which was on Nov 11, 2018), SDL Hercules hasn't been "mine". It's now "the groups" (i.e. the GitHub Organization's), of which I am only one member. It started out as a private fork, but it is no longer a private fork. It is an official GitHub Organization. The GitHub Organization -- not me -- "owns" the repository and assumes full responsibility for it. Not me.
And for the record, the only reason it's called SDL-Hercules-390 instead of just Hercules-390 is because GitHub already had a Hercules-390, so I had to come up with a different name. And since I had my own "SDL" web site, I decided to name it SDL-Hercules-390 to distinguish it from Hercules-390.
Since its creation, it has been the only active Hercules in existence that I am aware of. Hercules v3.x is no longer updated (or sure as hell isn't updated very damn often). And IMHO, SDL Hercules is vastly superior (which I hope the community agrees) to Hercules v3.x too, containing many important bug fixes and enhancements that simply don't exist in v3.x.
So if the official release is determined by popularity, I rather suspect SDL Hercules's v4.x is clearly the official Hercules, not v3.x.
So again, HOW is the "official" release of a product determined? Really? WHO determines what the "official" release is?
But the bottom line is, IMHO, it's largely unimportant. At least to me anyway. I don't really care "which Hercules" is deemed "the official version" and which isn't. All I care about is that *OUR* version of Hercules (SDL-Hercules-390's and the community's) remains the *best* damn Hercules out there.
And if that's not good enough for some people, so be it. It's no skin off my nose.
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
Perry looked at Della and then at Paul, and then to the Doctor who was sitting in the client chair, with Duke asleep in his lap. Junior had settled with Della, and the lion pair were parked on the couch in back. Then, "It seems Jack that your observations are paying off again, it seems the DA is indeed working with a handicap. Although I had thought that idiot Holcombe was through with being a homicide division cop." Paul looks up from his position. "Technically he is, after you proved categorically that not only did he blow it in working up the case, he caused a big mess which caused a mistrial. And you know of course Perry that the judge in that case definitely ruled out trying your client again with that crappy evidence they collected. In fact the only reason he's there is that Tragg is taking a well earned vacation someplace." The Doctor offers, "So the handicap in this case is indeed Holcombe. That's what I get for examining the case from the perception of using statistics. As well as using logic." From Perry Mason meets Doctor Who an as yet unpublished memoir.
|
Gregg Levine wrote: Hello!
I thought those folk from the piscean communities do not
have noses? The good ones do. ;-) Now a word from one of the managers, now that we have an
official last word on these things, let's move the thread back
to the original premise that of why the correspondent is
having these issues? AFAIK the OP's issue has already been resolved. Yes? /g/h390-vm/message/3826And as far as the new subject of conversation this thread has diverted to (packaging), I think we are done. Or at least I am anyway. I mean, I certainly have nothing more to say on the subject. So from my POV this thread is done. Yes? Happy New Year everyone! :) -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Hello, I am the correspondent that started this topic. From a pragmatic viewpoint the specific issue has been corrected by my editing of a configuration file.
|
For what it's worth, when I was doing releases, I built RPMs as well as macOS installer disk images.
Perhaps what can be done is to add recipes for Windows installer, .DMG, RPM, and DEB packages to the build process, and then they can be run by interested parties as needed.
I haven't tried building on macOS in years. I need to look at that again. But I will *NOT* use Homebrew or the like; they cause far too many unnecessary dependencies to be pulled in.
Mark A. Stevens wrote:
[...]
> I know enough about RPMs to get myself in lots of trouble,
> so I will point you to some online help. From my experience,
> a part of the team developing a package, builds and tests
> the RPMs.
<snip>
From the sounds of it then, it is not necessarily the developers of the product itself that is necessarily responsible for creating distribution packages, but another team altogether.
I cannot speak for the rest of the team of course, but as for me I'm happy with the way things are.
If someone (or several someones) wants to take on the added responsibility of creating official distribution packages for SDL Hyperion Hercules, they are free to do so. But as for me, I've already got enough on my plate.
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
I am a user of homebrew as it is easy. It perhaps would be better to leave this thread and start another (if there is still energy) on the subject of package distribution/building.
For me I have now all that I need with 3.13 and V1.R1.1 working together. Thanks everyone for the rapid and clear resolution of my issue.
|
Anthony, Yes, but it should be on [email protected]. Chris -- <cjar1950@...> ---------------------------------------------------------------------------------------------------------------------------------- On Sat, 01 Jan 2022 05:46:17 -0800 "Anthony Smith" <anthony@...> wrote: I am a user of homebrew as it is easy. It perhaps would be better to leave this thread and start another (if there is still energy) on the subject of package distribution/building.
For me I have now all that I need with 3.13 and V1.R1.1 working together. Thanks everyone for the rapid and clear resolution of my issue.
|
I've discovered almost at the same time hercules, hyperion and
the IBM IBM VMESA 2.40 distribution, I'm facing a strange thing
between Hyperion (4 something) and Hercules (3 something else).
Disn't try the ?comunity edition? for the time being. Running Arch
Linux, I found it rather simple to have a running hyperion while
Hercules 3.x is available as a standard package. I just wanted to
thanks all the people that allowed me to relink with my past and
made some of my dreams become true, I'm currently trying to become
as fluent wih Rexx as I was so long ago, I'll start some digging
arounnr VM community Edition hoping becoming able to provide some
help in this area. For the time being I'll just concentrate in
wishing all the best for all of you. Hoping that 2022 will bring
yu all that 2021 forgot and provide, if needed the adequate
leverage.
Sorry for my poor Englis, I 'm just trying to share some of my
feelings with colleagues all around the world.
Sincerely with all of you
Jean-Pierre Cabani¨¦ form a town in the very South of France :
Toulouse,
Le 01/01/2022 ¨¤ 14:46, Anthony Smith a
¨¦crit?:
I am a user of homebrew as it is easy. It perhaps would be better
to leave this thread and start another (if there is still energy)
on the subject of package distribution/building.
For me I have now all that I need with 3.13 and V1.R1.1 working
together. Thanks everyone for the rapid and clear resolution of my
issue.
--
Jean-Pierre Cabani¨¦ \_(¥Ä)_/
|
On Fri, Dec 31, 2021 at 06:18 PM, Fish Fish wrote:
Forgive me, but I'm Linux illiterate. What does the SDL Hyperion Hercules project / development team need to do to get whatever it was you showed me to install the latest and greatest OFFICIAL 4.x release of SDL Hyperion Hercules? Anything? Is it OUR (the Hercules team's) responsibility? Or someone else's? (i.e. the "package maintainer's" if there is such a thing?)
Fish, I have a SDL Hyperion 4.4 .deb for Debian and its descendants almost ready to add to our release assets. Tested so far only by two people other than myself. Bill
|
"I haven't tried building on macOS in years. I need to look at that again. But I will *NOT* use Homebrew or the like; they cause far too many unnecessary dependencies to be pulled in."
Yeah I know, I dont really like homebrew either.
But Apple have been up to their tricks, and done things like remove telnet from the OS, so now you have to go to a package manager?to get simple telnet. And in case you dont know, everything Apple now is written in Swift, the replacement for Objective-C. XCODE CLI is *huge*. There is a big push to make all things iOS run on the mac (hence the name macOS!).
Joe
For what it's worth, when I was doing releases, I built RPMs as well as macOS installer disk images.
Perhaps what can be done is to add recipes for Windows installer, .DMG, RPM, and DEB packages to the build process, and then they can be run by interested parties as needed.
I haven't tried building on macOS in years. I need to look at that again. But I will *NOT* use Homebrew or the like; they cause far too many unnecessary dependencies to be pulled in.
Mark A. Stevens wrote:
[...]
> I know enough about RPMs to get myself in lots of trouble,
> so I will point you to some online help. From my experience,
> a part of the team developing a package, builds and tests
> the RPMs.
<snip>
From the sounds of it then, it is not necessarily the developers of the product itself that is necessarily responsible for creating distribution packages, but another team altogether.
I cannot speak for the rest of the team of course, but as for me I'm happy with the way things are.
If someone (or several someones) wants to take on the added responsibility of creating official distribution packages for SDL Hyperion Hercules, they are free to do so. But as for me, I've already got enough on my plate.
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
--
|
Oh and one other thing... New Macs are ARM based. No more Intel. Also, no more 32-bit anything. Everything MAC is now 64-bit only.
So to build for macOS, you have to build for both ARM and Intel, a least for a little while.
Joe
"I haven't tried building on macOS in years. I need to look at that again. But I will *NOT* use Homebrew or the like; they cause far too many unnecessary dependencies to be pulled in."
Yeah I know, I dont really like homebrew either.
But Apple have been up to their tricks, and done things like remove telnet from the OS, so now you have to go to a package manager?to get simple telnet. And in case you dont know, everything Apple now is written in Swift, the replacement for Objective-C. XCODE CLI is *huge*. There is a big push to make all things iOS run on the mac (hence the name macOS!).
Joe
For what it's worth, when I was doing releases, I built RPMs as well as macOS installer disk images.
Perhaps what can be done is to add recipes for Windows installer, .DMG, RPM, and DEB packages to the build process, and then they can be run by interested parties as needed.
I haven't tried building on macOS in years. I need to look at that again. But I will *NOT* use Homebrew or the like; they cause far too many unnecessary dependencies to be pulled in.
Mark A. Stevens wrote:
[...]
> I know enough about RPMs to get myself in lots of trouble,
> so I will point you to some online help. From my experience,
> a part of the team developing a package, builds and tests
> the RPMs.
<snip>
From the sounds of it then, it is not necessarily the developers of the product itself that is necessarily responsible for creating distribution packages, but another team altogether.
I cannot speak for the rest of the team of course, but as for me I'm happy with the way things are.
If someone (or several someones) wants to take on the added responsibility of creating official distribution packages for SDL Hyperion Hercules, they are free to do so. But as for me, I've already got enough on my plate.
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
--
|
Anthony Smith
Jean-Pierre Cabani¨¦
Bill Lewis