>
> 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.
>
> I
On Apr 22, 2021, at 21:48, 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.
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
> 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
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 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
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
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 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
> 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: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
> 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
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 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
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
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 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
17 matches
Mail list logo
