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 s
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-suppo
>
> 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 refe
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
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 b
> 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
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 P
> 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
> 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
> 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
> 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
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 dur
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
On Apr 22, 2021, at 01:49, Ryan Schmidt wrote:
> 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.
I have seen intermittent failures today, also when loo
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
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.co
> 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 i
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 br
18 matches
Mail list logo
