Re: emacs-app-devel build fail on master not detected by buildbot

[Joshua Root]

On 2021-4-23 15:35 , Christopher Jones wrote:




On 23 Apr 2021, at 3:48 am, Dan Ports  wrote:

To be clear, the problem here was that MacPorts uses the xcode-provided
git, and certain older systems have a version of git that's too old to
support the --shallow-since option, causing the port to break on
systems where it's buildable today.

Now, those systems are pretty old at this point (IIRC, it was El
Capitan and older) so perhaps that is worth reconsidering. We could
also install and use our own version of git on older systems as we do
for some other fetch/extract dependencies, but that would require a
base update.


why a base update ? Just adding port:git as a build dep would do it, as port 
would then use that version instead.


Should be depends_fetch, and might also need to set git.cmd to 
${prefix}/bin/git, but yes, it's certainly possible without a base update.


- Josh

Re: emacs-app-devel build fail on master not detected by buildbot

[Christopher Jones]

> On 23 Apr 2021, at 3:48 am, Dan Ports  wrote:
> 
> On Thu, Apr 22, 2021 at 11:05:34PM +0900, Aaron Madlon-Kay wrote:
>> However it was rejected by the maintainer because he *wants* the current 
>> setup. If the port no longer builds because the referenced commit is more 
>> than 1,000 commits in the past, then the port is ripe for a bump. Increasing 
>> the depth or using a date-based strategy will just balloon the amount of 
>> data fetched.
> 
> To be clear, the problem here was that MacPorts uses the xcode-provided
> git, and certain older systems have a version of git that's too old to
> support the --shallow-since option, causing the port to break on
> systems where it's buildable today.
> 
> Now, those systems are pretty old at this point (IIRC, it was El
> Capitan and older) so perhaps that is worth reconsidering. We could
> also install and use our own version of git on older systems as we do
> for some other fetch/extract dependencies, but that would require a
> base update.

why a base update ? Just adding port:git as a build dep would do it, as port 
would then use that version instead.

Chris

> 
> Dan
> 
> -- 
> Dan R. K. Ports  https://drkp.net/



smime.p7s
Description: S/MIME cryptographic signature

Re: emacs-app-devel build fail on master not detected by buildbot

[Aaron Madlon-Kay]

For the general case an update to MacPorts base would be required, but
for the purposes of any given port shouldn't it be sufficient to do
`depends_fetch-append port:git`?

And my apologies; it wasn't you, Dan, who took the position I
described earlier, it was another commentator:
https://github.com/macports/macports-ports/pull/9295#discussion_r532780239

-Aaron

Re: emacs-app-devel build fail on master not detected by buildbot

[Dan Ports]

On Thu, Apr 22, 2021 at 11:05:34PM +0900, Aaron Madlon-Kay wrote:
> However it was rejected by the maintainer because he *wants* the current 
> setup. If the port no longer builds because the referenced commit is more 
> than 1,000 commits in the past, then the port is ripe for a bump. Increasing 
> the depth or using a date-based strategy will just balloon the amount of data 
> fetched.

To be clear, the problem here was that MacPorts uses the xcode-provided
git, and certain older systems have a version of git that's too old to
support the --shallow-since option, causing the port to break on
systems where it's buildable today.

Now, those systems are pretty old at this point (IIRC, it was El
Capitan and older) so perhaps that is worth reconsidering. We could
also install and use our own version of git on older systems as we do
for some other fetch/extract dependencies, but that would require a
base update.

Dan

-- 
Dan R. K. Ports  https://drkp.net/

Re: emacs-app-devel build fail on master not detected by buildbot

[Ryan Schmidt]

On Apr 22, 2021, at 18:22, Nathaniel W Griswold wrote:

> So are you guys just gonna point to the new commit and otherwise keep it the 
> same? I think maybe it should change.

I'll just weigh in to say that the purpose of our buildbot setup (the way that 
it is currently conceived) is to build binary packages that are distributed to 
users when they install ports. The purpose of the buildbot is not to 
periodically rebuild ports to discover breakages.

In this case, the problem occurred because the maintainer of the port did not 
update it before it broke. The maintainer should get into the habit of updating 
the port before it breaks and/or the maintainer should set the fetch depth such 
that the port will not break before the next time they update the port.

Re: emacs-app-devel build fail on master not detected by buildbot

