to do review every change, then I
could see it being helpful - but we don't have that]
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
by someone who could
temporarily disable the build infrastructure, make the mass change, and then
bring the build infrastructure back up.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
t; referring users to their web page, and I suggest that we do not mention "hub"
> in our page.
while that's super-silly of the 'hub' author, I don't think we need to
retaliate by not using or recommending the software if it's useful.
--
Daniel J. Luke
_
On Oct 24, 2016, at 2:31 PM, Rainer Müller wrote:
> Existing developers need to request to be added to this team by sending
> a mail to the macports-infra mailing list as instructed in the announcement.
of course, sorry I apparently can't read and follow directions :)
--
Dan
On Oct 24, 2016, at 1:26 PM, Clemens Lang wrote:
> On Mon, Oct 24, 2016 at 12:54:23PM -0400, Daniel J. Luke wrote:
>> This looks like it's true for me as well (cannot edit tickets beyond
>> making comments).
>
> Try clearing your cache (a force-reload should do that).
deal with it). It's also
perfectly reasonable to punt on this until after we've settled in after the
repo move.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
he problem would have been that you weren't a member of the MacPorts org on
> GitHub. Once you accept the invitation I just sent, you should be able to
> edit tickets.
This looks like it's true for me as well (cannot edit tickets bey
ust don't have the
> resources to investigate too deeply.
I think it's fine to close as 'wontfix' with a note back to the reporter (and
anyone who looks at the ticket in the future) explaining that you don't have
time/resources to get the un
On Oct 11, 2016, at 10:04 AM, René J.V. Bertin wrote:
> On Tuesday October 11 2016 09:21:09 Daniel J. Luke wrote:
>
>> one way to handle it could be:
>> +# don't normalize absolute paths
>
> See my previous message about why normalisation might be used h
p`
/opt/local/bin/nmap is provided by: nmap
> On Oct 11, 2016, at 9:07 AM, Daniel J. Luke wrote:
> see also:
>
> https://lists.macosforge.org/pipermail/macports-dev/2014-May/026728.html
>
> which I linked to the last time you brought this up.
>
> (no one replied to t
> port, or even to something in system space), regardless of whether there are
> "unexpected" symlinks in the path, no?
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
thats what the cool kids do these days. Currently, once they find out
> about svn, and trac, and yes i agree the little tired looking web pages, i
> suspect they are more likely to drift away. So the move to git will help.
the cool kids also aren't
ot inspire
> confidence for prospective collaborators.
Look - something concrete we can act on!
I propose:
- A new wiki page where we collect requests for new ports
- closing all of the new port request tickets
Leave trac tickets for bugs/updates/things we expect to be acted on in a
are different sizes).
> On the contrary. Plus, you are just
> stating the obvious: something has not been done in an exact way,
> therefore there is no evidence that this exact way yields this exact
> result. Duh.
I'll be very pleased if you're right and that moving to GitHub will bring in a
large volume of (new) high-quality submissions.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
ger's sole
> reason for being is to make the routine task of installing software and
> updates easier, more reliable and trustworthy.
if you have to tinker, and you contribute your tinkering, then other people
won't have to tinker.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
> 110Gb free). I know this is less of an issue on SSDs yet I cannot help but
>> think that free disk fragmentation ends up being a PITA everywhere. The
>> proposed change should help keeping it in check.
>>
>> I haven't look at how trivial it would be to implement t
2 out Apple is providing security updates for 10.10 and up only (unless I
> missed them changing it again).
As mentioned on this thread, Apple hasn't published a policy (that I'm aware
of). If you've seen a published security update policy from Apple - I'd be very
happy to
urther restricted to only include OS
releases still supported by Apple - ie those actively getting security updates]
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
shop/product/MC573Z/A/mac-os-x-106-snow-leopard )
back in the pre-history of 'System 7' -> 'Mac OS 7.6', previous versions didn't
officially change their name.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
then linking some things into
${destroot}${prefix}/bin) if you're looking for an example to help.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
kling of a patch's
> purpose.
I'm sure I've been guilty of creating patch-Foo.c.diff files in the past too,
and I agree it would be much better to choose a better identifier.
--
Daniel J. Luke
___
macports-dev mailing list
macp
e it was the 'least bad'
choice).
See also: http://queue.acm.org/detail.cfm?id=2349257
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
onsidering all the various build systems we encounter in MacPorts, from
> autotools to xcodebuild to cmake to scons to qmake to manually crafted
> Makefiles, my impression is that autotools sucks the least.
I guess we can just disagree on t
ut how to build the project, and after encoding
that knowledge into a Portfile, we all benefit.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
because if the port says "license GPL" it
> *could* be correct, but it's probably a mistake. If we change our policy,
> then I will *know* that "license GPL" is a mistake because it does not
> specify a version.
Sure - and we can encode it so lint complains a
're not going to be able to systematically know whether people are making a
mistake, and knowing "person made a mistake" in the license field isn't useful
to the ports system (only useful to a human reviewer who can correct the
Portfile).
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
On Jul 14, 2016, at 11:14 AM, Brandon Allbery wrote:
> On Thu, Jul 14, 2016 at 11:07 AM, Daniel J. Luke wrote:
> I don't think it's useful to define a status for "it's unclear which version
> of a license this falls under". (what kind of decisions w
On Jul 14, 2016, at 4:23 AM, Ryan Schmidt wrote:
> On Jul 13, 2016, at 8:43 AM, Daniel J. Luke wrote:
>> On Jul 13, 2016, at 9:36 AM, m...@macports.org wrote:
>>> Or does simply stating “GPL” cover that already and that is why it has
>>> always been that way?
>&g
PL there
appears to be no version of the GPL before version 1, so GPL and GPL-1+ are
equivalent.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
cports file doesn't appear to be used at all. Should the
> port install that as well?
maybe?
I have a dim recollection of providing coordinates to someone back in the
opendarwin days and I just wanted to make sure the file wasn't pointing at my
former reside
% cd `port dir ninja`
% ls -l files/
total 16
-rw-r--r-- 1 dluke staff 226B Jun 27 11:38
patch-configure.py-use-system-python.diff
[so, macports downloads the ninja tarball as patch-configure.diff and
patch-configure.py-boostrap-only.diff and tr
bly with diff attached, although if it's just mass revbump that's
probably not necessary). Ticket will say something like: X days from now perl5
will be upgraded to /latest release/ and your p5 ports will be rev-bumped.
Maintainers who were interested in testing could do so - and peo
On May 11, 2016, at 2:16 PM, mo...@macports.org wrote:
> subversion-perlbindings: add new subport subversion-perlbindings-5.24
While this change is fine - it's not an openmaintainer port (and this wasn't a
"broken port" issue), so I would have appreciated a no
is to just stop trying to support multiple
perl versions.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
On May 4, 2016, at 8:58 AM, Ryan Schmidt wrote:
>> Can you just manually put the openssl distfile on the master mirror? Since
>> so many ports depend on it, we're likely to see lots of noise from people
>> with older systems.
>
> Done.
Excellent. Tha
ally twice a week. The script takes
> over 24 hours to run, so starting it manually is probably not helpful.
Can you just manually put the openssl distfile on the master mirror? Since so
many ports depend on it, we're likely to see lots of noise from people wit
7;s not there
already), it would be useful to prevent more tickets from being opened for
failed builds.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
(PCI requirements
tend to drive a lot of "standard" configurations even for systems that don't
process credit cards).
> On May 3, 2016, at 3:32 PM, Daniel J. Luke wrote:
> It looks like the snowleopard and mtln buildbots can't download current
> openssl:
>
> DEBUG
host for any https url (or just for anything
if that's easier)? Some other solution?
[Noticed from clamav build failures
http://build.macports.org/builders/buildports-snowleopard-x86_64/builds/41753
http://build.macports.org/builders/buildports-mtln-x86_64/builds/29275]
--
Dani
ency engine to
handle variants.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
This could be fixed by adding variants to the dependency engine OR by making
>> use of the existing dependency engine (ie, breaking the port up into pieces
>> so that things can depend on what they actually need) OR by just getting rid
>> of variants (batteries-included insta
ng dependency engine (ie, breaking the port up into pieces so
that things can depend on what they actually need) OR by just getting rid of
variants (batteries-included install).
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
do users add additional functionality that wasn't built when they first
built ROOT6? [the answer is probably 'rebuild']
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
ent this
> that I think we should avoid.
I suppose it looks like hackery to you - but it does provide a consistent and
functional end product for the user.
hacking on how default variants work only fixes one case (and doesn't fix the
problem in general).
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
rts (because
they're already installed by the main port) - but it's worth it to have
everything "just work" for our end-users.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
me reason why it can't be split into multiple ports so that the
existing dependency management can work the way it is supposed to?
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/ma
binary
archive?]
install problems like this are almost always solvable without resorting to
variant magic. [why can't there be a fftw-3-fortran port that has the libs you
need to depend on?]
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev
hy it would be
> very helpful to pass them down as it would solve many of the issues about
> "dependency on a variant" that are always being complained about on this list
> (such as the scenario I describe above).
... but it wouldn't be a complete solution to
pass default variants down.
> port install A
> and
> port install B && port install A
>
> should result in the same final install.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
dependency of some other port, it should be
installed the same way as if it were installed manually first.
ie. A requires B:
port install A
and
port install B && port install A
should result in the same final install.
--
Daniel J. Luke
__
On Apr 11, 2016, at 10:49 AM, René J.V. Bertin wrote:
> Is it acceptable to have a sort of cyclic dependency
no.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listi
On Mar 31, 2016, at 2:45 PM, Daniel J. Luke wrote:
> Does default_variants not work like other commands? I would have expected
> default_variants-append here (and/or would rather be able to do
> default_variants-delete inside the compatibility variant).
answering my own question (sr
ds? I would have expected
default_variants-append here (and/or would rather be able to do
default_variants-delete inside the compatibility variant).
>}
>variant no_pcre description {Legacy compatibility variant} {}
>if {![variant_isset no_pcre]} {
>default_variants +pcr
ere were fewer versions, it might not be unduly-burdonsome to just have
individual portfiles for each version (especially if it solved other problems).
Of course, there may be some other approach to reducing portfile duplication
that woul
you want to discuss further. You're right that it's
only tangentially related (the port would be less complicated if it didn't have
to support as many php versions).
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
distributing versions of php that
no longer have upstream support)
> So if you're manually examining all ports that depend on openssl, you can run
> an "svn log" on them to see if any commits after r146162 updated the version
> or revision.
ick.
--
Daniel
er already got a rev-bump or a version upgrade, so they do not need
> it anymore:
That's probably safe, but I don't think there is a compelling reason to try and
only revbump the minimal set of ports (better to have some needless
rebuilds/downloads of b
On Mar 10, 2016, at 10:14 AM, Rainer Müller wrote:
> The longer we wait, the harder it will be to catch these.
> Should we rev-bump all dependents of OpenSSL now?
yes.
--
Daniel J. Luke
___
macports-dev mailing list
macpor
nd it works fine.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
s willing to put the effort in to maintain it, I'm not opposed -
but I don't think we need to do more than have some port notes with a reference
to the upstream "upgrading to 2.4" docs.
Creating a bunch of 'dead end' ports may "keep things working" for users
problem with that? I could do it if you don’t….
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
also changes the directory
> layout.
I think it's a mistake to tie upgrading the apache port to 2.4.x and changing
the layout (we could just do a simple version bump with the current port + make
modifications to any apache modules that ne
.
It's also how we generally handle this in MacPorts (consistency and
reproducibility being things that are important to us).
The proper fix from a MacPorts perspective is to depend on python27 and update
the shebangs to point to the macports pyt
that site is using a newer ssl/tls protocol than the version of
> curl/openssl provided with Mountain Lion knows about?
If that's the case, we could probably treat https connections like ftp (for the
older buildbots) and they could use the proxy to still be able to fetch.
--
Daniel J. Luk
f memory. Trac
> server restarted again.
You should consider changing the apache configuration to not spawn so many
processes ;-)
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
rsion number, fetches multiple new distfiles
(possibly including patches), need to update multiple distfile checksums
Less common case #2 is:
- portfile is extra complicated (does some craziness to generate a large number
sub-ports)
Maybe we can attack the common case and enhance it to cover ad
d propose that the existence of complicated portfiles is
evidence of features in base that are missing that maintainers desire.
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
ksum/ would probably
work (I'm perhaps not creative enough to think of a use-case where that would
false-positive and change something unintended).
--
Daniel J. Luke
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosf
e a few times is that using the port
> command for this can wipe your build directory (which may not yet be
> desirable when you're just updating the checksums), and more or less obliges
> you to add the variants you're going to use later on.
--
Daniel J. Luke
__
7;t review the patches - I had thought that that was how the latest one
worked (if not, it really should work that way).
--
Daniel J. Luke
++
| * dl..
nal 10x slowdown).
As mentioned in the ticket - this is really something that needs to be
configurable if it's added (I can see how one might want this on a small SSD,
but I don't want it set on my large disk arr
>> No luck with port search either:
>>> $ port search --exact --depends_lib --depends_build go
>>> No match for go found
>>
>> Try port echo depends:go.
>>
>
> This is not too useful as it returns a list of ports whose dependencies
> have '
n the base case we
would get an error - in the worst case anything could be in that file).
--
Daniel J. Luke
++
| * dl...@geeklair.net ---
On Jan 6, 2016, at 8:53 PM, Ryan Schmidt wrote:
> On Jan 6, 2016, at 7:51 PM, Daniel J. Luke wrote:
>> On Jan 6, 2016, at 8:35 PM, Ryan Schmidt wrote:
>>> How would you envision this capability being provided? I wouldn't want to,
>>> for example, just open up f
(and/or only provides source from a source control
system), then the best bad option is for us to create our own distfile.
--
Daniel J. Luke
+===
> The ideal would be to work with the developers to convince them not to issue
> stealth updates.
+1 for this as well.
--
Daniel J. Luke
+=
www.python.org/ftp/python/doc) but not the latest for 34
>> (3.4.4) or 35 (3.5.1). If there is another, stable, download location,
>> I'd be happy to point to it.
>>
>> Thanks,
>> - Eric
--
Daniel J. Luke
ertain operation that should always be exclusive (like install, de/activate).
please do.
--
Daniel J. Luke
++
| * dl...@geeklair.net * |
will not be impacting each other. The lock should be
> intelligent enough to use the dependency tree�after all, MacPorts is the
> one computing it.
>
> I agree with Rene here: the lock should be smart enough to use the
> dependency tree.
>
> On 01/04/2016 04:18 PM, Daniel J.
it's not something we should ship.
--
Daniel J. Luke
++
| * dl...@geeklair.net * |
|
indexed,
um?
Rainer just wrote: "To decide wether we need to reindex we need the port's name
to look it up in the index. The only way to get the name from the Portfile is
to run the Tcl interpreter on the Portfile. But par
a
> hash for a port's portfile should do the trick, no?)
sounds like you have an idea for an improvement? You should write up a patch
and try to get it included.
-
f the old perl
versions, it would be possible for him/her to run his/her own local repo (and
share it with others).
I highly suspect that anyone who needs this is going to be happier with
p
7;s 1st line?
Anything is possible, although this seems like a bad idea to me.
Maybe if you included a concise description of exactly what you're trying to
do, someone would have an alternate idea that
rg/pipermail/macports-dev/2015-March/029973.html
--
Daniel J. Luke
++
| * dl...@geeklair.net * |
| *
ople are not capable of safely running an internet
connected device that isn't actively supported by a vendor.
The specifics of what must be done to mitigate the risk depends a lot on the
specifics of the situation (and often would cost more than just getting a new
box / installing a
un on Apple hardware ... (ones that are still getting security updates).
> That's not always practical or appropriate.
... which might be why I didn't suggest it ;-)
--
Daniel J. Luke
+===
ching to libc++, since more and more ports are
> unable to build with libstdc++.
... and by the time this is done - how many people will be running those old
sys
write a 'port' or other utility procedure that does 'check
for available archives' and iterates over whatever number of directories we
have.
We do seem to be able to still release new versions of base/ ;-)
--
Daniel J. Luke
ystems is truly very low at this time.
These machines no longer run a version of Mac OS X that receives security
updates from Apple - and don’t run one of the 2 major OS releases we support
per policy (current, previous).
—
Danie
sh7.1p1, and will be submitting the patch
> upstream (but it's a OSX only fix...)
>
> https://trac.macports.org/ticket/49007
--
Daniel J. Luke
+==
On Nov 4, 2015, at 8:38 AM, Rainer Müller wrote:
> Effectively, my proposal is to move the whole fetching from VCS such as
> git/svn/hg/bzr into the mirror phase, which is called if necessary.
+1 for the general idea of having this work by generating a tarball.
--
Daniel J
rderly transition to somewhere else (or if
something is changing to fix the lack of attention to problems that we’re
currently seeing).
—
Daniel J. Luke
+===
et/48758
>
> Snow Leopard builder registry corrupted:
> https://trac.macports.org/ticket/47976
>
> Lion builder registry corrupted: https://trac.macports.org/ticket/48486
>
> Mavericks builder stuck: https://trac.macports.org/ticket/48802
Set up El Capitan Builder https:
I can’t speak for anyone else, but that works for me :)
> On Oct 11, 2015, at 8:08 PM, Jeremy Huddleston Sequoia
> wrote:
>
> Ok, so if the set includes the union of "good" and "specified", we're all
> happy?
>
>> On Oct 11, 2015, at 13:
s, and I seem to remember having this conversation once before... :)
>>
>> On 2015-10-12 05:06 , Daniel J. Luke wrote:
>>> it’s really useful for the case when upstream publishes a checksum (that’s
>>> not one of our default ‘good’ ones) when the output includes th
output on checksum failure
>
> This should help adoption of better, more robust hashing algorithms.
—
Daniel J. Luke
++
| * dl...@
> On Sep 20, 2015, at 8:36 AM, Thibaut Paumard wrote:
> Unless the project decides on one
> over the other,
https://guide.macports.org/chunked/porthier.html
"libexec/
System daemons and system utilities (executed by other programs)."
mode all (or at
least most) of the time. I know Clemens posted some TODO to the list a while
ago …
—
Daniel J. Luke
++
| *---
in our fink builds. Thanks in advance for any info.
I don’t think it does, but you could probably hack something into
portsandbox.tcl for temporary testing...
1 - 100 of 918 matches
Mail list logo
