few ports at a time when they had free time, it might help to
clear out the backlog.
Perry
--
Perry E. Metzgerpe...@piermont.com
on initial 2nd macports
> > install), without taking any cpu.
>
> fc-cache may just be doing a lot of IO. Try running
> $> sudo opensnoop -n fc-cache
> in a separate terminal to see whether it is in fact hanging or just
> taking a long time.
>
I've persona
rts or updates to old ones? It would be good
to update those as well.
Perry
--
Perry E. Metzgerpmetz...@macports.org
On Mon, 9 Apr 2018 16:29:56 + Zero King wrote:
> On Mon, Apr 09, 2018 at 12:10:47PM -0400, Perry E. Metzger wrote:
> >> I'm following the (obviously out-of-date) guide at
> >> https://trac.macports.org/wiki/howto/Upgrade
> >> but I'll try and
ink, but most people seem to have one of those these days.)
Perry
--
Perry E. Metzgerpe...@piermont.com
t; I will be updating the list and probably put it up on wiki, so that
> in future we don't spend time looking for the updated tarballs.
Rather than putting this in the Wiki, is there a way to fix the
Portfile so that we don't get a false positive trigger? Then people
don't have
(or at least forks of it) have already been
ported to MacOS for use by other projects.
I would not suggest that the practice of building packages in isolated
VMs be changed, as that provides a lot of nice isolation and
security, but it might be nice to steal a tool like "fakeroot&q
e not perfect in reviewing code. If we were, we wouldn't
need a CI system in the first place.
Perry
--
Perry E. Metzgerpe...@piermont.com
ll be merged very
quickly.
Apologies for the fact that I'm not also going through the Trac
tickets but there may be some progress on that sometime soon as well.
Alternatively, you can ask for review of existing Trac tickets here
by sending email with links, though I personally mostly do PRs.
Perry
--
Perry E. Metzgerpmetz...@macports.org
quite fast.
[By the way, if someone wants to turn this email into a document, I
was pretty careful writing what's above so that would be easy.]
> Maybe submitters in trac could be notified en masse to also do so.
We're still working out the best way to handle that.
--
Perry E. Metzgerpe...@piermont.com
acted on in, at most, a few months the submitter must
> have found another way to scratch their itch. Or the itch wasn't
> serious.
This is part of why I've been keeping the PR queue as clean as I can,
so that people feel like their fixes will be acted on quickly. I think
with time we can fix the Trac queue as well.
Perry
--
Perry E. Metzgerpe...@piermont.com
I just committed a new section of the guide called "Using Git
and GitHub". Please read, comment, and improve.
Perry
--
Perry E. Metzgerpmetz...@macports.org
On Wed, 11 Apr 2018 17:54:23 -0400 Andrew Moore
wrote:
> > On Apr 11, 2018, at 5:31 PM, Perry E. Metzger
> > wrote:
> >
> > I just committed a new section of the guide called "Using Git
> > and GitHub". Please read, comment, and improve.
>
> Um, sub
begin: SUBMIT CODE AS GITHUB
> PULL. REQUESTS. IF YOU JUST WANT TO $#!@, PLEASE USE TRAC -AM
Perry
--
Perry E. Metzgerpmetz...@macports.org
! but if you're using trac, do this!"
Perry
--
Perry E. Metzgerpmetz...@macports.org
emove support for 3.4 ASAP.
Not sure here, but generally, I think it's better to try to move
forward.
Perry
--
Perry E. Metzgerpe...@piermont.com
e
of Trac. If you find Trac is vastly easier, then use that for now.
The price is that you may not get attention to your requests as
quickly.
Perry
--
Perry E. Metzgerpmetz...@macports.org
f the submitter and commit them, but lets ignore that
possibility for now.)
Perry
--
Perry E. Metzgerpmetz...@macports.org
On Sat, 14 Apr 2018 18:31:51 -0500 Ryan Schmidt
wrote:
> On Apr 14, 2018, at 09:37, Perry E. Metzger wrote:
>
> > We have one open PR where the submitter hasn't replied to some
> > requests for changes since the initial request several weeks ago.
> > (I tried emailin
k correctly with updated version but I
> was able to pin point to only errors that I encountered (by running
> just port -d build/destroot/install acl2) but there might be other
> changes too that may be required. Do we run each and every variant
> combination and test the portfile or is t
superior.
I suspect that the names aren't reasonable, in that -devel isn't the
development branch of acl2, but is an unrelated fork at this point.
Perry
--
Perry E. Metzgerpe...@piermont.com
to tweak it to do it for me. :)
(By default, opam installs into a .opam/VERSION/ directory for the
user, in which there's bin, lib, man etc. directories.)
It's possible everything is in the developer guide and I've just
failed to notice sufficiently.
Perry
--
Perry E. Metzger
On Tue, 17 Apr 2018 13:32:53 -0400 "Perry E. Metzger"
wrote:
> Is there any documentation I can read about how the various build
> and install stages work? I am trying to rig things up so that I can
> use opam (the ocaml package manager) to do all the heavy lifting
> for t
On Tue, 17 Apr 2018 22:33:10 -0500 Ryan Schmidt
wrote:
> On Apr 17, 2018, at 12:39, Perry E. Metzger wrote:
>
> > Just to be clear: I know what is in:
> > https://guide.macports.org/#reference.phases
> >
> > but I'm trying to figure out a bit more detail. In
and also create ports for all
> dependencies.
>
> For example, cpan2port or pypi2port in macports-contrib [1,2] do
> that for Perl or Python, respectively. They are far from perfect,
> but are a great help to get an initial Portfile.
Maybe this is the right approach. Is this genera
domain qpl restrictive/distributable ruby sleepycat
+ssleay tcl/tk vim w3c wtfpl wxwidgets x11 zlib zpl
+
+
If the version number is a
.0 version, the .0 should be
omitted to make the version an integer. If the author gives the choice
--
Perry E. Metzger
On Mon, 23 Apr 2018 15:24:20 -0500 Ryan Schmidt
wrote:
> On Apr 23, 2018, at 14:19, Perry E. Metzger wrote:
>
> > I'm thinking of adding the following to the MacPorts guide
> > because we often have problems with people picking invalid
> > license names in Portfi
suggest that we remove this from being openmaintainer given that
simple version bumps won't work well without inside knowledge?
I'll go in now and try to fix what I damaged.
(As for why I was playing with this, it's the only client of
protobuf-c...)
Perry
--
Perry E. Metzgerpmetz...@macports.org
ix what I damaged.
>
> No worries, I am looking into it. The update is long overdue anyway.
I've sent you a list privately with the list of plugins that are
apparently missing.
Perry
--
Perry E. Metzgerpmetz...@macports.org
On Tue, 24 Apr 2018 16:50:57 +1000 Joshua Root
wrote:
> On 2018-4-24 08:48 , Perry E. Metzger wrote:
> > On Mon, 23 Apr 2018 23:58:23 +0200 Rainer Müller
> > wrote:
> >> It is a bit suspicious that you made no changes to
> >> files/dep-gen.sh in the port direct
ssue for having it automatically determined, btw?
--
Perry E. Metzgerpe...@piermont.com
r options people see? Thoughts about what "openmaintainer"
should generally mean?
I'm quite serious about saying that clear rules and certainty helps.
If I know what the rules are, it's much easier to quickly handle
things that can be handled quickly and to refer things
e ticket submission someday
> often resulted in months of nothing happening, or years.
>
> Maybe this is better. I think it is. Is it?
I tend to think it's a better way of working but it's up to the
community as a whole to say if it's really the right way to do
things. (If people really don't like it, I can hang back more.)
Perry
--
Perry E. Metzgerpmetz...@macports.org
is means
we'll be bumping some port revisions twice, and things may be a bit
broken during the next day or two given that both protobuf-cpp and
protobuf3-cpp can't be installed at the same time.
(Given that we don't need the old one, getting them both to install
at the same time doe
s 'Work In Progress'. This is trivially done
> > by adding 'WIP' to the start of the PR title.
>
> Wouldn't it be more appropriate to use labels, rather than
> inserting a label into the title?
>
I tend to think labels are better as well.
Perry
--
Perry E. Metzgerpmetz...@macports.org
orts, but much less suitable for
> (nearly) ready patches. GitHub on the other hand has drawbacks when
> the number of issues grows.
Indeed. Which is why I think using git's branch facility is the right
tool, and not GitHub as such.
Perry
--
Perry E. Metzgerpmetz...@macports.org
have a _short_ PR
queue. It really does keep things from getting lost.
Perry
--
Perry E. Metzgerpe...@piermont.com
thub, review the changes in github, etc. It's just not a
pull request because it isn't ready to be pulled into master.
Perry
--
Perry E. Metzgerpmetz...@macports.org
There's a port I suspect hasn't built in a long while. How can I
check on what is and isn't building on the buildbots?
--
Perry E. Metzgerpmetz...@macports.org
On Thu, 26 Apr 2018 01:19:59 +1000 Joshua Root
wrote:
> On 2018-4-26 00:44 , Perry E. Metzger wrote:
> > I tend to think it's a better way of working but it's up to the
> > community as a whole to say if it's really the right way to do
> > things. (If people r
;I'm
happy with whatever you do as long as you test your changes".
Allowing people to just set a different policy in their Portfile
comments may be the only practical way to go here.
That said, under the current system, I think Joshua really means for
his ports to be closed, and probably
On Wed, 25 Apr 2018 10:34:47 -0500 Ryan Schmidt
wrote:
> On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
> > On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
> >> Portfile authors need to manually "revbump" the library's
> >> depend
On Thu, 26 Apr 2018 01:46:27 +1000 Joshua Root
wrote:
> On 2018-4-26 01:34 , Ryan Schmidt wrote:
> >
> > On Apr 25, 2018, at 09:02, Perry E. Metzger wrote:
> >> On Tue, 24 Apr 2018 09:31:04 -0700 Ken Cunningham wrote:
> >>> Portfile authors need
On Wed, 25 Apr 2018 12:13:37 -0700 Ken Cunningham
wrote:
> On 2018-04-25, at 11:58 AM, Perry E. Metzger wrote:
>
> > There's a port I suspect hasn't built in a long while. How can I
> > check on what is and isn't building on the buildbots?
>
> check pack
On Wed, 25 Apr 2018 14:40:55 -0500 Ryan Schmidt
wrote:
> On Apr 25, 2018, at 14:14, Perry E. Metzger wrote:
>
> > I don't know that this is needed. As I noted, there are other
> > package systems that just note that they have to rebuild
> > dependents if a packa
the minuses of going along with
that? The most obvious one is, I think, the possibility of breaking
things that are messy to fix. (The positives are obvious and needn't
be belabored.)
Perry
--
Perry E. Metzgerpmetz...@macports.org
etail will
reveal whether it is too much work to bother with or relatively easy
to do. (My guess is probably the former, but it would be nice to
figure out what is involved first.)
Perry
--
Perry E. Metzgerpmetz...@macports.org
rary version info is recorded in the binaries. Rev-upgrade
> works very well in most cases. I'm having a hard time understanding
> how this would help.
Well, right now we're manually bumping "revision" in dependent ports
when we upgrade a port that is depended on, right? This seems to
indicate that the current way isn't automatic. Or maybe I'm
misunderstanding?
Perry
--
Perry E. Metzgerpmetz...@macports.org
On Thu, 26 Apr 2018 10:03:59 -0500 Ryan Schmidt
wrote:
> On Apr 26, 2018, at 10:00, Perry E. Metzger wrote:
>
> > On Thu, 26 Apr 2018 23:54:49 +1000 Joshua Root wrote:
> >>> So rather than just guessing based on things like major version
> >>> of a library
n the case of
rethinkdb our version is ancient. In the case of raceintospace our
version isn't that ancient.
Perry
--
Perry E. Metzgerpmetz...@macports.org
On Fri, 27 Apr 2018 01:09:49 +1000 Joshua Root
wrote:
> On 2018-4-27 01:03 , Ryan Schmidt wrote:
> >
> > On Apr 26, 2018, at 10:00, Perry E. Metzger wrote:
> >
> >> Well, right now we're manually bumping "revision" in dependent
> >> p
e is not.
>
> There's next years GSOC project for you :>
Hey, that wouldn't be a bad one.
--
Perry E. Metzgerpmetz...@macports.org
rry about that. Note that if you had done a pull request, I would
have made sure that someone looked at it before now. We are much
better at the moment at dealing with patches via pull requests than
via tickets.
Perry
--
Perry E. Metzgerpmetz...@macports.org
t;
>
> and so far, that fixes all the ports for me.
>
> But it's not a fix I'm prepared to suggest in a Portfile just yet.
Understood.
Perry
--
Perry E. Metzgerpmetz...@macports.org
sts.macports.org/pipermail/macports-dev/2018-April/038496.html>
>
> ;-P
Pardon my ignorance, but I'm not sure I understand why the rev bump
would still be necessary if we could tell the build bots to just
rebuild the package at that point?
Perry
--
Perry E. Metzgerpmetz...@macports.org
On Thu, 26 Apr 2018 19:17:27 +0200 Rainer Müller
wrote:
> On 2018-04-26 18:55, Perry E. Metzger wrote:
> > On Fri, 27 Apr 2018 02:46:43 +1000 Joshua Root
> > wrote:
> >>> So what might work would be trying out installing the archives
> >>> in a sandbox a
rly worried about breaking the build.
I should have gone to Trac of course. It hasn't built in a long time.
https://trac.macports.org/query?0_port=rethinkdb&0_port_mode=~&0_status=%21closed&col=id&col=summary&col=port&col=status&col=owner&col=type&col=pr
on them and make you fix them (and squash
the commits) before we merge.
Perry
--
Perry E. Metzgerpmetz...@macports.org
In one part of the guide, we say not to use "file copy" but to use
"copy" instead, but in 4.3.2. we show an example using "file copy"
rather than "copy". Is this a bug?
--
Perry E. Metzgerpe...@piermont.com
On Fri, 27 Apr 2018 05:02:30 +0200 Rainer Müller
wrote:
> On 2018-04-27 03:23, Perry E. Metzger wrote:
> > In one part of the guide, we say not to use "file copy" but to use
> > "copy" instead,
>
> Are you sure you read that in the guide?
Yes.
"F
On Fri, 27 Apr 2018 23:10:34 +1000 Joshua Root
wrote:
> On 2018-4-27 23:02 , Rainer Müller wrote:
> > On 2018-04-27 14:37, Perry E. Metzger wrote:
> >> "For the above operations provided by Tcl's file command,
> >> MacPorts provides the following sho
atever you want to do.
Regardless of what gets chosen, I'd suggest that we
1. Update the documentation to consistently follow the selected style.
and maybe
2. Update "port lint" to notice style violations.
--
Perry E. Metzgerpmetz...@macports.org
to play with the
operations you need to perform.
--
Perry E. Metzgerpmetz...@macports.org
0e585feb55340dfe2a45d236f90fd2edecdb3e4
> https://github.com/macports/macports-ports/commit/968ddf5b34bbba587c5c1335c24d79bb8e4ea481
> https://github.com/macports/macports-ports/commit/24864aeda99bedbc183f882878df70e8b555aa0b
>
> > On Apr 27, 2018, at 5:47 PM, Perry E. Metzger
> &
20e585feb55340dfe2a45d236f90fd2edecdb3e4
> https://github.com/macports/macports-ports/commit/968ddf5b34bbba587c5c1335c24d79bb8e4ea481
> https://github.com/macports/macports-ports/commit/24864aeda99bedbc183f882878df70e8b555aa0b
>
> > On Apr 27, 2018, at 5:47 PM, Perry E. Metzger
quite careful I may have missed
a revision or two on either end by accident.
And let me just say, git's UI is horrible. Yes, we're stuck with it
forever because the tooling is too good, but when you have to deal
with something like this and you don't use those commands every day
it
atches,
I recommend doing a GitHub pull request. If you do that, I'll be able
to look at this a bit later today.
Perry
--
Perry E. Metzgerpmetz...@macports.org
o do it again. :)
Perry
--
Perry E. Metzgerpmetz...@macports.org
I don't know much about Trac. Is it possible to do a query against it
to get raw data on open tickets over time, which could be fed to a
graph that could be put up in the Wiki?
--
Perry E. Metzgerpmetz...@macports.org
On Sun, 29 Apr 2018 16:29:34 -0400 "Perry E. Metzger"
wrote:
> I don't know much about Trac. Is it possible to do a query against
> it to get raw data on open tickets over time, which could be fed to
> a graph that could be put up in the Wiki?
>
Note that I'll ha
k.uni-mainz.de/~reiffert/macports/>
The script doesn't seem to exist in the internet archive though. :(
--
Perry E. Metzgerpmetz...@macports.org
Sometimes, I've noticed, PRs in the queue don't get automatically
labeled as expected. See this one, for example:
https://github.com/macports/macports-ports/pull/1687
Anyone know why?
Perry
--
Perry E. Metzgerpmetz...@macports.org
=changetime,desc=1,max=10,format=table)
which would seem to indicate that it should not be showing closed
tickets.
Any ideas?
Perry
--
Perry E. Metzgerpmetz...@macports.org
On Mon, 30 Apr 2018 14:30:51 + Zero King
wrote:
> On Mon, Apr 30, 2018 at 10:18:51AM -0400, Perry E. Metzger wrote:
> >On:
> >https://trac.macports.org/wiki/Tickets
> >
> >I see a list of tickets assigned to me, but it includes closed
> >tickets. When I ed
On Mon, 30 Apr 2018 10:40:41 -0400 "Perry E. Metzger"
wrote:
> On Mon, 30 Apr 2018 14:30:51 + Zero King
> > The `or` has lower precedence. So use
> > TicketQuery(status=!closed,reporter=$USER,or,status=!closed,owner=$USER,col=id|summary|component|port|reporter|ow
st effort going not to fixing problems but to finding the
problems that can be fixed.)
...
Anyway, that was what I wrote. I'd be interested in hearing other
people's thoughts.
Perry
--
Perry E. Metzgerpmetz...@macports.org
On Mon, 30 Apr 2018 17:50:51 +0200 Rainer Müller
wrote:
> The report uses "order=time" (Created), but the name suggests it
> would be supposed to use "order=changetime" (Modified). I just
> corrected that.
Thank you!
--
Perry E. Metzgerpmetz...@macports.org
Tags failed to appear again on something in the PR queue.
https://github.com/macports/macports-ports/pull/1697
--
Perry E. Metzgerpmetz...@macports.org
On Tue, 1 May 2018 00:51:27 +0200 Rainer Müller
wrote:
> On 2018-04-30 18:16, Perry E. Metzger wrote:
> > But, more generally: because if you make your tracking system
> > into a graveyard of dead requests that will never be acted on,
> > you end up with it being very dif
On Mon, 30 Apr 2018 18:26:32 -0500 Ryan Schmidt
wrote:
> On Apr 30, 2018, at 10:06, Perry E. Metzger wrote:
>
> > Perry E. Metzger (pmetzger) pushed a commit to branch master
> > in repository macports-ports.
> >
> >
> > https://githu
On Tue, 1 May 2018 13:20:45 + Zero King wrote:
> As Rainer replied, GitHub didn't provide the needed information in
> time. Maybe we should wait 30 seconds and retry?
That seems like a very good idea. I'd probably wait two minutes,
though, just to nail it.
Perry
--
her. This is exactly what happened in the
> cfitsio package. However, I'm afraid that this would be non trivial.
One can do _some_ of this with nm and some scripts -- that is, one
can check if one library fails to export a symbol that the other
exports. (More than that is difficult.)
pport Python 2.7, we should
probably deprecate the port.
Thoughts?
--
Perry E. Metzgerpmetz...@macports.org
Ryan asks, in https://trac.macports.org/ticket/56424
whether it is a reasonable idea to keep all the Pear modules in the
ports collection given that they were never updated after their
initial import seven years ago.
Thoughts? Probably best to reply on the ticket.
--
Perry E. Metzger
When pull requests come in, users are asked to fill out a short
checklist. I'd like to add a reminder to squash your commits into it
-- this has become a frequent issue with pull requests from new
contributors.
Where do I find the checklist to edit it?
Perry
--
Perry E. Me
On Mon, 7 May 2018 12:58:04 + Zero King wrote:
> On Mon, May 07, 2018 at 08:41:30AM -0400, Perry E. Metzger wrote:
> >When pull requests come in, users are asked to fill out a short
> >checklist. I'd like to add a reminder to squash your commits into
> >it -- this h
es nothing itself.
I'm inclined to commit this. Thoughts?
Perry
--
Perry E. Metzgerpmetz...@macports.org
7;t do a
> notification if the only person to be notified is the person to
> whom the PR is already assigned, or from whom a review was already
> requested, that would help a little.
Would you like the reminder on how to use "skip notification"
restored? I'd want to put it
emove the documentation of this feature from
> the pull request template, will you document it elsewhere?
Restored (at the bottom).
--
Perry E. Metzgerpmetz...@macports.org
excellent software developers from all over the world.
> I'm looking forward to more contributions, too!
Welcome!
Perry
--
Perry E. Metzgerpmetz...@macports.org
I noticed that "reclaim" doesn't seem to be in the man page or in the
guide. Am I missing something?
Perry
--
Perry E. Metzgerpmetz...@macports.org
Renee, do you think you can do a new pull request with these fixes?
Perry
On Fri, 25 May 2018 14:48:05 -0500 Ryan Schmidt
wrote:
> On May 24, 2018, at 09:06, Renee Otten wrote:
>
> > Perry E. Metzger (pmetzger) pushed a commit to branch master
> > in reposit
Starting in a few days and lasting for a few weeks, my availability
might be spottier than usual, so if other people wanted to step up to
help watch the pull request queue for a while, it would be
appreciated. I will still be around, just not quite so steadily.
Perry
--
Perry E. Metzger
fact that I've had a lot of unavoidable drains on my
time recently, I would have hand-fixed all of the issues and
committed the (correct) changes myself, but I was not in a position
to do so.
Perry
--
Perry E. Metzgerpe...@piermont.com
d the sum of the gains
they ever experience running Python over the lifetime of the binaries.
It is thus now available for users, but not the default.
--
Perry E. Metzgerpmetz...@macports.org
On Sun, 15 Jul 2018 16:46:59 -0700 Eitan Adler
wrote:
> On Sun, 15 Jul 2018 at 13:30, Perry E. Metzger
> wrote:
> > It can take tens of minutes instead of a minute or two to build
> > when you turn it on. That's quite different from the fairly slight
> > change th
e are people for whom this is important,
but they're not normal users.
Perry
On Sun, 15 Jul 2018 16:46:59 -0700 Eitan Adler
wrote:
> On Sun, 15 Jul 2018 at 13:30, Perry E. Metzger
> wrote:
> > It can take tens of minutes instead of a minute or two to build
> > when
On Sun, 15 Jul 2018 19:34:58 -0700 Eitan Adler
wrote:
> On Sun, 15 Jul 2018 at 17:00, Perry E. Metzger
> wrote:
> >
> > I want to be clear about something. In theory, we could turn on
> > runtime trace guided optimization for _every_ binary. Python isn't
> &g
run time difference for most people, either.
The average person _never_ runs a compute bound python program.
--
Perry E. Metzgerpmetz...@macports.org
On Tue, 17 Jul 2018 00:15:43 +0100 Chris Jones
wrote:
> > On 16 Jul 2018, at 1:00 am, Perry E. Metzger
> > wrote:
> >
> > I want to be clear about something. In theory, we could turn on
> > runtime trace guided optimization for _every_ binary. Python isn't
&
1 - 100 of 225 matches
Mail list logo