[Nathaniel W Griswold]

So are you guys just gonna point to the new commit and otherwise keep it the 
same? I think maybe it should change.

Nate

> On Apr 22, 2021, at 4:55 PM, Christopher Jones  
> wrote:
> 
> 
> 
>> On 22 Apr 2021, at 10:44 pm, Aaron Madlon-Kay  wrote:
>> 
>>> all it does is save a bit of bandwidth during the fetch
>> 
>> In the case of Emacs, it saves *gigabytes* during fetch.
> 
> OK, fair enough. I didn’t realise emacs had quite that much history ;)…
> 
>> 
>> The depth restriction was a lifesaver when I worked on the nativecomp 
>> variant a while back. 
>> 
>> -Aaron
> 

Re: emacs-app-devel build fail on master not detected by buildbot

[Christopher Jones]

> On 22 Apr 2021, at 10:44 pm, Aaron Madlon-Kay  wrote:
> 
> > all it does is save a bit of bandwidth during the fetch
> 
> In the case of Emacs, it saves *gigabytes* during fetch.

OK, fair enough. I didn’t realise emacs had quite that much history ;)…

> 
> The depth restriction was a lifesaver when I worked on the nativecomp variant 
> a while back. 
> 
> -Aaron



smime.p7s
Description: S/MIME cryptographic signature

Re: emacs-app-devel build fail on master not detected by buildbot

[Aaron Madlon-Kay]

> all it does is save a bit of bandwidth during the fetch

In the case of Emacs, it saves *gigabytes* during fetch.

The depth restriction was a lifesaver when I worked on the nativecomp
variant a while back.

-Aaron

Re: emacs-app-devel build fail on master not detected by buildbot

[Christopher Jones]

> On 22 Apr 2021, at 10:04 pm, Christopher Jones  
> wrote:
> 
> 
> 
>> On 22 Apr 2021, at 9:59 pm, Nathaniel W Griswold  
>> wrote:
>> 
>> Thank you, Christopher.
>> 
>> Are you saying the date-style depth would be the right way forward? That 
>> seems fine and then the maintainers could either keep up or not. The current 
>> idea of using the breakage event as a signal to update the port file is 
>> kinda bad IMO.
> 
> I was simply stating that updating the port is anyway a good thing to do, and 
> would fix the current issue.
> 
> But yes, on the 1000 depth thing I agree that doesn’t seem like a great thing 
> to be doing in the port file, but thats the maintainers decision to change ….

… but changing it to 3000 doesn’t do anything but delay the inevitable… I would 
just remove it, as we don’t really do this sort of thing elsewhere where we 
perform git fetches, and as fas as I can see all it does is save a bit of 
bandwidth during the fetch…..

> 
> Chris
> 
> 
>> 
>> Nate
>> 
>>> On Apr 22, 2021, at 3:55 PM, Christopher Jones  
>>> wrote:
>>> 
>>> 
>>> 
 On 22 Apr 2021, at 3:05 pm, Aaron Madlon-Kay  wrote:
 
 I proposed in a past PR to emacs-app-devel to use a modern git flag that 
 lets you specify a depth based on commit date. That would be the “real” 
 solution in the direction you’re going.
 
 However it was rejected by the maintainer because he *wants* the current 
 setup. If the port no longer builds because the referenced commit is more 
 than 1,000 commits in the past, then the port is ripe for a bump. 
 Increasing the depth or using a date-based strategy will just balloon the 
 amount of data fetched.
 
 So rather than increasing the depth to 3,000, I recommend you either:
 
 - bump the commit to a recent one, or
 - file a Trac ticket so that someone else is prompted to do so
>>> 
>>> Indeed that is the correct way forward really…
>>> 
>>> https://github.com/macports/macports-ports/commit/6fb61146fb988bd75fe7bc5a209544b30b560692
>>> 
 
 Thanks,
 Aaron
 
 
