Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?

2022-05-21 Thread Bill Cole

On 2022-05-21 at 20:23:49 UTC-0400 (Sat, 21 May 2022 20:23:49 -0400)
Andrew Udvare 
is rumored to have said:

If it's off GitHub or GitLab you don't have to create the tarball 
unless it
has submodules (you can also fetch multiple tarballs but this is 
complex).


In this case (and for many ASF projects) the master version control is 
Subversion, so the only way I'm getting a tarball is making it 
client-side.


I actually have a script to update my ports that are of 'latest 
version'

tarballs.

https://github.com/Tatsh/ports/blob/master/_resources/bin/liveupdate


That could be useful, thanks.

Unfortunately on MacPorts there's no PortGroup to use git or similar 
to
fetch the latest code. I guess it's because it will almost certainly 
bring

more tickets into the system


Understood. I see this mostly as a developers tool, with explicit 
non-support.



especially when said latest versions are
important dependencies. On Gentoo we do have this feature (provided by
eclasses, equivalent of PoetGroup) and you have to make configuration
changes to use it when it comes to packages in the main tree. This 
makes
the point that you're on your own when you start doing this to your 
system.


You can write your own PortGroup to do this so the code can be shared 
among

your ports, similar to Gentoo's way:

https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/git-r3.eclass

Basically, git clone if the clone isn't there already, update 
otherwise

(replacing fetch phase). Don't forget submodules. Make the clone live
somewhere permanent until the package is uninstalled. When installing, 
copy
recursively the clone to the normal build directory (replacing the 
extract

phase) then the rest of the system can work as is.


Food for thought. Thanks.




On Sat, May 21, 2022, 16:38 Bill Cole <
macportsusers-20171...@billmail.scconsult.com> wrote:


On 2022-05-21 at 15:24:23 UTC-0400 (Sat, 21 May 2022 15:24:23 -0400)
Andrew Udvare 
is rumored to have said:


Rather than pull via version control,


Which is MY GOAL, not an incidental mechanical issue.


grab a tarball with the SHA you want.


Which would mean creating an ad hoc tarball before each (rapid) 
update.



That's how I do 'latest' version ports.


Well, that requires:

1. creating a tarball
2. calculating the hashes
3. editing the portfile

Which is a lot of fiddling for each new version.
My goal is to NOT do all that, but to get the same installation that 
I
would get if I did. It is also to have a way that non-developer users 
can
easily install the actual latest version of the moment, which is 
sometimes

the easiest way to get fixes that don't merit a full release.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?

2022-05-21 Thread Andrew Udvare
If it's off GitHub or GitLab you don't have to create the tarball unless it
has submodules (you can also fetch multiple tarballs but this is complex).
I actually have a script to update my ports that are of 'latest version'
tarballs.

https://github.com/Tatsh/ports/blob/master/_resources/bin/liveupdate

Unfortunately on MacPorts there's no PortGroup to use git or similar to
fetch the latest code. I guess it's because it will almost certainly bring
more tickets into the system especially when said latest versions are
important dependencies. On Gentoo we do have this feature (provided by
eclasses, equivalent of PoetGroup) and you have to make configuration
changes to use it when it comes to packages in the main tree. This makes
the point that you're on your own when you start doing this to your system.

You can write your own PortGroup to do this so the code can be shared among
your ports, similar to Gentoo's way:

https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/git-r3.eclass

Basically, git clone if the clone isn't there already, update otherwise
(replacing fetch phase). Don't forget submodules. Make the clone live
somewhere permanent until the package is uninstalled. When installing, copy
recursively the clone to the normal build directory (replacing the extract
phase) then the rest of the system can work as is.

On Sat, May 21, 2022, 16:38 Bill Cole <
macportsusers-20171...@billmail.scconsult.com> wrote:

> On 2022-05-21 at 15:24:23 UTC-0400 (Sat, 21 May 2022 15:24:23 -0400)
> Andrew Udvare 
> is rumored to have said:
>
> > Rather than pull via version control,
>
> Which is MY GOAL, not an incidental mechanical issue.
>
> > grab a tarball with the SHA you want.
>
> Which would mean creating an ad hoc tarball before each (rapid) update.
>
> > That's how I do 'latest' version ports.
>
> Well, that requires:
>
> 1. creating a tarball
> 2. calculating the hashes
> 3. editing the portfile
>
> Which is a lot of fiddling for each new version.
> My goal is to NOT do all that, but to get the same installation that I
> would get if I did. It is also to have a way that non-developer users can
> easily install the actual latest version of the moment, which is sometimes
> the easiest way to get fixes that don't merit a full release.
>
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
>


Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?

2022-05-21 Thread Bill Cole
On 2022-05-21 at 15:24:23 UTC-0400 (Sat, 21 May 2022 15:24:23 -0400)
Andrew Udvare 
is rumored to have said:

> Rather than pull via version control,

Which is MY GOAL, not an incidental mechanical issue.

> grab a tarball with the SHA you want.

Which would mean creating an ad hoc tarball before each (rapid) update.

> That's how I do 'latest' version ports.

Well, that requires:

1. creating a tarball
2. calculating the hashes
3. editing the portfile

Which is a lot of fiddling for each new version.
My goal is to NOT do all that, but to get the same installation that I would 
get if I did. It is also to have a way that non-developer users can easily 
install the actual latest version of the moment, which is sometimes the easiest 
way to get fixes that don't merit a full release.


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?

2022-05-21 Thread Andrew Udvare
Rather than pull via version control, grab a tarball with the SHA you want.
That's how I do 'latest' version ports.

On Sat, May 21, 2022, 11:23 Bill Cole <
macportsusers-20171...@billmail.scconsult.com> wrote:

> I'm currently working on a OSS project (SpamAssassin) which is in a
> pre-release rush and which I ultimately test & deploy via MacPorts.
>
> I'd *like* to be able to switch from the current supported release in
> MacPorts to a fresh build from a Subversion checkout without manually
> mimicking what MP does (in part because I'm not 100% confident that I am
> doing it right) so that I can do testing iteration in a more efficient and
> repeatable fashion. This would be a different level of 'reckless cowboy'
> beyond the '-devel' ports we already have here and there with prerelease
> software.
>
> I expect that this does not exist (I can't find anything...) but that it
> could. MP would need to always do a fetch/checkout/update/pull from the
> source control repo (I presume it would need BOTH svn and git support) and
> require use of a secure transport to make trusting the code without tarball
> checksums reasonable.
>
> Does anyone else like the idea of this? See a need? Hate it? Already have
> a private tool for this?
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
>


Is there a well-defined way to do "bleeding edge" ports? Should there be one?

2022-05-21 Thread Bill Cole
I'm currently working on a OSS project (SpamAssassin) which is in a pre-release 
rush and which I ultimately test & deploy via MacPorts.

I'd *like* to be able to switch from the current supported release in MacPorts 
to a fresh build from a Subversion checkout without manually mimicking what MP 
does (in part because I'm not 100% confident that I am doing it right) so that 
I can do testing iteration in a more efficient and repeatable fashion. This 
would be a different level of 'reckless cowboy' beyond the '-devel' ports we 
already have here and there with prerelease software.

I expect that this does not exist (I can't find anything...) but that it could. 
MP would need to always do a fetch/checkout/update/pull from the source control 
repo (I presume it would need BOTH svn and git support) and require use of a 
secure transport to make trusting the code without tarball checksums reasonable.

Does anyone else like the idea of this? See a need? Hate it? Already have a 
private tool for this?

-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


Re: macOS 12.3 and /usr/bin/python. Status?

2022-05-21 Thread Gerben Wierda via macports-users
You might be able to create a different action using mupdf (for which there is 
a port)

Gerben Wierda (LinkedIn )
R IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

> On 1 May 2022, at 07:03, Mike Alexander  wrote:
> 
> On 30 Apr 2022, at 6:26, Al Varnell wrote:
> 
>> Or just install python.
> 
> It is installed.  The problem is that the Combine PDF Pages Automator action 
> is in /system/library and has a hard coded path to /usr/bin/python.  That 
> can't be worked around since nothing in /System can be changed.
> 
> I also have PDFPen Pro which comes with an Apple Script that does much the 
> same thing.  It isn't quite what I want, but it's good enough.
> 
> Mike