> On Apr 22, 2021, at 22:29, Nathaniel W Griswold  
> wrote:
> 
> I use the subport emacs-app-devel (subport of emacs) on my 10.15 Catalina 
> system (with variants +imagemagick, +rsvg). The build failed during my 
> last port upgrade outdated and i investigated why.
> 
> The external git mirror (https://github.com/emacs-mirror/emacs.git) has 
> exceeded 1000 new commits since the commit referenced by the Portfile 
> (80e26472206cc44837521ba594cd50e724d9af5c). Since the clone produced from 
> the Portfile uses depth 1000, This means that port cannot check out that 
> commit in its local checkout and the port build fails on that step.
> 
> I thought about it a bit and i feel like if the logic to trigger a build 
> is already Portfile-aware this could be detected with a small change to 
> the system. If a git clone with a —depth=${val} is found in the Portfile 
> for a port or subport, then the build system could trigger a build 
> periodically at some rate that doesn’t stress the build setup too much. I 
> don’t know how many Portfiles have `git clone —depth=${val} ${repo}` 
> git.url values but if there aren’t that many you could trigger these 
> builds quite often.
> 
> I will increase the depth to 3000 for now and submit my updated Portfile.
> 
> Thank you
> 
> Nate
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: emacs-app-devel build fail on master not detected by buildbot

[Christopher Jones]

> On 22 Apr 2021, at 9:59 pm, Nathaniel W Griswold  wrote:
> 
> Thank you, Christopher.
> 
> Are you saying the date-style depth would be the right way forward? That 
> seems fine and then the maintainers could either keep up or not. The current 
> idea of using the breakage event as a signal to update the port file is kinda 
> bad IMO.

I was simply stating that updating the port is anyway a good thing to do, and 
would fix the current issue.

But yes, on the 1000 depth thing I agree that doesn’t seem like a great thing 
to be doing in the port file, but thats the maintainers decision to change ….

Chris


> 
> Nate
> 
>> On Apr 22, 2021, at 3:55 PM, Christopher Jones  
>> wrote:
>> 
>> 
>> 
>>> On 22 Apr 2021, at 3:05 pm, Aaron Madlon-Kay  wrote:
>>> 
>>> I proposed in a past PR to emacs-app-devel to use a modern git flag that 
>>> lets you specify a depth based on commit date. That would be the “real” 
>>> solution in the direction you’re going.
>>> 
>>> However it was rejected by the maintainer because he *wants* the current 
>>> setup. If the port no longer builds because the referenced commit is more 
>>> than 1,000 commits in the past, then the port is ripe for a bump. 
>>> Increasing the depth or using a date-based strategy will just balloon the 
>>> amount of data fetched.
>>> 
>>> So rather than increasing the depth to 3,000, I recommend you either:
>>> 
>>> - bump the commit to a recent one, or
>>> - file a Trac ticket so that someone else is prompted to do so
>> 
>> Indeed that is the correct way forward really…
>> 
>> https://github.com/macports/macports-ports/commit/6fb61146fb988bd75fe7bc5a209544b30b560692
>> 
>>> 
>>> Thanks,
>>> Aaron
>>> 
>>> 
 On Apr 22, 2021, at 22:29, Nathaniel W Griswold  
 wrote:
 
 I use the subport emacs-app-devel (subport of emacs) on my 10.15 Catalina 
 system (with variants +imagemagick, +rsvg). The build failed during my 
 last port upgrade outdated and i investigated why.
 
 The external git mirror (https://github.com/emacs-mirror/emacs.git) has 
 exceeded 1000 new commits since the commit referenced by the Portfile 
 (80e26472206cc44837521ba594cd50e724d9af5c). Since the clone produced from 
 the Portfile uses depth 1000, This means that port cannot check out that 
 commit in its local checkout and the port build fails on that step.
 
 I thought about it a bit and i feel like if the logic to trigger a build 
 is already Portfile-aware this could be detected with a small change to 
 the system. If a git clone with a —depth=${val} is found in the Portfile 
 for a port or subport, then the build system could trigger a build 
 periodically at some rate that doesn’t stress the build setup too much. I 
 don’t know how many Portfiles have `git clone —depth=${val} ${repo}` 
 git.url values but if there aren’t that many you could trigger these 
 builds quite often.
 
 I will increase the depth to 3000 for now and submit my updated Portfile.
 
 Thank you
 
 Nate
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: emacs-app-devel build fail on master not detected by buildbot

[Nathaniel W Griswold]

Thank you, Christopher.

Are you saying the date-style depth would be the right way forward? That seems 
fine and then the maintainers could either keep up or not. The current idea of 
using the breakage event as a signal to update the port file is kinda bad IMO.

Nate

> On Apr 22, 2021, at 3:55 PM, Christopher Jones  
> wrote:
> 
> 
> 
>> On 22 Apr 2021, at 3:05 pm, Aaron Madlon-Kay  wrote:
>> 
>> I proposed in a past PR to emacs-app-devel to use a modern git flag that 
>> lets you specify a depth based on commit date. That would be the “real” 
>> solution in the direction you’re going.
>> 
>> However it was rejected by the maintainer because he *wants* the current 
>> setup. If the port no longer builds because the referenced commit is more 
>> than 1,000 commits in the past, then the port is ripe for a bump. Increasing 
>> the depth or using a date-based strategy will just balloon the amount of 
>> data fetched.
>> 
>> So rather than increasing the depth to 3,000, I recommend you either:
>> 
>> - bump the commit to a recent one, or
>> - file a Trac ticket so that someone else is prompted to do so
> 
> Indeed that is the correct way forward really…
> 
> https://github.com/macports/macports-ports/commit/6fb61146fb988bd75fe7bc5a209544b30b560692
> 
>> 
>> Thanks,
>> Aaron
>> 
>> 
>>> On Apr 22, 2021, at 22:29, Nathaniel W Griswold  
>>> wrote:
>>> 
>>> I use the subport emacs-app-devel (subport of emacs) on my 10.15 Catalina 
>>> system (with variants +imagemagick, +rsvg). The build failed during my last 
>>> port upgrade outdated and i investigated why.
>>> 
>>> The external git mirror (https://github.com/emacs-mirror/emacs.git) has 
>>> exceeded 1000 new commits since the commit referenced by the Portfile 
>>> (80e26472206cc44837521ba594cd50e724d9af5c). Since the clone produced from 
>>> the Portfile uses depth 1000, This means that port cannot check out that 
>>> commit in its local checkout and the port build fails on that step.
>>> 
>>> I thought about it a bit and i feel like if the logic to trigger a build is 
>>> already Portfile-aware this could be detected with a small change to the 
>>> system. If a git clone with a —depth=${val} is found in the Portfile for a 
>>> port or subport, then the build system could trigger a build periodically 
>>> at some rate that doesn’t stress the build setup too much. I don’t know how 
>>> many Portfiles have `git clone —depth=${val} ${repo}` git.url values but if 
>>> there aren’t that many you could trigger these builds quite often.
>>> 
>>> I will increase the depth to 3000 for now and submit my updated Portfile.
>>> 
>>> Thank you
>>> 
>>> Nate

Re: emacs-app-devel build fail on master not detected by buildbot

[Christopher Jones]

> On 22 Apr 2021, at 3:05 pm, Aaron Madlon-Kay  wrote:
> 
> I proposed in a past PR to emacs-app-devel to use a modern git flag that lets 
> you specify a depth based on commit date. That would be the “real” solution 
> in the direction you’re going.
> 
> However it was rejected by the maintainer because he *wants* the current 
> setup. If the port no longer builds because the referenced commit is more 
> than 1,000 commits in the past, then the port is ripe for a bump. Increasing 
> the depth or using a date-based strategy will just balloon the amount of data 
> fetched.
> 
> So rather than increasing the depth to 3,000, I recommend you either:
> 
> - bump the commit to a recent one, or
> - file a Trac ticket so that someone else is prompted to do so

Indeed that is the correct way forward really…

https://github.com/macports/macports-ports/commit/6fb61146fb988bd75fe7bc5a209544b30b560692
 


> 
> Thanks,
> Aaron
> 
> 
>> On Apr 22, 2021, at 22:29, Nathaniel W Griswold  wrote:
>> 
>> I use the subport emacs-app-devel (subport of emacs) on my 10.15 Catalina 
>> system (with variants +imagemagick, +rsvg). The build failed during my last 
>> port upgrade outdated and i investigated why.
>> 
>> The external git mirror (https://github.com/emacs-mirror/emacs.git) has 
>> exceeded 1000 new commits since the commit referenced by the Portfile 
>> (80e26472206cc44837521ba594cd50e724d9af5c). Since the clone produced from 
>> the Portfile uses depth 1000, This means that port cannot check out that 
>> commit in its local checkout and the port build fails on that step.
>> 
>> I thought about it a bit and i feel like if the logic to trigger a build is 
>> already Portfile-aware this could be detected with a small change to the 
>> system. If a git clone with a —depth=${val} is found in the Portfile for a 
>> port or subport, then the build system could trigger a build periodically at 
>> some rate that doesn’t stress the build setup too much. I don’t know how 
>> many Portfiles have `git clone —depth=${val} ${repo}` git.url values but if 
>> there aren’t that many you could trigger these builds quite often.
>> 
>> I will increase the depth to 3000 for now and submit my updated Portfile.
>> 
>> Thank you
>> 
>> Nate
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: emacs-app-devel build fail on master not detected by buildbot

[Aaron Madlon-Kay]

I proposed in a past PR to emacs-app-devel to use a modern git flag that lets 
you specify a depth based on commit date. That would be the “real” solution in 
the direction you’re going.

However it was rejected by the maintainer because he *wants* the current setup. 
If the port no longer builds because the referenced commit is more than 1,000 
commits in the past, then the port is ripe for a bump. Increasing the depth or 
using a date-based strategy will just balloon the amount of data fetched.

So rather than increasing the depth to 3,000, I recommend you either:

- bump the commit to a recent one, or
- file a Trac ticket so that someone else is prompted to do so

Thanks,
Aaron


> On Apr 22, 2021, at 22:29, Nathaniel W Griswold  wrote:
> 
> I use the subport emacs-app-devel (subport of emacs) on my 10.15 Catalina 
> system (with variants +imagemagick, +rsvg). The build failed during my last 
> port upgrade outdated and i investigated why.
> 
> The external git mirror (https://github.com/emacs-mirror/emacs.git) has 
> exceeded 1000 new commits since the commit referenced by the Portfile 
> (80e26472206cc44837521ba594cd50e724d9af5c). Since the clone produced from the 
> Portfile uses depth 1000, This means that port cannot check out that commit 
> in its local checkout and the port build fails on that step.
> 
> I thought about it a bit and i feel like if the logic to trigger a build is 
> already Portfile-aware this could be detected with a small change to the 
> system. If a git clone with a —depth=${val} is found in the Portfile for a 
> port or subport, then the build system could trigger a build periodically at 
> some rate that doesn’t stress the build setup too much. I don’t know how many 
> Portfiles have `git clone —depth=${val} ${repo}` git.url values but if there 
> aren’t that many you could trigger these builds quite often.
> 
> I will increase the depth to 3000 for now and submit my updated Portfile.
> 
> Thank you
> 
> Nate

Re: emacs-app-devel build fail on master not detected by buildbot

[Nathaniel W Griswold]

While i agree with the maintainer that the port should be kept up to date, i 
did spend quite a bit of time investigating this issue on my machine. I hadn’t 
worked on a port in a while so i had to get the rust off and spend time on 
digging to find out what was wrong. While i wasn’t too busy today, and that’s 
the reason i was able to dig into it, it remains that this was an issue that 
has already come up and so this is actually time that i could have spent on my 
actual work instead. I’m sure it will happen to other people. We need a 
solution so it doesn’t happen again. Your recommendation to me in keeping with 
the maintainer’s solutions does not seem it will prevent the problem from 
reocurring. Additionally, the solution you previously proposed to the 
maintainer does not keep the package up to date with git.

Adding the ability to explicitly flag the port as ‘volatile’ or some such 
either directly in the Portfile or in any build meta info that exists would 
prevent people who are mostly just users like myself from suffering lost time 
in their day because of broken builds. Even if we all go to macports support 
when it happens and the dev team does all the work, it’s still a problem. I 
think this should be automated in the buildbot, or all maintainers of such 
ports should get some kind of regular reminder to update their port, or such 
ports should just have an explicit shelf life to compute future expiration 
date, or pretty much anything so users don’t suffer the consequences.

Do you agree?

Nate

> On Apr 22, 2021, at 9:05 AM, Aaron Madlon-Kay  wrote:
> 
> I proposed in a past PR to emacs-app-devel to use a modern git flag that lets 
> you specify a depth based on commit date. That would be the “real” solution 
> in the direction you’re going.
> 
> However it was rejected by the maintainer because he *wants* the current 
> setup. If the port no longer builds because the referenced commit is more 
> than 1,000 commits in the past, then the port is ripe for a bump. Increasing 
> the depth or using a date-based strategy will just balloon the amount of data 
> fetched.
> 
> So rather than increasing the depth to 3,000, I recommend you either:
> 
> - bump the commit to a recent one, or
> - file a Trac ticket so that someone else is prompted to do so
> 
> Thanks,
> Aaron
> 
> 
>> On Apr 22, 2021, at 22:29, Nathaniel W Griswold  wrote:
>> 
>> I use the subport emacs-app-devel (subport of emacs) on my 10.15 Catalina 
>> system (with variants +imagemagick, +rsvg). The build failed during my last 
>> port upgrade outdated and i investigated why.
>> 
>> The external git mirror (https://github.com/emacs-mirror/emacs.git) has 
>> exceeded 1000 new commits since the commit referenced by the Portfile 
>> (80e26472206cc44837521ba594cd50e724d9af5c). Since the clone produced from 
>> the Portfile uses depth 1000, This means that port cannot check out that 
>> commit in its local checkout and the port build fails on that step.
>> 
>> I thought about it a bit and i feel like if the logic to trigger a build is 
>> already Portfile-aware this could be detected with a small change to the 
>> system. If a git clone with a —depth=${val} is found in the Portfile for a 
>> port or subport, then the build system could trigger a build periodically at 
>> some rate that doesn’t stress the build setup too much. I don’t know how 
>> many Portfiles have `git clone —depth=${val} ${repo}` git.url values but if 
>> there aren’t that many you could trigger these builds quite often.
>> 
>> I will increase the depth to 3000 for now and submit my updated Portfile.
>> 
>> Thank you
>> 
>> Nate
> 

Publicizing MacPorts

[Steven Smith]


> 
> Ironically, MacPorts is claimed to have "initial or beta support" for
> Apple silicon on https://isapplesiliconready.com/

Another reason major news like M1 support must be announced.

As a volunteer, I could quickly post a correction, but in doing so this website 
reasonably asks for a reference link, for which there is none because MacPorts 
has made no such announcement.

If MacPorts doesn’t tell its story, someone else will.

> On Apr 22, 2021, at 10:09, Zero King  wrote:
> 
> On Mon, Apr 19, 2021 at 01:24:51PM +0200, Mojca Miklavec wrote:
>>> On Mon, 19 Apr 2021 at 12:45, Steven Smith wrote:
>>> If a comparable announcement to this was made for MacPorts, I missed it:
>>> https://arstechnica.com/gadgets/2021/02/mac-utility-homebrew-finally-gets-native-apple-silicon-and-m1-support/
>> We never made any announcement since it basically "worked from day 1"
>> (almost), and we never had any specific point in time when support for
>> M1 was significantly improved. (We probably needed an upgrade of
>> MacPorts base, but that happened very soon.)
>> We should probably be publicising that MacPorts works just fine with
>> M1 more aggressively from the very beginning.
> 
> Ironically, MacPorts is claimed to have "initial or beta support" for
> Apple silicon on https://isapplesiliconready.com/ (top search result for
> "is m1 ready" on Google), while Homebrew is "fully compatible".
> 
>> If anyone is willing to volunteer to do PR for MacPorts ...
>> Mojca

Re: Publicizing MacPorts

[Zero King]

On Mon, Apr 19, 2021 at 01:24:51PM +0200, Mojca Miklavec wrote:

On Mon, 19 Apr 2021 at 12:45, Steven Smith wrote:


If a comparable announcement to this was made for MacPorts, I missed it:

https://arstechnica.com/gadgets/2021/02/mac-utility-homebrew-finally-gets-native-apple-silicon-and-m1-support/


We never made any announcement since it basically "worked from day 1"
(almost), and we never had any specific point in time when support for
M1 was significantly improved. (We probably needed an upgrade of
MacPorts base, but that happened very soon.)

We should probably be publicising that MacPorts works just fine with
M1 more aggressively from the very beginning.


Ironically, MacPorts is claimed to have "initial or beta support" for
Apple silicon on https://isapplesiliconready.com/ (top search result for
"is m1 ready" on Google), while Homebrew is "fully compatible".


If anyone is willing to volunteer to do PR for MacPorts ...

Mojca

emacs-app-devel build fail on master not detected by buildbot

[Nathaniel W Griswold]

I use the subport emacs-app-devel (subport of emacs) on my 10.15 Catalina 
system (with variants +imagemagick, +rsvg). The build failed during my last 
port upgrade outdated and i investigated why.

The external git mirror (https://github.com/emacs-mirror/emacs.git) has 
exceeded 1000 new commits since the commit referenced by the Portfile 
(80e26472206cc44837521ba594cd50e724d9af5c). Since the clone produced from the 
Portfile uses depth 1000, This means that port cannot check out that commit in 
its local checkout and the port build fails on that step.

I thought about it a bit and i feel like if the logic to trigger a build is 
already Portfile-aware this could be detected with a small change to the 
system. If a git clone with a —depth=${val} is found in the Portfile for a port 
or subport, then the build system could trigger a build periodically at some 
rate that doesn’t stress the build setup too much. I don’t know how many 
Portfiles have `git clone —depth=${val} ${repo}` git.url values but if there 
aren’t that many you could trigger these builds quite often.

I will increase the depth to 3000 for now and submit my updated Portfile.

Thank you

Nate

Re: Help Understanding Code Signing

[Ryan Schmidt]

On Apr 22, 2021, at 00:09, Marcus Calhoun-Lopez wrote:

> I must admit that whan issues like code signing come up, I tend to
> tune out, so please forgive me if this is well trodden territory.
> 
> While working on the netgen, I added the following code to get the
> destroot phase working (where ${pdv} is 3.8, 3.9, etc.):
>destroot.env-append
> PYTHONPATH=${destroot}${prefix}/lib/python${pdv}/site-packages/ \
> 
> DYLD_LIBRARY_PATH=${destroot}${prefix}/lib
> 
> In the CMake file, PYTHONPATH is respected by execute_process [1], but
> DYLD_LIBRARY_PATH is not.
> From what I can tell, this is an OS issue and not a cmake problem [2].
> Apparently, the solution is to run codesign on cmake.
> Is this at all feasible?
> Is there another possible workaround anyone can think of?
> I am afraid I know little to nothing about how codesign [3] works.
> 
> Thank you,
> Marcus
> 
> [1] https://cmake.org/cmake/help/latest/command/execute_process.html
> [2] https://gitlab.kitware.com/cmake/cmake/-/issues/20678
> [3] 
> https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

https://gitlab.kitware.com/cmake/cmake/-/issues/20678 seems to be about 
restrictions encountered when using a binary distributed by cmake.org. The 
reporter said he did not experience those restrictions when building cmake 
himself or when using cmake from Homebrew, so I would not expect you to 
experience those restrictions with cmake from MacPorts either. Presumably the 
binary from cmake.org is built with settings (hardened runtime?) that cause 
this to occur, settings that we are presumably not using.

DYLD_LIBRARY_PATH needs to be set when invoking the binary that needs it. Ever 
since OS X 10.11, DYLD environment variables are not inherited by subprocesses, 
so you can't just set it at the top level and expect it to be there in whatever 
subprocess or subsubprocess needs it. (Other environment variables are still 
inherited.) So you might need to follow the execution path a little and figure 
out where the executable that needs DYLD_LIBRARY_PATH is being run and set 
DYLD_LIBRARY_PATH when running it.

Re: Buildbots down?

[Ryan Schmidt]

On Apr 21, 2021, at 11:36, Herby G wrote:

> https://build.macports.org/ is unreachable.

Maybe there was a temporary problem with my Internet connection? It was up when 
I checked it.

Re: FileZilla: current version requires SDK 11

[Ryan Schmidt]

On Apr 21, 2021, at 10:55, Lothar Haeger wrote:

> Sorry for the long delay, busy times had me loose this topic out of sight a 
> bit.
> 
>> Would it help if we had a port in MacPorts that installed the macOS 11 SDK?
> 
> I'm not sure about that, since I have XCode 12.4 (which afaik includes the 
> latest SDK) installed on Catalina 10.15.7:

Yes, then you already have the macOS 11 SDK.


>> $ ls -l /Library/Developer/CommandLineTools/SDKs/
>> total 0
>> lrwxr-xr-x 1 root wheel  14 Mar 13 11:44 MacOSX.sdk -> MacOSX11.1.sdk
>> drwxr-xr-x 7 root wheel 224 Jun  7  2020 MacOSX10.14.sdk
>> drwxr-xr-x 8 root wheel 256 Mar 13 11:44 MacOSX10.15.sdk
>> drwxr-xr-x 7 root wheel 224 Mar 13 11:44 MacOSX11.1.sdk
> 
> Nevertheless 'port build' fails and main.log starts with:
> 
>> version:1
>> :debug:sysinfo macOS 10.15 (darwin/19.6.0) arch i386
>> :debug:sysinfo MacPorts 2.6.4
>> :debug:sysinfo Xcode 12.4
>> :debug:sysinfo SDK 10.15

This "SDK" is the SDK MacPorts wants to use. It does not indicate the SDK that 
actually exists on your system. If the SDK indicated here does not exist, it 
will use whatever SDK does exist.


> My guess is that the last of those line hints at the cause of the problems, 
> i.e. port is not using the latest available SDK but the one matching the OS 
> version.
> 
>> Could FileZilla build using that on older systems?
> 
> Is there a way to specify the SDK version to be used in a Portfile? If so, 
> adding a dependency for an SDK port may help. If not, I do not see how SDK 
> ports will change anything.

Since you already have the macOS 11 SDK, I agree that providing a port for the 
macOS 11 SDK would do nothing to help this situation.

It has been awhile since this thread has started and I forget the other 
details. If you are still having trouble building FileZilla, please file a bug 
report; I don't see any filed for FileZilla right now.

Help Understanding Code Signing

[Marcus Calhoun-Lopez]

I must admit that whan issues like code signing come up, I tend to
tune out, so please forgive me if this is well trodden territory.

While working on the netgen, I added the following code to get the
destroot phase working (where ${pdv} is 3.8, 3.9, etc.):
destroot.env-append
PYTHONPATH=${destroot}${prefix}/lib/python${pdv}/site-packages/ \

DYLD_LIBRARY_PATH=${destroot}${prefix}/lib

In the CMake file, PYTHONPATH is respected by execute_process [1], but
DYLD_LIBRARY_PATH is not.
>From what I can tell, this is an OS issue and not a cmake problem [2].
Apparently, the solution is to run codesign on cmake.
Is this at all feasible?
Is there another possible workaround anyone can think of?
I am afraid I know little to nothing about how codesign [3] works.

Thank you,
Marcus

[1] https://cmake.org/cmake/help/latest/command/execute_process.html
[2] https://gitlab.kitware.com/cmake/cmake/-/issues/20678
[3] 
https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

Re: Publicizing MacPorts

[Jason Liu]

On Wed, Apr 21, 2021 at 10:42 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> A set of pages with some screenshots of some of the cool GUI software and
> games, like SNAP has for Ubuntu.


To piggyback off Ken's statement, as a part of the modernization efforts
for the website, it would be nice to have a section or infobox on the
MacPorts front page with either a featured "App of the Day" or "App of the
Week", similar to what is in the iOS/Mac App Store. Just off the top of my
head, I can think of over a dozen candidates, including GIMP, Inkscape,
VLC, Blender, Audacity, KeePassXC, Battle for Wesnoth, SuperTuxKart, etc.
We could even automatically populate the text of the infobox with the
long_description directly from the portfiles. Add some pretty screenshots,
and of course, the bottom would always say something like:

To install this app using MacPorts, run this command

sudo port install gimp

in a terminal window.

We could even make it so that if a visitor to the website clicks on the
text for the "sudo port install" line, it automatically copies the command
to their clipboard. I think that just adding this one thing could make the
MacPorts website feel more lively and dynamic.

I can also help with a redesign or modernization of the public-facing
website. I did some professional web design work to put myself through
college. I'm more of a web programmer than a graphic designer, but taking
good-looking screenshots of apps shouldn't be too difficult. Even better
would be to scrape the screenshots directly from the project authors'
websites, since they are much more likely to have up-to-date screenshots
whenever they make changes to their UI.

-- 
Jason Liu


On Wed, Apr 21, 2021 at 10:42 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> various people have come along with some good ideas over the five years
> I’ve been around.
>
> A set of pages with some screenshots of some of the cool GUI software and
> games, like SNAP has for Ubuntu.
>
> A rewrite of the very old and dated and cobwebby website.
>
> To be honest —  these people in the end have not been encouraged to
> proceed. “I’ll get to that” or “Who is going to do that?” or “Why should we
> do that?” are far more common responses.
>
> So — start there, I would volunteer.
>
> Ken